About triage
An issue-triage skill for maintainers assessing issues and PRs. It organizes work with classification and status labels, and verifies claims before applying an outcome after maintainer direction.
Key features
- 01Triage with classification and status roles
- 02List pending issues and PRs
- 03Check for existing implementations and rejection records
- 04Reproduce bugs and verify PR diffs
- 05Prepare agent briefs or requests for more information
- 06Require an AI contribution marker in triage comments
Use cases
- 01Review issues and external PRs awaiting triage
- 02Verify bug reports or PR claims
- 03Route work to an agent or a human
- 04Resume triage after reporters provide information
Install
Copy the command and run it in a terminal.
npx skills add https:/After installing, type/triagein Claude Code to confirm it loaded.
Bundled filesAGENT-BRIEF.mdOUT-OF-SCOPE.md
Details
From the project READMETriage
把项目 issue tracker 上的 issue 推过一台小型分诊状态机。
如果本仓库把外部 PR 也当作请求入口（见 issue-tracker 配置），分诊同样覆盖它们。PR 就是带代码的 issue，同样的角色、同样的状态、同一台机器，下文几处标了“针对 PR”的差异。裸 #42 按 tracker 配置解析为 issue 或 PR。
分诊期间发到 issue tracker 的每条评论或 issue，必须以下面这行 AI 贡献标记开头：
> **[AI Generated]** 本评论由 AI 完成。
分诊评论写的是 agent 自己的判断，用“由 AI 完成”。整段只是转述维护者的结论时，改用 > **[AI Assisted]** 本评论由 AI 辅助完成。
参考文档
- AGENT-BRIEF.md：如何写出耐用的 agent brief
- OUT-OF-SCOPE.md：
.out-of-scope/知识库如何运作
角色
两个分类角色：
bug：有东西坏了enhancement：新功能或改进
五个状态角色：
needs-triage：维护者需要评估needs-info：等报告人补充信息ready-for-agent：任务要求完整，可交给 AFK agentready-for-human：需要人来实现wontfix：不会处理
针对 PR，这些状态对照其附带的代码来读：ready-for-agent 表示已附上 brief，agent 应在 diff 上推进下一步。ready-for-human 表示可由人合并。
每个分诊过的 issue 应当恰好带一个分类角色和一个状态角色。状态角色冲突时，先标出来问维护者，再做任何其他事。
以上是标准角色名：issue tracker 里实际的 label 字符串可能不同。映射关系应当已提供。如未提供，叫用户跑 /setup-ouyangjiahong-skills。
状态流转：无 label 的 issue 通常先进 needs-triage。从那里移到 needs-info、ready-for-agent、ready-for-human 或 wontfix。报告人回复后，needs-info 回到 needs-triage。维护者可随时覆盖：看起来异常的流转要先标出并询问，再动手。
GitHub Project 同步
GitHub 仓库若配置了 Project，分诊时按 github-project skill 的 references/sync-discipline.md 同步工作状态，状态映射取其状态迁移节。needs-info 只表示信息不足，不替代 Project Status。提醒用户跑 /github-project 同步状态，并复核结果。
调用
维护者发起 /triage，用自然语言描述要做的事。解读请求并执行。例如：
- “看看有什么要我处理的”
- “看一下 #42”（issue 或 PR）
- “把 #42 移到 ready-for-agent”
- “有哪些 agent 可以认领的？”
展示待处理项
查询 issue tracker，按时间从旧到新呈现三类：
- 无 label：从未分诊。
needs-triage：评估进行中。needs-info且报告人自上次分诊记录后有新活动：需要重新评估。
PR 在范围内时，把它们也纳入这些类别，每行标注 [PR] 或 [issue]。发现过程只暴露外部 PR（tracker 配置定义了谁算外部），协作者进行中的 PR 不是分诊工作。这只在发现阶段过滤。明确点名的 PR 不论作者一律分诊。
展示数量和每项的一行摘要，让维护者挑选。
分诊某个具体的 issue 或 PR
-
收集上下文。完整读 issue 或 PR（正文、评论、label、作者、日期，PR 还要读 diff）。解析已有的分诊记录，避免重复问已解决的问题。用项目的领域术语表探索代码库，遵守相关区域的 ADR。对着代码库做两项检查：(a) 重复：按领域概念（而非请求的字面措辞）搜索请求的行为是否已有实现，报告你查过哪里。若已存在，这是已实现的
wontfix（第 5 步）。(b) 曾被拒绝：读.out-of-scope/*.md，浮出与本请求相似的条目。 -
给出建议。告诉维护者你建议的分类和状态，附上理由，并给出与本请求相关的代码库摘要，包括是否已实现。等维护者指示。
-
验证主张。在任何追问之前，先核实主张是否成立。bug 按报告人的步骤复现。PR 确认 diff 确实做了它声称的事：checkout 出来，跑相关测试或命令。报告结果：已确认（附代码路径）、复现失败、细节不足（强烈的
needs-info信号）。一次成功的验证会让 agent brief 更有说服力。 -
追问（如需）。若请求需要充实，调用两次 Skill 工具，分别传入“grilling”和“domain-modeling”，一次只问一个问题，把请求问成形，同时打磨领域术语。决策落定时同步更新
CONTEXT.md/ADR。 -
应用结论：
ready-for-agent：发一条 agent brief 评论（AGENT-BRIEF.md）。ready-for-human：与 agent brief 同结构，但说明为什么不能委派（需要判断、外部权限、设计决策、人工测试）。needs-info：发分诊记录（模板见下）。wontfix：关闭，评论内容取决于为什么：- 已实现：改动已在代码库中存在。指出它所在的位置。不要写入
.out-of-scope/（那个知识库是给被拒绝的请求用的，不是已建好的功能）。 - 被拒（bug）：礼貌解释，然后关闭。
- 被拒（enhancement）：写入
.out-of-scope/，评论里链接它，然后关闭（OUT-OF-SCOPE.md）。
- 已实现：改动已在代码库中存在。指出它所在的位置。不要写入
needs-triage：套上角色。若有部分进展，可选地留条评论。
快速状态覆盖
若维护者说“把 #42 移到 ready-for-agent”，信任这个判断，直接套上角色。确认将要做的动作（角色变更、评论、关闭），然后执行。跳过追问。若未经过追问就移到 ready-for-agent，问要不要写一份 agent brief。
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”，别让工作白费。问题必须具体、可行动，不能是“请提供更多信息”。
恢复之前的会话
若 issue 或 PR 上已有分诊记录，读它们，检查报告人是否已回答了任何遗留问题，呈现更新后的情况再继续。别重复问已解决的问题。