Triage

通过一个小型的分诊角色状态机来推进项目 issue 跟踪器上的 issue。

如果本仓库将外部 pull request 视为一种请求来源，那么分诊同样涵盖它们：一个 PR 就是一个附带了代码的 issue——相同的角色、相同的状态、相同的状态机，只是带有下文标注为"对于 PR"的几处差异。

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

> *This was generated by AI during triage.*

角色

两个分类角色：

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

五个状态角色：

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

每个已分诊的 issue 都应恰好带有一个分类角色和一个状态角色。如果状态角色相互冲突，先标记出来并询问维护者，然后再做其他任何事。

状态转换：未打标签的 issue 通常先进入 needs-triage；从那里它会转向 needs-info、ready-for-agent、ready-for-human 或 wontfix。一旦报告者回复，needs-info 就返回到 needs-triage。

展示需要关注的内容

查询 issue 跟踪器，并呈现三个分组，最旧的在前：

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

为每一项展示数量和一行摘要。让维护者来挑选。

对特定 issue 或 PR 进行分诊

1. 收集上下文。 阅读完整的 issue 或 PR（正文、评论、标签、作者、日期；对于 PR，还包括 diff）。解析任何先前的分诊记录，这样你就不会重复询问已解决的问题。

2. 给出建议。 向维护者说明你对分类和状态的建议及其理由，并附上一份与该请求相关的简要代码库概述。

3. 核实该主张。 在任何拷问之前，先检查该主张是否成立。对于 bug，按报告者的步骤复现它。对于 PR，确认 diff 确实实现了它所声称的内容。

4. 拷问（如有必要）。 如果请求需要充实，一起运行 /grilling 和 /domain-modeling 技能——一次一个问题地把它拷问成形。

5. 应用结果：

   • ready-for-agent — 发布一条代理简报评论。
   • ready-for-human — 与代理简报结构相同，但注明为何无法委派。
   • needs-info — 发布分诊记录。
   • wontfix — 关闭，评论内容取决于原因。

快速状态覆盖

如果维护者说"把 #42 移到 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"之下，这样工作成果不会丢失。