القائمة
任务巡检助手：基于实际任务数据自动分析未完成任务、生成动态优先级建议、识别标签治理问题；触发: 巡检, patrol, 任务分析, workload, 未完成任务, 周报.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| 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 会话已确认可连接