mcpField
T
triage

triage

github.com/marcioaltoe开发043 次安装今天更新
代码仓库

关于 triage

triage 是一项用于按角色和状态流转处理项目问题跟踪器中议题的技能，也可按配置处理外部 PR。它包含信息收集、建议状态、验证问题及发布分类结果的步骤。

主要功能

  1. 01按类别和状态为议题分类
  2. 02按配置将外部 PR 纳入分流
  3. 03收集议题、评论、标签及代码变更
  4. 04检查重复实现与既往拒绝记录
  5. 05发布分流说明或 Agent 简报

适用场景

  1. 01查看需要维护者关注的议题
  2. 02评估指定议题或 PR 的处理状态
  3. 03为待补充信息的议题撰写问题
  4. 04将已明确任务整理为 Agent 简报

安装

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

$npx skills add https://github.com/marcioaltoe/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