# Triage

> 让项目中的 issues 和外部 PR 沿着一组 triage 角色的状态机流转——分类、验证、必要时追问(grill),并写出 agent-ready 的 brief。

- Skill: `gongyijie85/triage` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add gongyijie85/triage`
- Raw SKILL.md: https://api.skillmd.com/api/skills/gongyijie85/triage/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: gongyijie85 (https://skillmd.com/u/gongyijie85)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/gongyijie85/triage

---


# 分流(Triage)

让项目 issue tracker 上的 issues 沿着小型 triage 角色状态机流转。

如果本仓库把外部 pull request 也当作请求入口(参见 issue-tracker 配置),triage 同样覆盖它们:**PR 就是附带了代码的 issue**——同样的角色、同样的状态、同样的状态机,只是下面标注了几处 "for a PR" 的差异。根据 tracker 配置把裸 `#42` 解析为 issue 或 PR。

triage 期间发布到 issue tracker 的每条评论或 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/` 知识库如何运作

## 角色

两个 **分类(category)** 角色:

- `bug` — 某样东西坏了
- `enhancement` — 新功能或改进

五个 **状态(state)** 角色:

- `needs-triage` — 维护者需要评估
- `needs-info` — 等待报告者提供更多信息
- `ready-for-agent` — 已完整说明,可供 AFK agent 接手
- `ready-for-human` — 需要人类实现
- `wontfix` — 不会被处理

对于 PR,同样的状态要对照其附带的代码来解读:`ready-for-agent` 意味着已附上 brief,agent 应对 diff 采取下一步行动;`ready-for-human` 意味着已准备好由人类合并。

每个经过 triage 的 issue 应恰好携带一个 category 角色和一个 state 角色。如果 state 角色冲突,先标记出来并向维护者询问,再做任何其它事情。

这些是规范角色名——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)** — 从未被 triage 过。
2. **`needs-triage`** — 评估进行中。
3. **`needs-info` 且自上次 triage 笔记以来报告者有新活动** — 需要重新评估。

当 PR 在范围内时,把外部 PR 纳入这些桶,并为每行标注 `[PR]` 或 `[issue]`。发现(discovery)只暴露_外部_PR(tracker 配置定义谁算外部)——协作者进行中的 PR 不是 triage 工作。这个过滤只作用于发现阶段;明确点名的 PR 无论作者是谁都始终会被 triage。

显示每个条目的计数和一行摘要。让维护者挑选。

## Triage 一个具体的 issue 或 PR

1. **收集上下文。** 通读完整的 issue 或 PR(正文、评论、标签、作者、日期;PR 还要看 diff)。解析任何先前的 triage 笔记,避免重复询问已解决的问题。使用项目的领域词汇表探索代码库,尊重所触及区域的 ADR。对照代码库执行两项检查:(a) **冗余(redundancy)**——按领域概念(而不只是请求的措辞)搜索请求的行为是否已有实现,并报告你查找过哪里。如果找到了,它就是一个已实现的 `wontfix`(第 5 步)。(b) **先前拒绝(prior rejection)**——阅读 `.out-of-scope/*.md`,指出任何与本次请求相似的条目。

2. **给出建议。** 把你的 category 和 state 建议连同理由告诉维护者,并附上与请求相关的简要代码库摘要——包括它是否已实现。等待指示。

3. **验证主张。** 在任何 grilling 之前,先核实主张是否成立。对于 bug,按报告者的步骤复现它。对于 PR,确认 diff 确实做了它所声称的事——checkout 它,运行相关测试或命令。报告发生了什么:已确认(附代码路径)、失败,或细节不足(一个强烈的 `needs-info` 信号)。确认过的验证能形成强得多的 agent brief。

4. **Grill(如需要)。** 如果请求需要充实,调用 skill tool 两次,分别使用 "grilling" 和 "domain-modeling"——一轮一轮地把它追问成可用的形状,随着决策落地同步打磨领域术语并更新 `CONTEXT.md`/ADR。

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

## 快速状态覆盖

如果维护者说"把 #42 移到 ready-for-agent",信任他们并直接应用该角色。确认你将要做的事(角色变更、评论、关闭),然后执行。跳过 grilling。如果在没有 grilling 会话的情况下移动到 `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
```

把 grilling 期间解决的所有内容记录在 "established so far" 下,以免工作丢失。问题必须具体且可操作,而不是"请提供更多信息"。

## 恢复之前的会话

如果 issue 或 PR 上已有先前的 triage 笔记,阅读它们,检查报告者是否回答了任何未决问题,并在继续之前呈现更新后的图景。不要重复询问已解决的问题。