mcpField
T
triage

triage

github.com/nulfrog开发038 次安装2 周前更新
代码仓库

关于 triage

供维护者使用的分诊技能，将项目问题按类别和状态推进，并在需要时核实问题、收集信息或撰写 Agent 简报。它依据项目配置处理标签，并可按配置将外部 PR 纳入分诊。

主要功能

  1. 01按类别与状态管理问题分诊流程
  2. 02汇总待处理、待评估及有新回复的问题
  3. 03检查代码以核实问题与既有实现
  4. 04撰写 Agent 简报或补充信息请求
  5. 05按项目配置处理外部 PR

适用场景

  1. 01查看需要维护者关注的问题
  2. 02评估并更新指定问题或 PR 的状态
  3. 03为可交由 Agent 处理的问题准备简报

安装

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

$npx skills add https://github.com/nulfrog/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，还要查看差异）。解析之前的分诊备注，避免重复询问已解决的问题。使用项目的领域术语表探索代码库，并遵循该区域的 ADR。针对代码库进行两项检查：（a）冗余检查：按领域概念（而非仅按请求中的措辞）搜索是否已有所需行为的实现，并说明你查找过哪些位置。如果找到了，这属于已经实现的 wontfix（第 5 步）。（b）之前的拒绝：阅读 .out-of-scope/*.md，指出其中是否有与此请求相似的记录。

  2. 提出建议。 告知维护者你的分类和状态建议，并说明理由；同时简要总结与请求相关的代码库情况（包括是否已经实现）。等待指示。

  3. 验证主张。 在提出一连串问题之前，先检查主张是否成立。对于 bug，根据报告者提供的步骤复现。对于 PR，确认差异是否实现了其声称的效果：检出代码并运行相关测试或命令。报告结果：已确认（附代码路径）、未能确认，或信息不足（这是强烈的 needs-info 信号）。确认验证结果后，Agent 简报会有力得多。

  4. 追问（如有需要）。 如需进一步完善请求，调用 Skill 工具两次，分别用于 "grilling" 和 "domain-modeling"，每轮提出一组问题，逐步明确领域术语，并在达成决定时同步更新 CONTEXT.md/ADR。

  5. 落实结果：

    • ready-for-agent：发布 Agent 简报评论（AGENT-BRIEF.md）。
    • ready-for-human：使用与 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 简报。

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

将追问过程中已明确的所有内容记录在“目前已确定”部分，以免遗漏。问题必须具体且可执行，不要问“请提供更多信息”。

恢复之前的会话

如果 issue 或 PR 上有之前的分诊备注，请先阅读，并检查报告者是否已回答尚未解决的问题，然后在继续之前说明最新情况。不要重复询问已解决的问题。

评论

支持 Markdown