mcpField
T
triage

triage

github.com/mattpocockAgent 工作流305.7k1.0M 次安装1 天前更新
代码仓库

关于 triage

用于在问题跟踪器上处理 issue 与 PR 分诊的 skill。它通过一组类别和状态角色推进分诊流程，并在操作前检查代码库中是否已存在对应实现。面向维护者使用，适合需要统一管理请求队列的项目。

主要功能

  1. 01类别角色 bug 与 enhancement 的分配
  2. 02状态角色的转换与冲突检测
  3. 03检查代码库中是否已实现相应功能
  4. 04将已拒绝的需求记录到 .out-of-scope/
  5. 05为 PR 复用同一状态机并验证差异

适用场景

  1. 01列出需要维护者关注的未分诊 issue
  2. 02将已明确的 issue 标记为 ready-for-agent 并生成 agent brief
  3. 03关闭重复或已实现的请求并附上说明

安装

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

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

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

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

AGENT-BRIEF.md
OUT-OF-SCOPE.md
agents/
openai.yaml

详细介绍

分诊（Triage）

通过一个由分诊角色组成的小型状态机，推进问题追踪器上议题的流转。

如果本仓库将外部 PR 视为请求入口（参见问题追踪器配置），分诊同样覆盖这些 PR：PR 就是附带代码的议题，使用相同的角色、相同的状态和相同的状态机，区别之处见下文标注“针对 PR”的条目。对于裸的 #42，按追踪器配置将其解析为议题或 PR。

在分诊期间发布到问题追踪器的每条评论或议题，必须以下面的免责声明开头：

> *This was generated by AI during triage.*

参考文档

角色

两个类别角色：

  • bug：功能出现故障
  • enhancement：新功能或改进

五个状态角色：

  • needs-triage：维护者需要评估
  • needs-info：等待报告者提供更多信息
  • ready-for-agent：规格完整，可交由无人值守（AFK）的 Agent 处理
  • ready-for-human：需要人工实现
  • wontfix：不予处理

对于 PR，这些状态针对所附代码来理解：ready-for-agent 表示已附带简报，Agent 应对 diff 执行下一步；ready-for-human 表示已准备好由人工合并。

每个经过分诊的议题应恰好带有一个类别角色和一个状态角色。若状态角色相互冲突，需标记出来，并先询问维护者，再进行任何其他操作。

以上为标准角色名称。问题追踪器中实际使用的标签字符串可能不同，映射关系应已提供给你。若未提供，请告知用户运行 /setup-matt-pocock-skills。

状态流转：未打标签的议题通常先进入 needs-triage；之后可转为 needs-info、ready-for-agent、ready-for-human 或 wontfix。报告者回复后，needs-info 会回到 needs-triage。维护者可随时覆盖任何流转；对看起来异常的流转需标记出来，并在继续前询问。

调用方式

维护者调用 /triage，并用自然语言描述需求。理解该请求后执行。示例：

  • “给我看所有需要我关注的内容”
  • “看看 #42”（议题或 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) 冗余检查：按领域概念（而非请求的措辞）搜索是否已存在该请求行为的实现，并报告你搜索过的位置。若已存在，则按第 5 步将其作为已实现的 wontfix 处理。(b) 既往拒绝检查：阅读 .out-of-scope/*.md，找出与本请求相似的条目并告知维护者。

  2. 给出建议。 告知维护者你判定的类别和建议结论，并说明理由，同时简要概述代码库中与请求相关的情况（包括是否已实现）。等待维护者指示。

  3. 验证声明。 在进行任何拷问式追问（grilling）之前，先确认声明成立。对于 bug，按照报告者的步骤复现。对于 PR，确认 diff 确实实现了其声称的功能：检出代码，运行相关测试或命令。报告结果：已确认（附代码路径）、失败，或信息不足（这是强烈的 needs-info 信号）。经过确认的验证会让 Agent 任务简报更有说服力。

  4. 拷问式追问（如有需要）。 若请求需要进一步细化，请两次调用 Skill 工具，分别用于 "grilling" 和 "domain-modeling"。每次只提出一轮问题，逐步打磨请求；在决策确定时，就地厘清领域术语并更新 GLOSSARY.md/ADR。

  5. 执行结果处理：

    • ready-for-agent：发布 Agent 任务简报评论（AGENT-BRIEF.md）。
    • ready-for-human：结构与 Agent 任务简报相同，但需说明为何无法交由 Agent 执行（判断性决策、外部访问、设计决策、人工测试）。
    • needs-info：发布分诊笔记（模板见下文）。
    • 对于 wontfix，关闭 Issue，评论内容取决于原因：
      • 已实现：代码库中已存在该变更。指明其位置；不要写入 .out-of-scope/（该知识库仅用于被拒绝的请求，而非已实现的功能）。
      • 被拒绝（bug）：给出礼貌的解释，然后关闭。
      • 被拒绝（功能增强）：写入 .out-of-scope/，在评论中链接到该记录，然后关闭（OUT-OF-SCOPE.md）。
    • needs-triage：应用对应角色标签。若有部分进展，可选择添加评论。

快速状态覆盖

若维护者说"将 #42 移至 ready-for-agent"，应相信其判断并直接应用对应角色。在执行前确认即将进行的操作（角色变更、评论、关闭），然后再执行。跳过拷问式追问。若要在未经过拷问的情况下移至 ready-for-agent，应询问维护者是否要编写 Agent 任务简报。

需要更多信息的模板

## 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 上已有先前的分诊笔记，请阅读这些笔记，检查报告者是否已回答任何未决问题，并在继续之前呈现更新后的情况。不要重复询问已解决的问题。

评论

支持 Markdown