triage

name	triage
description	让 issue 和外部 PR 走过一个由分诊角色构成的状态机——分类、验证、必要时拷问，并撰写可供智能体使用的简报。
disable-model-invocation	true

Triage

让项目问题追踪器上的 issue 走过一个由分诊角色构成的小型状态机。

如果本仓库把外部拉取请求（PR）当作一种请求载体（见问题追踪器配置），分诊也涵盖它们：PR 就是附带了代码的 issue——相同的角色、相同的状态、相同的机器，只有下面标注“for a PR”的少数差异。按追踪器配置将一个裸的 #42 解析为 issue 或 PR。

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

> *This was generated by AI during triage.*

参考文档

• AGENT-BRIEF.md —— 如何撰写具持久性的智能体简报
• OUT-OF-SCOPE.md —— .out-of-scope/ 知识库如何运作

角色

两个类别角色：

• bug —— 某处坏了
• enhancement —— 新功能或改进

五个状态角色：

• needs-triage —— 维护者需要评估
• needs-info —— 等待报告者提供更多信息
• ready-for-agent —— 已完全规格化，可交给 AFK 智能体
• ready-for-human —— 需要人类实现
• wontfix —— 不会被处理

对于 PR，同样的状态是针对所附代码来解读的：ready-for-agent 表示已附上简报、智能体应对该 diff 采取下一步行动；ready-for-human 表示它已可供人类合并。

每个已分诊的 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”
• “有什么已经可以让智能体接手的？”

展示需要关注的内容

查询问题追踪器并呈现三个分组，最旧的在前：

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. 验证声明。 在任何拷问之前，检查该声明是否站得住脚。对于缺陷，按报告者的步骤复现它。对于 PR，确认 diff 确实做到了它所声称的——检出它、运行相关的测试或命令。报告发生了什么：已确认（附代码路径）、失败，或细节不足（一个强烈的 needs-info 信号）。一次已确认的验证能造就强得多的智能体简报。

4. 拷问（如有需要）。 如果请求需要充实，同时运行 /grilling 和 /domain-modeling 技能——一次一个问题地把它拷问成型，锐化领域术语，并在决策落定时就地更新 CONTEXT.md/ADR。

5. 应用结果：

   • ready-for-agent —— 发布一条智能体简报评论（AGENT-BRIEF.md）。
   • ready-for-human —— 结构与智能体简报相同，但注明为何无法委派（判断决策、外部访问、设计决策、手动测试）。
   • needs-info —— 发布分诊笔记（模板见下）。
   • wontfix —— 关闭，评论内容取决于为什么：
     • 已实现 —— 该改动已存在于代码库中。指向它所在的位置；不要写入 .out-of-scope/（那个知识库是给被拒绝的请求的，不是给已构建的）。
     • 拒绝（缺陷） —— 礼貌地解释，然后关闭。
     • 拒绝（增强） —— 写入 .out-of-scope/，从评论中链接到它，然后关闭（OUT-OF-SCOPE.md）。
   • needs-triage —— 应用该角色。如果有部分进展可选择性地加评论。

快速状态覆盖

如果维护者说“把 #42 移到 ready-for-agent”，相信他们并直接应用该角色。确认你将要做的事（角色更改、评论、关闭），然后行动。跳过拷问。如果在没有拷问式会话的情况下移到 ready-for-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 上存在先前的分诊笔记，阅读它们，检查报告者是否已回答任何悬而未决的问题，并在继续前呈现一幅更新后的图景。不要重新询问已解决的问题。