triage

name	triage
description	让 issue 和外部 PR 走过一个由分诊角色构成的状态机——分类、验证、必要时刨根问底地追问，并撰写可供 agent 使用的简报（brief）。
disable-model-invocation	true

分诊（Triage）

让项目 issue tracker 上的 issue 走过一个由分诊角色构成的小型状态机。

如果本仓库把外部 pull request 也当作一个请求来源（见 issue-tracker 配置），分诊也覆盖它们：一个 PR 就是一个附带了代码的 issue——相同的角色、相同的状态、相同的状态机，只有少数几处标注了"对 PR 而言"的差异（见下文）。按 tracker 配置把一个裸的 #42 解析为 issue 还是 PR。

分诊期间发布到 issue tracker 的每一条评论或 issue 都必须 以这条免责声明开头：

> *This was generated by AI during triage.*

参考文档

• AGENT-BRIEF.md — 如何撰写经久耐用的 agent 简报
• OUT-OF-SCOPE.md — .out-of-scope/ 知识库如何运作

角色

两个 分类（category） 角色：

• bug — 有东西坏了
• enhancement — 新功能或改进

五个 状态（state） 角色：

• needs-triage — 维护者需要评估
• needs-info — 等待报告者提供更多信息
• ready-for-agent — 已完全明确，可交给一个离线（AFK）agent
• ready-for-human — 需要人来实现
• wontfix — 不会处理

对 PR 而言，这些相同的状态是对照附带的代码来理解的：ready-for-agent 表示已附上一份简报、应由一个 agent 对该 diff 走下一步；ready-for-human 表示已准备好供人来合并。

每个经过分诊的 issue 都应恰好带有一个分类角色和一个状态角色。如果状态角色之间相互冲突，就把它标出来，并在做任何其他事情之前询问维护者。

这些是规范角色名——issue tracker 中实际使用的标签字符串可能不同。这个映射应当已经提供给你——如果没有，运行 /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 tracker，并呈现三个桶，最旧的在前：

1. Unlabeled（未打标签）——从未被分诊过。
2. needs-triage——评估进行中。
3. needs-info 且自上次分诊笔记以来报告者有活动——需要重新评估。

当 PR 在范围内时，把外部 PR 也纳入这些桶，并给每一行标记 [PR] 或 [issue]。发现（discovery）只浮现 外部 PR（tracker 配置定义了谁算外部）——一位协作者进行中的 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 技能——一次一个问题地把它追问成形，打磨领域术语，并在决策落地时就地更新 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 上存在先前的分诊笔记，就阅读它们，检查报告者是否已回答任何遗留问题，并在继续之前呈现一幅更新后的图景。不要重复追问已解决的问题。