task-patrol

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：

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/label-governance-rules.md：标签治理规则与映射模板
• references/weekly-report-template.md：周报生成模板与示例

---

反模式（避免）

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

---

质量自检清单

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