---
name: task-patrol
phase: implement
description: "任务巡检助手：基于实际任务数据自动分析未完成任务、生成动态优先级建议、识别标签治理问题；触发: 巡检, patrol, 任务分析, workload, 未完成任务, 周报."
---

# Task-Patrol: 任务巡检助手

## 适用范围

**在需要自动分析未完成任务、降低任务管理负担时触发本技能**。基于 Yunxiao MCP Server 的只读工具，完成三件事：

1. **巡检**：拉取用户的未完成任务，按状态分组
2. **分析**：识别 stale 任务、多线并行风险、优先级建议
3. **建议**：输出可执行的优先级队列和标签治理建议

**典型触发查询**：
- "分析我的未完成任务"
- "任务巡检"
- "帮我看看哪些任务该优先做"
- "我的 workload 有什么风险"
- "标签治理建议"

**不适用场景**：
- 需要修改任务状态、分配任务（当前 MCP Server 为只读）
- 非 Yunxiao 项目管理系统的任务分析
- 不涉及具体项目/用户的泛化讨论

---

## 核心原则

### 1. 只读分析，不越界操作

当前 MCP Server 是 read-only GA 边界。**MUST NOT** 尝试调用写操作工具（如更新状态、添加评论、创建子任务）。所有输出必须是：

- 分析报告
- 优先级建议
- 标签映射建议
- 待人工确认的 action items

### 2. 数据驱动，不自作主张

**MUST** 基于实际拉取的任务数据做分析，不能凭记忆或假设。每次巡检必须：

1. 确认 MCP 会话可用（`mcpc connect @yunxiao`）
2. 获取当前用户信息（`get_current_user`）
3. 拉取指定项目的任务列表（`get_my_project_workitems` 或 `search_workitems`）
4. 基于真实数据生成分析

### 3. 动态优先级框架

优先级分层不是固定规则，而是基于**实际状态语义**和**时间分布**动态判断。默认采用三层模型，但应适配用户实际使用的工作流状态：

| 层级 | 判断维度 | 参考标准（可按团队节奏调整） |
|------|----------|---------------------------|
| **P0 / 今日聚焦** | 高活跃度状态 + 近期创建 | 处于"进行中"类状态的任务；或"待处理"但创建时间较短的紧急任务 |
| **P1 / 本周计划** | 待启动状态 + 中等滞留 | 处于"待处理/backlog"类状态，已创建一段时间但尚未严重超期 |
| **P2 / 待评估** | 长期滞留 + 低活跃状态 | 任何未完成状态但创建时间显著过长（如远超团队常规迭代周期），建议重新评估必要性 |

**关键**：根据用户实际状态名称映射到上述语义层级。如果用户团队没有"处理中"而是"开发中"，直接替换语义对应即可。

**高风险标记**：P0 中处于活跃状态但长期无进展（如超过一个迭代周期）的任务，额外标注"长期挂起"，提醒确认是否真的在推进。

### 4. 标签治理作为独立输出

如果用户未主动提及标签问题，但任务数据中存在标签使用，**SHOULD** 附带输出标签一致性检查：

- 命名规范一致性（中英文、大小写、分隔符）
- 明显拼写错误
- 同一维度的标签数量是否过度膨胀
- 同一任务标签数量是否过多（影响分类清晰度）

---

## 执行工作流

### 阶段 1：连接与数据采集

> **进入条件**：用户请求任务巡检或 workload 分析。

#### 1.1 确认 MCP 会话可用

通过 mcpc 连接 `@yunxiao` session：

```bash
mcpc connect @yunxiao
```

若连接失败，提示用户检查 mcpc 配置或启动 MCP Server（如 `mcpc server start yunxiao`），并提供已配置的 session 名称。

#### 1.2 获取用户与项目上下文

- 调用 `get_current_user` 获取用户 ID 和默认组织
- 确认目标 `projectId`（用户显式提供或从历史上下文获取）
- 若用户未指定项目，**MUST** 询问或从最近上下文推断，不可假设

#### 1.3 拉取任务数据

**单项目模式**（用户指定 projectId）：
1. `get_my_project_workitems` — 首选，聚合多分类
2. `search_workitems` — 备选，按 category 分页获取
3. `get_project_workitem_board` — 辅助，获取 Kanban 视图

**跨项目模式**（用户未指定 projectId 或明确说"所有项目"）：
1. `search_projects` — 获取用户参与的项目列表
2. 对每个项目依次调用 `get_my_project_workitems`
3. 聚合各项目数据为统一视图

**MUST** 拉取所有状态，不能只拉"未完成"，因为需要计算"已完成"比例作为工作量参考。
**SHOULD** 限制跨项目数量，避免响应过长。具体上限根据信息量动态判断（若项目任务普遍较少可适当放宽，若单个项目任务极多则应收紧）。

---

### 阶段 2：分析与分层

> **进入条件**：已获得原始任务数据。

#### 2.1 状态分布与时间趋势

统计以下指标：

