Triage 技能：用状态机管理 Issue 与外部 PR 的分诊流程

技能概述

Triage 是一个面向开源项目维护者的 Claude 技能，它把 issue 和外部 PR 放进一套由"分类角色 + 状态角色"组成的小型状态机里，逐条评估、验证、追问，必要时打磨成一份 agent 可直接执行的简报。

适用场景

1. Issue 列表堆积，需要快速判断优先级。 维护者用一句话描述诉求（例如"给我看看有哪些需要我处理的"），技能会查询 issue tracker，按"从未分诊""正在评估""等待提问者回复但有新动态"分成三组，每组标出 [PR] 或 [issue]、数量、一句话摘要，从最旧的开始排。维护者再挑具体条目深入。

2. 判断某个 issue 能不能交给后台 agent 无人值守完成。 技能会读完整条 issue（正文、评论、标签、作者、时间，PR 还要读 diff），检索代码库确认需求是否已经实现、是否与 .out-of-scope/ 里既往拒绝过的需求重复，然后给出分类与状态建议并说明理由。确认可行后写成 agent brief，标记为 ready-for-agent。

3. 外部 PR 分流。 如果仓库把外部 PR 当作请求入口，PR 会被当作"附带代码的 issue"走同一套角色和状态机。技能会实际检出代码、跑相关测试或命令，确认 diff 是否真的做到了它声称的事，再决定下一步。

核心功能

1. 两分类 + 五状态的标签体系。 分类角色是 bug（有东西坏了）和 enhancement（新功能或改进）；状态角色是 needs-triage（待维护者评估）、needs-info（等待报告者补充信息）、ready-for-agent（已完整描述，可交给 AFK agent）、ready-for-human（需要人类实现）、wontfix（不予处理）。每条分诊过的 issue 应当恰好携带一个分类角色和一个状态角色；如果状态角色互相冲突，技能会先标记出来并询问维护者，不会擅自处理。

2. 先验证，再打磨，最后落状态。 技能不会跳过验证直接打标签：bug 要按报告者的步骤复现，PR 要检出并跑测试，然后如实报告"已确认（附代码路径）""未能复现""信息不足"三种结果。信息不足本身就是强 needs-info 信号。需求还比较粗糙时，技能会调用 grilling 和 domain-modeling 两个技能，一轮一轮提问把需求问清楚，并把敲定的领域术语同步更新到 CONTEXT.md 和 ADR 里。

3. 可追溯的结论输出。 落到 ready-for-agent 时附上 agent brief；落到 ready-for-human 时用同样结构，但注明为何不能委托（需要判断力、外部权限、设计决策或人工测试）；落到 needs-info 时发一份 Triage Notes，把已经确认的结论和还需要提问者回答的具体问题分开列出，避免工作成果丢失。所有发到 issue tracker 的评论都会带上"本次内容由 AI 在分诊过程中生成"的声明。

常见问题

Triage 技能是做什么的？

它把 issue 和外部 PR 沿一套固定的状态机推进：先归类为 bug 或 enhancement，再进入某个状态角色，最终产出可执行的结论——要么是一份 agent 简报，要么是给报告者的追问清单，要么是关闭并说明理由。核心目的是让维护者不必每条都从头读起。

它能自动处理 issue 吗，还是需要人工确认？

需要人工确认。这个技能被设计为只能由维护者手动调用（disable-model-invocation），不会自己触发。推荐分类和状态、应用标签、发评论、关闭 issue 之前都会先说明将要做什么；状态流转看起来不寻常时也会先问过维护者。维护者也可以直接指定"把 #42 移到 ready-for-agent"，技能会跳过打磨环节直接执行。

needs-triage、needs-info、ready-for-agent 这些状态是什么意思？

needs-triage 是维护者需要评估；needs-info 是卡在报告者那边等补充信息；ready-for-agent 是描述完整、可以交给无人值守的 agent；ready-for-human 是需要人类来实现或合并；wontfix 是不会处理。正常流转是未标注 → needs-triage → 其余四者之一，报告者回复后 needs-info 会回到 needs-triage。

一个 issue 可以同时有两个状态标签吗？

不可以。状态角色应当恰好一个。如果发现冲突，技能会先标记并询问维护者，而不是自行挑选一个。

外部 PR 也会被分诊吗，内部成员的 PR 呢？

外部 PR 在仓库把它当作请求入口时会纳入分诊，使用与 issue 相同的角色和状态。但发现视图只暴露外部 PR——协作者正在推进的 PR 不算分诊工作。这个过滤只作用于发现环节：维护者明确点名某个 PR 时，无论作者是谁都会被分诊。

分诊时会不会重复问已经回答过的问题？

不会。技能会先解析 issue 上此前的 triage notes，检查报告者是否已经回答了待办问题，再给出更新后的全貌，不会重新问已经解决的问题。

如果某个需求已经实现过了，技能会怎么处理？

归类为"已实现"的 wontfix：关闭 issue 并在评论中指向代码中的实现位置。这种情况不会写入 .out-of-scope/——那个知识库只记录被拒绝的需求，不记录已经建好的功能。如果是被拒绝的增强需求，则会写入 .out-of-scope/ 并从评论链接过去；被拒绝的 bug 则给出解释后直接关闭。

用这个技能需要什么前置配置？

需要一份标签映射，把技能里的规范角色名对应到你的 issue tracker 实际使用的标签字符串。如果你还没有这份映射，需要先运行 /setup-matt-pocock-skills。此外技能会读取 AGENT-BRIEF.md（如何写持久化简报）和 OUT-OF-SCOPE.md（.out-of-scope/ 知识库的工作方式）作为参考文档。