mcpField
T
triage

triage

github.com/paololeonardi开发058 次安装10 周前更新
代码仓库

关于 triage

triage 是一种技能，可在项目议题跟踪器中按类别和状态角色推进议题。它会收集议题与代码库信息，向维护者提出处理建议，并按确认结果更新状态及相关评论或文档。

主要功能

  1. 01列出待处理议题
  2. 02按类别和状态分类
  3. 03检查代码及过往拒绝记录
  4. 04通过提问梳理需求
  5. 05应用标签、评论或关闭议题

适用场景

  1. 01查看未标记或待处理议题
  2. 02结合代码评估缺陷报告
  3. 03为 Agent 准备任务简报
  4. 04记录被拒绝的功能请求

安装

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

$npx skills add https://github.com/paololeonardi/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，还要查看差异）。解析之前的分诊备注，避免重复询问已解决的问题。使用项目的领域术语表探索代码库，并遵循该区域的 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