mcpField
T
triage

triage

github.com/ouyangjiahong26开发579 次安装2 天前更新
代码仓库

关于 triage

一个用于 issue tracker 分诊的技能，面向负责评估 issue 和 PR 的维护者。它按分类与状态标签管理流程，并要求先核实主张、征求维护者指示，再应用结论。

主要功能

  1. 01按分类和状态角色分诊
  2. 02展示待处理的 issue 与 PR
  3. 03检查代码库中的重复实现和拒绝记录
  4. 04复现 bug 并验证 PR diff
  5. 05生成 agent brief 或补充信息请求
  6. 06要求分诊评论带 AI 贡献标记

适用场景

  1. 01整理待评估的 issue 和外部 PR
  2. 02核实缺陷报告或 PR 声明
  3. 03将请求分派给 Agent 或人工处理
  4. 04跟进报告人补充信息后的分诊

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/ouyangjiahong26/skills --skill triage

安装后在 Claude Code 中输入/triage确认已加载。

附带文件AGENT-BRIEF.mdOUT-OF-SCOPE.md

详细介绍

来自项目 README

Triage

把项目 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 辅助完成。

参考文档

角色

两个分类角色：

  • 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 应当恰好带一个分类角色和一个状态角色。状态角色冲突时，先标出来问维护者，再做任何其他事。

以上是标准角色名：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，按时间从旧到新呈现三类：

  1. 无 label：从未分诊。
  2. needs-triage：评估进行中。
  3. needs-info 且报告人自上次分诊记录后有新活动：需要重新评估。

PR 在范围内时，把它们也纳入这些类别，每行标注 [PR] 或 [issue]。发现过程只暴露外部 PR（tracker 配置定义了谁算外部），协作者进行中的 PR 不是分诊工作。这只在发现阶段过滤。明确点名的 PR 不论作者一律分诊。

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

分诊某个具体的 issue 或 PR

  1. 收集上下文。完整读 issue 或 PR（正文、评论、label、作者、日期，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”，一次只问一个问题，把请求问成形，同时打磨领域术语。决策落定时同步更新 CONTEXT.md/ADR。

  5. 应用结论：

    • 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 上已有分诊记录，读它们，检查报告人是否已回答了任何遗留问题，呈现更新后的情况再继续。别重复问已解决的问题。

评论

支持 Markdown