mcpField
T
triage

triage

github.com/tt-a1i开发192130 次安装2 天前更新
代码仓库

关于 triage

用于在项目问题跟踪器中按既定角色和状态流转问题的技能。它帮助维护者审查新事项、对照代码库核实问题，并通过相应备注或 Agent 简报处理结果。

主要功能

  1. 01问题分类与状态流转
  2. 02按时间排序的待处理队列
  3. 03针对请求检查代码库
  4. 04生成 Agent 简报和分类备注
  5. 05可选的外部拉取请求分类

适用场景

  1. 01查看尚未标记且需要关注的问题
  2. 02确认请求的功能是否已经存在
  3. 03为 Agent 或人工处理准备问题
  4. 04向报告者索取具体信息

安装

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

$npx skills add https://github.com/tt-a1i/matt-skills-with-to-goal --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-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 始终要进行分诊，无论作者是谁。

显示数量，并为每项提供一行摘要。最后以 👇 结尾，让维护者选择（按编号或 ID）。

对特定 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”，每轮提出一组问题，逐步完善请求、明确领域术语，并随着决策确定，在线更新 GLOSSARY.md/ADR。

  5. 落实处理结果（在聊天确认中以对应的表情符号开头；跟踪器评论除必需的 AI 免责声明外保持纯文本）：

    • ✅ ready-for-agent — 发布 Agent 任务说明评论（AGENT-BRIEF.md）。
    • 🧑 ready-for-human — 使用与 Agent 任务说明相同的结构，但说明无法委派的原因（需要判断、外部访问权限、设计决策或手动测试）。
    • 💬 needs-info — 发布分流备注（使用下方模板）。
    • 🚫 wontfix — 关闭，并根据原因选择评论内容：
      • 已实现 — 代码库中已存在此变更。指出其所在位置；不要写入 .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