Triage

---
name: triage
description: 将 issue 和外部 PR 推过一组分诊角色的状态机——分类、验证、必要时盘问，并写出 agent 就绪的任务简报。
disable-model-invocation: true
---

# 分类（Triage）

让项目问题跟踪器上的 issue 走一遍由分类角色组成的小型状态机。

如果本仓库把外部拉取请求（PR）也当作请求入口（见 issue-tracker 配置），分类也覆盖它们：**PR 就是带着代码的 issue**——同样的角色、同样的状态、同样的状态机，只有少数几处下面标注了"仅限 PR"的差异。根据跟踪器配置，把裸的 `#42` 解析为 issue 或 PR。

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

```
> *This was generated by AI during triage.*
```

## 参考文档

- [AGENT-BRIEF.md](AGENT-BRIEF.md) — 如何写出耐用的 agent brief
- [OUT-OF-SCOPE.md](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` 意味着已附上 brief，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"
- "有哪些是 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. **验证主张。** 在任何盘问之前，先确认主张站得住脚。对 bug，按报告人的步骤复现。对 PR，确认 diff 确实做了它声称的事——checkout 下来，运行相关测试或命令。报告发生了什么：已确认（附代码路径）、失败、或细节不足（强烈的 `needs-info` 信号）。确认过的验证能产生强得多的 agent brief。

4. **盘问（如需）。** 如果请求需要补充打磨，调用 Skill 工具两次，分别传入 "grilling" 和 "domain-modeling"——一轮一轮地把它盘问成型，随着决策落定，同步打磨领域术语并更新 `GLOSSARY.md`/ADR。

5. **应用结果：**
   - `ready-for-agent` — 发布 agent brief 评论（[AGENT-BRIEF.md](AGENT-BRIEF.md)）。
   - `ready-for-human` — 结构同 agent brief，但要注明为什么不能委派（需要判断、外部访问、设计决策、人工测试）。
   - `needs-info` — 发布分类笔记（模板见下）。
   - `wontfix` — 关闭，评论内容取决于*原因*：
     - **已实现** — 代码库中已存在该改动。指出它在哪里；**不要**写入 `.out-of-scope/`（那个知识库是给*被拒绝*的请求的，不是给已实现的）。
     - **被拒绝（bug）** — 礼貌解释，然后关闭。
     - **被拒绝（enhancement）** — 写入 `.out-of-scope/`，在评论里链接到它，然后关闭（[OUT-OF-SCOPE.md](OUT-OF-SCOPE.md)）。
   - `needs-triage` — 应用该角色。如果有部分进展，可选加一条评论。

## 快速状态覆盖

如果维护者说"把 #42 移到 ready-for-agent"，相信他们，直接应用该角色。确认你将要做的（角色变更、评论、关闭），然后行动。跳过盘问。如果在没有盘问会话的情况下移到 `ready-for-agent`，问他们是否想写 agent brief。

## Needs-info 模板

```markdown
## 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 上已有先前的分类笔记，读它们，检查报告人是否回答了未解决的问题，并在继续之前呈现更新后的图景。不要重复问已解决的问题。