triage

triage 技能概览

triage 的作用

triage 是一个用于 GitHub issue 分流的 triage 技能，负责把新进来的问题带过一个基于角色的状态机。它能帮你分类报告、判断是否还需要更多信息，并把工作路由给 AFK agent 或人工维护者。如果你需要一个用于 Issue Tracking 的 triage 技能，它的目标就是减少猜测，让 issue 处理保持一致。

最适合什么人

如果你要管理一个繁忙的 issue 队列，希望有可重复的收件流程，或者需要一种结构化方法把杂乱的 bug 报告转成可执行工作，就适合用 triage 技能。它尤其适合先区分 bug 和 enhancement，再把每个 issue 进一步推进到 needs-triage、needs-info、ready-for-agent、ready-for-human 或 wontfix。

它有什么不同

它最大的区别在于明确的状态机和严格的角色分工。这个技能不是简单的“总结 issue”；它要求恰好一个 category role 和一个 state role，并且规定每条 triage 评论或 issue 消息都必须以 disclosure disclaimer 开头。对于需要可预测输出、符合策略的路由，以及能顺畅交接给另一个 agent 的 triage 工作流，这一点非常关键。

如何使用 triage 技能

安装并先阅读这些文件

安装命令：

npx skills add mattpocock/skills --skill triage

安装 triage 后，先看 SKILL.md，再读 AGENT-BRIEF.md 和 OUT-OF-SCOPE.md。这些文件解释了持久化 brief 的格式，以及被拒绝想法是如何记录的——这两部分最容易直接影响 triage 的实际质量。这个 repo 里没有辅助脚本或额外的参考目录，所以这三个文件就是实际上的核心内容。

给技能正确的输入

triage 的效果最好时，你会提供 issue 标题、正文、已有标签，以及这次 triage 的明确目标。好的输入会告诉技能，你要的是分类、补充信息、agent brief，还是最终的拒绝决定。

推荐的 prompt 结构：

• “Triage this GitHub issue. Classify it as bug or enhancement, choose the correct state role, and say whether it should go to an AFK agent or stay with a human.”
• “Here is the issue thread and current labels. Apply the triage state machine and draft the comment with the required disclaimer.”
• “This looks under-specified. Determine whether it belongs in needs-info or ready-for-agent, and explain the missing acceptance criteria.”

用工作流思维，而不只是打标签

实用的 triage 方法，是把输出当作路由，而不是分类学。先确认它是 bug 还是 enhancement。然后判断它是否可执行、是否被报告者输入阻塞，或者是否明确超出范围。如果它已经适合交给 agent 处理，brief 应该描述行为预期和验收标准，而不是文件路径或具体实现步骤。

注意仓库规则

有两个细节会实质影响输出质量：disclaimer 要求，以及“恰好一个 category role 加一个 state role”的规则。如果 issue 的状态有歧义，技能会要求先标记冲突，并在改动其他内容之前询问维护者。这时候最正确的做法是停下来澄清，而不是硬行套标签。

triage 技能 FAQ

triage 只是用来处理 GitHub issue 标签吗？

不是。这个技能确实是围绕 GitHub 风格的 issue 跟踪构建的，但核心任务是判断 issue 状态并路由工作。如果你的 tracker 使用不同的标签字符串，canonical roles 仍然重要，你需要先把它们映射到自己的系统，再开始处理。

如果我会写普通 prompt，还需要它吗？

普通 prompt 可以分类单个 issue，但 triage 技能额外提供了可复用的状态模型、brief 编写模式，以及明确的 out-of-scope 处理方式。当你需要的是很多 issue 的一致决策，而不是一次性的摘要时，这些能力就很有价值。

triage 适合新手吗？

适合，前提是你已经理解基本的 issue 标签。triage 比自己写一条定制 policy prompt 更容易上手，因为它会直接告诉你有哪些状态，以及每种状态转换是什么意思。新手最常见的错误，是跳过 issue 上下文，只给一个标签请求，却没有正文、没有讨论、也没有当前状态。

什么时候不该用 triage？

不要把 triage 用在深入的实现规划或代码审查上。它适合做收件、路由和是否准备就绪的判断。如果 issue 已经有完整规范，而你需要的是设计或编码帮助，那换别的技能，或者直接给实现类 prompt，会更合适。

如何改进 triage 技能

提供更丰富的 issue 上下文

当你补充完整的 issue 正文、可见评论、当前标签和任何维护者备注时，triage 的效果会更好。只给一个标题通常会导致路由质量偏弱，因为技能无法判断这个报告是否可复现、是否已经回答过，或者是否缺少关键细节。

直接说出你真正需要的决定

如果你的目标是“ready for agent”，就直接说。如果你的目标是“应该以 wontfix 关闭”，也要明确说出来。最强的 triage 用法，是把决策边界说清楚，因为这样技能才能针对正确状态优化，而不是产出一份泛泛的摘要。

提高交接质量

当 issue 被转到 ready-for-agent 时，要求生成一份 agent brief，使用持久化的语言写清行为、约束和验收标准。除非你确实需要，不要要求逐文件的实现说明；仓库指导更偏向行为契约，因为它们能更好地抵抗代码库漂移。

迭代第一轮结果

如果第一次 triage 过于保守，就用下面三类补充信息之一再跑一轮：复现步骤、预期行为与实际行为的差异，或者这个 issue 对用户为什么重要。这些细节往往决定它应进入 needs-info、ready-for-human 还是 wontfix，也会让 triage 技能在第二轮判断时更果断。