mcpField
T
triage

triage

github.com/nstaab1开发049 次安装3 周前更新
代码仓库

关于 triage

triage 是一项技能，用于按既定角色和状态处理项目议题，以及配置范围内的外部 PR。它收集背景、建议状态、核实问题，并落实维护者的决定。

主要功能

  1. 01分配类别角色和状态角色
  2. 02审查议题及配置范围内的外部 PR
  3. 03检查是否已有实现及曾被拒绝的请求
  4. 04核实错误报告或 PR 变更
  5. 05应用处理结果并记录分流说明

适用场景

  1. 01整理需要维护者关注的议题
  2. 02在分派前评估错误报告
  3. 03为 Agent 或人工处理准备说明
  4. 04记录待补信息或被拒绝的请求

安装

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

$npx skills add https://github.com/nstaab1/nathan-agent-skills --skill triage

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

包含的文件

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

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

详细介绍

分诊

将项目问题跟踪器中的问题按分诊角色组成的小型状态机流转。

如果此仓库将外部拉取请求视为需求提交入口（参见问题跟踪器配置），分诊也涵盖这些请求：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 应对差异执行下一步操作；ready-for-human 表示已准备好由人工合并。

每个完成分诊的问题都应恰好有一个类别角色和一个状态角色。如果状态角色冲突，请标记并先询问维护者，再进行任何其他操作。

这些是规范角色名称。问题跟踪器中实际使用的标签字符串可能有所不同。映射信息应已提供给你。如果没有，请告知用户运行 /setup-agent-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