- 总任务数
- 各状态数量及占比
- 处于活跃/进行中类状态的任务数（上下文切换风险指标）
- 长期滞留任务数（stale 指标，根据团队节奏判断何为"长期"）
- **近期新增** vs **近期完成** vs **前期完成**（趋势变化）
- **活跃项目数**（跨项目模式下）

**趋势判断原则**：
| 情形 | 信号 | 建议 |
|-----|------|------|
| 新增远大于完成 | 任务堆积加速 | 建议暂停接新需求，集中清存量 |
| 新增与完成大致平衡 | 收支平衡 | 维持当前节奏 |
| 新增明显少于完成 | 存量下降 | 可适当承接新任务 |
| 活跃中堆积且新增与完成平衡 | 产出停滞 | 检查是否有阻塞或上下文干扰 |

> 注："远大于""大致平衡""明显少于"应根据绝对数量和团队规模判断，不写死倍数。

#### 2.2 优先级分层

按三层模型归类，使用用户实际的状态名称：

```
P0 / 今日聚焦:
  - [活跃状态名] xxx
  - [待处理状态名] yyy (如刚创建且紧急)

P1 / 本周计划:
  - [待启动状态名] zzz
  - [待处理状态名] www (如已创建一段时间)

P2 / 待评估 (stale):
  - [任意未完成状态名 > 团队平均迭代周期] aaa
  - [任意未完成状态名 > 更长期阈值] bbb  <- 建议直接取消或转需求池
```

#### 2.3 风险识别

检查以下风险信号，阈值根据实际数据分布动态判断：

| 风险 | 判断依据 | 建议 |
|-----|----------|------|
| 多线并行 | 活跃中任务数明显过多（如超过团队建议的并行度） | 提醒聚焦，建议将部分任务移回待处理 |
| Stale 堆积 | 长期滞留任务占比过高 | 建议批量评估取消或重新排期 |
| 无 Bug/缺陷跟踪 | Bug 类分配数为 0 但功能任务积压 | 建议确认 Bug 是否由他人处理 |
| 标签混乱 | 同一任务标签过多，或标签体系明显不一致 | 建议精简标签体系 |

---

### 阶段 3：输出与建议

> **进入条件**：分析完成。

#### 3.1 输出格式原则

输出结构应清晰、可执行，但不要求严格模板化。核心要素包括：

**必须包含**：
- **概览**：项目/用户、总任务数、各状态分布、趋势判断
- **优先级分层**：P0/P1/P2 任务列表，使用实际状态名
- **风险提示**：具体风险描述 + 可执行的建议动作
- **标签治理建议**（如数据中存在标签）：基于实际数据的具体问题

**可选增强**：
- 跨项目汇总表（跨项目模式）
- 具体任务的创建时间和滞留时长
- 周报格式转换（可引用 `references/weekly-report-template.md`）

#### 3.2 交互式追问

报告输出后，**SHOULD** 提供下一步选项，根据用户场景动态调整：

- "需要我查看某个具体任务的详情吗？"
- "要生成这段时期的 Markdown 周报吗？"
- "需要我针对 P2 任务逐个分析是否可以取消吗？"
- "跨项目模式下：需要我重点分析哪个项目的风险吗？"

---

## 运行参考

- [references/yunxiao-tools-cheatsheet.md](references/yunxiao-tools-cheatsheet.md)：常用工具快速参考
- [references/label-governance-rules.md](references/label-governance-rules.md)：标签治理规则与映射模板
- [references/weekly-report-template.md](references/weekly-report-template.md)：周报生成模板与示例

---

## 反模式（避免）

| 反模式 ❌ | 正确做法 ✅ |
|----------|------------|
| 假设 MCP 会话一定可用 | 先执行 `mcpc connect @yunxiao`，失败时引导检查配置 |
| 只拉取"未完成"任务 | 拉取全部状态，需要"已完成"作为基准 |
| 凭记忆汇报任务状态 | 每次必须重新拉取最新数据 |
| 推荐 AI"自动完成"某个任务 | 只读边界内，只输出建议和报告 |
| 忽略 Stale 任务 | 必须单独列出并建议评估/取消 |
| 对无标签的项目输出标签建议 | 先检查是否存在标签数据 |
| 跨项目巡检时不限制项目数量 | 根据信息量动态控制，避免响应过长和信息过载 |
| 把具体阈值（如 7 天/14 天）当硬规则 | 根据团队节奏和实际数据分布动态判断 |

---

## 质量自检清单

- [ ] `@yunxiao` MCP 会话已确认可连接
- [ ] 已获取当前用户真实数据，未假设用户身份
- [ ] 已拉取全部状态的任务，不只是"未完成"
- [ ] 按 P0/P1/P2 三层完成优先级分层，使用实际状态名
- [ ] Stale 任务已单独标出并建议动作
- [ ] 活跃中任务数过多时给出聚焦提醒
- [ ] 标签治理建议基于实际数据，非空泛规则
- [ ] 未尝试任何写操作（状态更新、评论、分配）
- [ ] 跨项目模式下已控制信息量，输出汇总表
- [ ] 长期活跃但无进展的任务已标注高风险