# Triage

> 通过分流角色的状态机处理 Issue 和外部 PR —— 包括分类、验证、必要时盘问，并撰写可直接交付给智能体的简报。触发词：分流、triage、issue 分类、bug 处理、bug 报告、功能请求。

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

---


# 分流（Triage）

## 适用时机

当工作流匹配以下用户请求时使用：通过分流角色的状态机处理 Issue 和外部 PR —— 包括分类、验证、必要时盘问，并撰写可直接交付给智能体的简报。


_来源：[mattpocock/skills](https://github.com/mattpocock/skills)（MIT）。_

让项目 Issue 跟踪器上的 Issue 经过一组小型分流角色组成的状态机。

如果本仓库将外部拉取请求（PR）视为请求面（参见 Issue 跟踪器配置），分流也覆盖 PR：**PR 即附带代码的 Issue** —— 角色相同、状态相同、机器相同，仅有少量差异在下方“针对 PR”处注明。请根据跟踪器配置，将裸 `#42` 解析为 Issue 或 PR。

在分流期间发布到 Issue 跟踪器的每条评论或每个 Issue，**必须**以以下免责声明开头：

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

## 参考文档

- [AGENT-BRIEF.md](AGENT-BRIEF.md) — 如何撰写可持久保存的智能体简报
- [OUT-OF-SCOPE.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 应只携带一个分类角色和一个状态角色。若状态角色冲突，加标记并向维护者确认再做其他操作。

以上为标准角色名 —— 实际在 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”
- “哪些是智能体可以领走的？”

## 显示需要关注的事

查询 Issue 跟踪器，按时间从最旧到最新呈现三个分组：

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 实现了其声称的内容 —— 检出代码并运行相关测试或命令。报告结果：已确认（附代码路径）、复现失败、或证据不足（强 `needs-info` 信号）。已确认的验证会显著强化智能体简报的可信度。

4. **盘问（如有必要）。** 若请求需要细化，可同时运行 `/grilling` 和 `/domain-modeling` 技能 —— 一次一个问题地打磨，明确领域术语，并在决策落定时就地更新 `CONTEXT.md` / ADR。

5. **应用结果：**
   - `ready-for-agent` — 在评论中发布智能体简报（[AGENT-BRIEF.md](AGENT-BRIEF.md)）。
   - `ready-for-human` — 结构与智能体简报相同，但需注明为何不能委派（需要判断、外部访问、设计决策、人工测试等）。
   - `needs-info` — 发布分流记录（见下方模板）。
   - `wontfix` — 关闭 Issue，评论视*原因*而定：
     - **已经实现** — 该改动在代码库中已存在。指出其所在位置；**不要**写入 `.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`，请询问是否需要撰写智能体简报。

## 需要补充信息模板

```markdown
## Triage Notes

**What we've established so far:**

- point 1
- point 2

**What we still need from you (@reporter):**

- question 1
- question 2
```

将在盘问中已解决的全部内容归入“目前已确认的事”，避免工作丢失。问题必须具体可执行，而非“请提供更多信息”。

## 恢复上一会话

若 Issue 或 PR 上已有先前的分流记录，先阅读并检查报告者是否已回答未解决问题，再呈现一份更新的整体情况，再继续。不要重复提问已经解决的问题。


## 限制

- 当工作流指定了上游工具、账号、API 密钥或本地环境时，需具备相应配置。
- 未经用户明确授权，不会执行破坏性、生产环境、付费或对外发送消息的操作。
- 将生成的内容或建议当作最终结论之前，需基于用户的真实资料源进行验证。