Menu
任务巡检助手：基于实际任务数据自动分析未完成任务、生成动态优先级建议、识别标签治理问题；触发: 巡检, patrol, 任务分析, workload, 未完成任务, 周报.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | task-patrol |
| phase | implement |
| description | 任务巡检助手：基于实际任务数据自动分析未完成任务、生成动态优先级建议、识别标签治理问题；触发: 巡检, patrol, 任务分析, workload, 未完成任务, 周报. |
在需要自动分析未完成任务、降低任务管理负担时触发本技能。基于 Yunxiao MCP Server 的只读工具，完成三件事：
典型触发查询：
不适用场景：
当前 MCP Server 是 read-only GA 边界。MUST NOT 尝试调用写操作工具（如更新状态、添加评论、创建子任务）。所有输出必须是：
MUST 基于实际拉取的任务数据做分析，不能凭记忆或假设。每次巡检必须：
mcpc connect @yunxiao）get_current_user）get_my_project_workitems 或 search_workitems）优先级分层不是固定规则，而是基于实际状态语义和时间分布动态判断。默认采用三层模型，但应适配用户实际使用的工作流状态：
| 层级 | 判断维度 | 参考标准（可按团队节奏调整） |
|---|---|---|
| P0 / 今日聚焦 | 高活跃度状态 + 近期创建 | 处于"进行中"类状态的任务；或"待处理"但创建时间较短的紧急任务 |
| P1 / 本周计划 | 待启动状态 + 中等滞留 | 处于"待处理/backlog"类状态，已创建一段时间但尚未严重超期 |
| P2 / 待评估 | 长期滞留 + 低活跃状态 | 任何未完成状态但创建时间显著过长（如远超团队常规迭代周期），建议重新评估必要性 |
关键：根据用户实际状态名称映射到上述语义层级。如果用户团队没有"处理中"而是"开发中"，直接替换语义对应即可。
高风险标记：P0 中处于活跃状态但长期无进展（如超过一个迭代周期）的任务，额外标注"长期挂起"，提醒确认是否真的在推进。
如果用户未主动提及标签问题，但任务数据中存在标签使用，SHOULD 附带输出标签一致性检查：
进入条件：用户请求任务巡检或 workload 分析。
通过 mcpc 连接 @yunxiao session：
mcpc connect @yunxiao
若连接失败，提示用户检查 mcpc 配置或启动 MCP Server（如 mcpc server start yunxiao），并提供已配置的 session 名称。
get_current_user 获取用户 ID 和默认组织projectId（用户显式提供或从历史上下文获取）单项目模式（用户指定 projectId）：
get_my_project_workitems — 首选，聚合多分类search_workitems — 备选，按 category 分页获取get_project_workitem_board — 辅助，获取 Kanban 视图跨项目模式（用户未指定 projectId 或明确说"所有项目"）：
search_projects — 获取用户参与的项目列表get_my_project_workitemsMUST 拉取所有状态，不能只拉"未完成"，因为需要计算"已完成"比例作为工作量参考。 SHOULD 限制跨项目数量，避免响应过长。具体上限根据信息量动态判断（若项目任务普遍较少可适当放宽，若单个项目任务极多则应收紧）。
进入条件：已获得原始任务数据。
统计以下指标：
趋势判断原则：
| 情形 | 信号 | 建议 |
|---|---|---|
| 新增远大于完成 | 任务堆积加速 | 建议暂停接新需求，集中清存量 |
| 新增与完成大致平衡 | 收支平衡 | 维持当前节奏 |
| 新增明显少于完成 | 存量下降 | 可适当承接新任务 |
| 活跃中堆积且新增与完成平衡 | 产出停滞 | 检查是否有阻塞或上下文干扰 |
注："远大于""大致平衡""明显少于"应根据绝对数量和团队规模判断，不写死倍数。
按三层模型归类，使用用户实际的状态名称：
P0 / 今日聚焦:
- [活跃状态名] xxx
- [待处理状态名] yyy (如刚创建且紧急)
P1 / 本周计划:
- [待启动状态名] zzz
- [待处理状态名] www (如已创建一段时间)
P2 / 待评估 (stale):
- [任意未完成状态名 > 团队平均迭代周期] aaa
- [任意未完成状态名 > 更长期阈值] bbb <- 建议直接取消或转需求池
检查以下风险信号，阈值根据实际数据分布动态判断：
| 风险 | 判断依据 | 建议 |
|---|---|---|
| 多线并行 | 活跃中任务数明显过多（如超过团队建议的并行度） | 提醒聚焦，建议将部分任务移回待处理 |
| Stale 堆积 | 长期滞留任务占比过高 | 建议批量评估取消或重新排期 |
| 无 Bug/缺陷跟踪 | Bug 类分配数为 0 但功能任务积压 | 建议确认 Bug 是否由他人处理 |
| 标签混乱 | 同一任务标签过多，或标签体系明显不一致 | 建议精简标签体系 |
进入条件：分析完成。
输出结构应清晰、可执行，但不要求严格模板化。核心要素包括：
必须包含：
可选增强：
references/weekly-report-template.md）报告输出后，SHOULD 提供下一步选项，根据用户场景动态调整：
| 反模式 ❌ | 正确做法 ✅ |
|---|---|
| 假设 MCP 会话一定可用 | 先执行 mcpc connect @yunxiao，失败时引导检查配置 |
| 只拉取"未完成"任务 | 拉取全部状态，需要"已完成"作为基准 |
| 凭记忆汇报任务状态 | 每次必须重新拉取最新数据 |
| 推荐 AI"自动完成"某个任务 | 只读边界内，只输出建议和报告 |
| 忽略 Stale 任务 | 必须单独列出并建议评估/取消 |
| 对无标签的项目输出标签建议 | 先检查是否存在标签数据 |
| 跨项目巡检时不限制项目数量 | 根据信息量动态控制，避免响应过长和信息过载 |
| 把具体阈值（如 7 天/14 天）当硬规则 | 根据团队节奏和实际数据分布动态判断 |
@yunxiao MCP 会话已确认可连接