triage

name	triage
description	将 issues 和外部 PRs 移过 triage 角色状态机 —— 分类、验证、必要时进行质询，并编写 agent 可用的摘要。
disable-model-invocation	true

Triage

将项目 issue tracker 上的 issues 移过一个小型的 triage 角色状态机。

如果本仓库将外部 Pull Request 视为请求渠道（参见 issue-tracker 配置），triage 也涵盖它们：PR 是附带代码的 issue —— 相同的角色、相同的状态、相同的状态机，仅有少数标记为"对于 PR"的差异。将裸 #42 解析为 issue 或 PR，取决于 tracker 配置。

Triage 期间发布到 issue tracker 的每条评论或 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 —— 已完全明确，可供 AFK agent 使用
• ready-for-human —— 需要人工实现
• wontfix —— 不予处理

对于 PR，相同状态针对附带代码进行理解：ready-for-agent 表示附有 agent 摘要，agent 应对 diff 采取下一步操作；ready-for-human 表示可供人工合并。

每个经 triage 的 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"
• "有哪些可供 agents 领取的？"

展示需要关注的内容

查询 issue tracker 并按以下三个分组展示，最旧的优先：

1. 未标记 —— 从未经过 triage。
2. needs-triage —— 评估进行中。
3. 自上次 triage 记录以来有报告者活动的 needs-info —— 需要重新评估。

当 PR 在范围内时，将外部 PR 纳入这些分组，并为每行标记 [PR] 或 [issue]。发现仅展示外部 PR（tracker 配置定义了谁算外部）—— 协作者进行中的 PR 不是 triage 工作。此过滤器仅用于发现；明确指定的 PR 无论作者是谁都会被 triage。

显示每个分组的数量和每项的一句话摘要。让维护者选择。

对特定 issue 或 PR 进行 Triage

1. 收集上下文。 读取完整的 issue 或 PR（正文、评论、标签、作者、日期；对于 PR，还包括 diff）。解析之前的 triage 记录，以免重复询问已解决的问题。使用项目的领域词汇表探索代码库，尊重所涉及区域的 ADR。针对代码库运行两项检查：(a) 冗余性 —— 按领域概念搜索所请求行为的现有实现（不仅仅是请求的措辞），并报告你查找的位置。如果找到，它是已实现的情况，按 wontfix 处理（第 5 步）。(b) 之前的拒绝 —— 读取 .out-of-scope/*.md 并找出与此请求类似的任何内容。

2. 建议。 告诉维护者你的类别和状态建议及理由，加上与请求相关的简要代码库摘要 —— 包括是否已实现。等待指示。

3. 验证声明。 在任何质询之前，检查声明是否成立。对于 bug，按报告者的步骤复现。对于 PR，确认 diff 做了它声称做的事情 —— checkout 它，运行相关测试或命令。报告结果：已确认（含代码路径）、未通过、或细节不足（强烈的 needs-info 信号）。已确认的验证会产生更强的 agent 摘要。

4. 质询（如需要）。 如果请求需要充实，同时运行 /grilling 和 /domain-modeling 技能 —— 逐个问题地进行质询，随着决策落地内联更新 CONTEXT.md/ADR。

5. 应用结果：

   • ready-for-agent —— 发布 agent 摘要评论（AGENT-BRIEF.md）。
   • ready-for-human —— 与 agent 摘要结构相同，但注明为何无法委托（判断性决策、外部访问、设计决策、手动测试）。
   • needs-info —— 发布 triage 记录（下方模板）。
   • 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

**目前已确认的内容：**

- 要点 1
- 要点 2

**仍需您提供的信息（@报告者）：**

- 问题 1
- 问题 2

将质询期间已解决的所有内容记录在"目前已确认"下，以免工作丢失。问题必须具体且可操作，而非"请提供更多信息"。

恢复之前的会话

如果 issue 或 PR 上存在之前的 triage 记录，读取它们，检查报告者是否已回答了任何未解决的问题，并在继续之前呈现更新的情况。不要重复询问已解决的问题。