| name | task-patrol |
| phase | implement |
| description | 任务巡检助手：基于实际任务数据自动分析未完成任务、生成动态优先级建议、识别标签治理问题；触发: 巡检, patrol, 任务分析, workload, 未完成任务, 周报. |
Task-Patrol: 任务巡检助手
适用范围
在需要自动分析未完成任务、降低任务管理负担时触发本技能。基于 Yunxiao MCP Server 的只读工具，完成三件事：
- 巡检：拉取用户的未完成任务，按状态分组
- 分析：识别 stale 任务、多线并行风险、优先级建议
- 建议：输出可执行的优先级队列和标签治理建议
典型触发查询：
- "分析我的未完成任务"
- "任务巡检"
- "帮我看看哪些任务该优先做"
- "我的 workload 有什么风险"
- "标签治理建议"
不适用场景：
- 需要修改任务状态、分配任务（当前 MCP Server 为只读）
- 非 Yunxiao 项目管理系统的任务分析
- 不涉及具体项目/用户的泛化讨论
核心原则
1. 只读分析，不越界操作
当前 MCP Server 是 read-only GA 边界。MUST NOT 尝试调用写操作工具（如更新状态、添加评论、创建子任务）。所有输出必须是：
- 分析报告
- 优先级建议
- 标签映射建议
- 待人工确认的 action items
2. 数据驱动，不自作主张
MUST 基于实际拉取的任务数据做分析，不能凭记忆或假设。每次巡检必须：
- 确认 MCP 会话可用（
mcpc connect @yunxiao）
- 获取当前用户信息（
get_current_user）
- 拉取指定项目的任务列表（
get_my_project_workitems 或 search_workitems）
- 基于真实数据生成分析
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）：
get_my_project_workitems — 首选，聚合多分类search_workitems — 备选，按 category 分页获取get_project_workitem_board — 辅助，获取 Kanban 视图
跨项目模式（用户未指定 projectId 或明确说"所有项目"）：
search_projects — 获取用户参与的项目列表- 对每个项目依次调用
get_my_project_workitems
- 聚合各项目数据为统一视图
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 任务逐个分析是否可以取消吗？"
- "跨项目模式下：需要我重点分析哪个项目的风险吗？"
运行参考
反模式（避免）
| 反模式 ❌ | 正确做法 ✅ |
|---|
| 假设 MCP 会话一定可用 | 先执行 mcpc connect @yunxiao，失败时引导检查配置 |
| 只拉取"未完成"任务 | 拉取全部状态，需要"已完成"作为基准 |
| 凭记忆汇报任务状态 | 每次必须重新拉取最新数据 |
| 推荐 AI"自动完成"某个任务 | 只读边界内，只输出建议和报告 |
| 忽略 Stale 任务 | 必须单独列出并建议评估/取消 |
| 对无标签的项目输出标签建议 | 先检查是否存在标签数据 |
| 跨项目巡检时不限制项目数量 | 根据信息量动态控制，避免响应过长和信息过载 |
| 把具体阈值（如 7 天/14 天）当硬规则 | 根据团队节奏和实际数据分布动态判断 |
质量自检清单
