triage

name	triage
description	让 Issues 和外部 PR 沿分诊角色状态机流转：分类、验证、必要时持续追问，并编写可直接交给 Agent 的任务简报。
disable-model-invocation	true

分诊

让项目 Issue 跟踪器中的 Issues 沿着一个小型分诊角色状态机流转。

如果当前仓库把外部 PR 也视为请求入口（参见 Issue 跟踪器配置），分诊同样覆盖这些 PR：PR 是附带代码的 Issue。它们使用相同角色、相同状态和相同状态机；仅有少量差异会在下文标记为“对于 PR”。遇到单独的 #42 时，根据跟踪器配置判断它是 Issue 还是 PR。

分诊过程中发布到 Issue 跟踪器的每一条评论或 Issue，必须以下方免责声明开头：

> *This was generated by AI during triage.*

参考文档

• AGENT-BRIEF.md——如何编写能够长期使用的 Agent 任务简报
• OUT-OF-SCOPE.md——.out-of-scope/ 知识库的使用方式

角色

两种类别角色：

• bug——已有功能发生损坏
• enhancement——新功能或改进

五种状态角色：

• needs-triage——等待维护者评估
• needs-info——等待报告者补充信息
• ready-for-agent——信息完整，可以交给无需人工上下文的 Agent
• ready-for-human——需要人类实现
• wontfix——不会处理

对于 PR，同样的状态需要结合所附代码理解：ready-for-agent 表示已经附上任务简报，Agent 应接手 diff 的下一步工作；ready-for-human 表示已经可以由人类完成合并。

每个完成分诊的 Issue 都必须恰好拥有一个类别角色和一个状态角色。如果多个状态角色互相冲突，先标记问题并询问维护者；在得到答复前不得继续。

这些名称属于标准角色，Issue 跟踪器中实际使用的标签字符串可能不同。相应映射应当已经配置；没有时运行 /setup-matt-pocock-skills。

状态转换：无标签 Issue 通常先进入 needs-triage，再从这里转入 needs-info、ready-for-agent、ready-for-human 或 wontfix。报告者回复后，needs-info 返回 needs-triage。维护者可以随时覆盖状态；遇到看起来异常的转换时，先指出并询问，再继续处理。

调用方式

维护者运行 /triage，并使用自然语言说明需求。理解请求后直接执行。例如：

• “把所有需要我关注的内容列出来”
• “我们看看 #42”（Issue 或 PR）
• “把 #42 移到 ready-for-agent”
• “哪些任务已经可以交给 Agent？”

展示需要关注的内容

查询 Issue 跟踪器，分成三组展示，每组按最旧优先排序：

1. 无标签——从未分诊。
2. needs-triage——正在评估。
3. needs-info，且报告者在上次分诊记录后有新活动——需要重新评估。

PR 属于分诊范围时，把外部 PR 放入相应分组，并在每行标记 [PR] 或 [issue]。发现列表只展示外部 PR；谁属于外部人员由跟踪器配置定义。协作者正在推进的 PR 不属于分诊工作。此过滤仅用于发现列表；用户明确指定某个 PR 时，无论作者是谁都必须分诊。

显示每组数量，并为每项提供一行摘要。让维护者选择下一项。

分诊指定 Issue 或 PR

1. 收集上下文。 阅读完整 Issue 或 PR，包括正文、评论、标签、作者和日期；对于 PR，还要阅读 diff。解析以前的分诊记录，避免重复询问已经解决的问题。使用项目领域术语表探索代码库，并遵守所涉及区域的 ADR。针对代码库执行两项检查：(a) 重复性——按领域概念搜索是否已经实现所请求行为，不能只搜索请求原文；同时报告检查过的位置。已经存在时，按“已经实现”的 wontfix 处理，参见步骤 5。(b) 过去的拒绝记录——读取 .out-of-scope/*.md，展示与当前请求相似的记录。

2. 提出建议。 向维护者说明建议采用的类别和状态及其理由，同时给出与请求有关的代码库摘要，包括该能力是否已经实现。等待维护者指示。

3. 验证主张。 进入追问前，先检查请求中的主张是否成立。对于 bug，按照报告者步骤复现。对于 PR，检出代码并运行相关测试或命令，确认 diff 是否实现了其声称的行为。报告结果：已确认（附代码路径）、验证失败，或信息不足；信息不足是强烈的 needs-info 信号。经过确认的验证会显著提高 Agent 简报质量。

4. 持续追问（需要时）。 请求仍需补充时，同时运行 /grilling 和 /domain-modeling Skills。每次只问一个问题，把请求逐步打磨完整；决策产生时同步打磨领域术语，并更新 CONTEXT.md 或 ADR。

5. 应用结果：

   • ready-for-agent——发布一条 Agent 任务简报评论，格式参见 AGENT-BRIEF.md。
   • ready-for-human——使用与 Agent 简报相同的结构，但说明无法委托的原因，例如需要判断、外部访问权限、设计决策或人工测试。
   • needs-info——按照下方模板发布分诊记录。
   • wontfix——关闭请求，评论内容根据原因决定：
     • 已经实现——代码库中已经存在所请求变更。指出具体位置；不要写入 .out-of-scope/。该知识库记录的是被拒绝的请求，不是已经实现的功能。
     • 拒绝 bug——礼貌说明原因，然后关闭。
     • 拒绝 enhancement——写入 .out-of-scope/，在评论中链接该记录，然后关闭，参见 OUT-OF-SCOPE.md。
   • needs-triage——应用对应角色。有部分进展时，可以选择留下评论。

快速覆盖状态

维护者说“把 #42 移到 ready-for-agent”时，相信其判断，直接应用角色。先确认即将执行的操作，包括角色变化、是否评论、是否关闭，然后执行。跳过持续追问。没有经过追问就移到 ready-for-agent 时，询问维护者是否希望编写 Agent 任务简报。

Needs-info 模板

## Triage Notes

**What we've established so far:**

- point 1
- point 2

**What we still need from you (@reporter):**

- question 1
- question 2

把追问过程中已经确定的全部内容写入 “established so far”，避免成果丢失。问题必须具体且可执行，不能只写“请提供更多信息”。

继续以前的会话

Issue 或 PR 中已有分诊记录时，先阅读记录，检查报告者是否已经回答未解决的问题，再展示更新后的整体情况。不要重复询问已经解决的问题。