/triage 技能

它的作用

triage 处理项目追踪器上的 issue，把每个 issue 推过一个由 分流角色 ——一个类别角色和一个状态角色——并留下以下之一：一份智能体就绪的简报、一个给报告人的具体问题，或一个记录了原因的关闭 issue。

它只用于 你没创建的。原始 bug 报告、新来的功能请求、不请自来的外部 pull request——从外部落到追踪器里的工作，保持报告人留下的原样。 任务 that to-tickets 产出的天生已为智能体就绪，而运行 triage 处理它们最多是白费功夫。规则很平直： /triage 只用于外部进来的 issue，不用于你自己创建的 issue。

让它区别于手工贴标签的第二件事：它推荐并等待。它带着推理告诉你类别和状态判断，加上在代码库中的发现，在你指挥之前什么都不应用。

何时使用

你通过输入 /triage 然后用平实的语言描述你想要什么—— agent 不会自动调用它。「给我看任何需要我注意的东西」「看看 #42」「把 #42 移到 ready-for-agent」。

前置条件

triage 读写你的 issue 追踪器，所以 setup-matt-pocock-skills 必须先配置好那个追踪器及其标签词汇。下面的角色名是 canonical；你追踪器中的标签字符串可能不同，而映射正是 setup 提供的。如果你的追踪器已经精确使用标准名称，那就无需映射，也无需配置。

追踪器配置还决定外部 pull request 是否算作请求表面，以及谁算外部。该标志默认关闭，不再是配置问题——在 docs/agents/issue-tracker.md 如果你想把 PR 纳入范围。

状态机

每个分流后的条目最终都恰好带有一个类别角色和一个状态角色。两个类别： bug （有东西坏了）和 enhancement （新功能或改进）。五种状态：

那就是全部词汇，「恰好一个状态角色」的不变量让查询保持简单。它也是 skill：用户曾要求为「已规格化但被其他 issue 阻塞」的工作增设第六种状态，用于 deferred 由未来触发器门控的工作，以及用于终态 implemented 状态。这些都没有发布。见下面的问题。

wontfix 分三条路，区别很重要，因为只有其中一条写入知识库：

.out-of-scope/ 每个被否决的 concept，而非按 issue 记录，写成简短的设计文档而不是数据库行：否决了什么、为什么，以及每个提出过该请求的 issue。 triage 在评估任何东西之前读取整个目录，并按概念而非关键词匹配——「夜间主题」匹配 dark-mode.md。当它命中匹配时，会浮出旧决策并问你感受是否依旧，而不是从头重新论证这个请求。

简报前先验证

在任何 追问审视, triage 检查论断是否真的成立。对于 bug，它按报告人的步骤复现。对于 PR，它检出分支并运行相关测试。然后它报告三件事中的哪一件发生了：已确认（带代码路径）；复现失败；或细节不足无法尝试——后者本身就是最强的 needs-info 信号了。

它在同一次扫描中对代码库再跑两项检查—— redundancy （是否已实现，按领域概念而非报告人的措辞搜索？）和 先前的否决 （是否 .out-of-scope/ 已经说过不？）。两者都很便宜，而且都会产生一个 wontfix 当它们命中时。

这一切都是为了做好一件产物： 智能体简报，即 issue 移至 ready-for-agent。一旦发布，简报就是契约，原始报告只是背景。简报被写成 durable 而不是精确，因为一个 issue 可能停在 ready-for-agent 好几周，而代码在它底下移动。所以它们点名类型、签名和行为契约，绝不点名文件路径或行号。已确认的复现比猜测能做出强得多的简报。

PR 就是带代码的 issue

当追踪器把外部 pull request 当作请求表面时，它们经过同一台机器——相同的类别、相同的状态、相同的转换。状态只是对照 diff 阅读： ready-for-agent 意味着已附上简报，智能体应该对代码采取下一步， ready-for-human 意味着它准备好由人来合并。PR 上的简报描述对现有 diff 还剩下什么要做，而不是如何从零构建。

发现阶段只浮现 external PR，因为协作者的进行中分支不是分流工作。该过滤器只在发现阶段生效——明确点名一个 PR，无论谁写的它都会被分流。一个粗糙之处：GitHub 模板的外部 PR 列表命令会问 gh pr list 为一个 authorAssociation 字段 gh 没有暴露，所以按原文写出的命令直接失败（#468）。

常见问题

我运行了 /to-spec and /to-tickets，而现在那些任务躺在那儿没人分流。我该运行 /triage 处理它们？ 不。它们已经为智能体就绪—— to-tickets 应用 ready-for-agent 标签发布，正是为了让 AFK 运行器无需再扫描一遍就能捡起它们。撞上这个问题的用户运行过规格流程，看到 needs-triage 在输出上，发现他们的 AFK 运行器无视了一切。 triage 是从外部抵达工作的入口；规格流程是你发起工作的车道。它们相会于 ready-for-agent，而不是之前。

是 triage 在有 to-spec → to-tickets → implement 流程？ 只有你有外部进来的工作才需要。 triage 先于那条主干线存在，做的是不同的工作：它是他人提交报告的通道。如果你追踪器里的一切都出自你自己的规划，你很少会打开它。如果你维护任何公开的东西，或你的团队向你提交 bug，它就是前门。主要用途是开源仓库接收外部贡献者的 issue。

智能体试图应用 ready-for-agent and gh 说标签不存在。 已知开放 bug（#616）。 setup-matt-pocock-skills 把标签词汇写入 docs/agents/triage-labels.md，但不会在你的追踪器中创建标签。请自行创建五个状态标签和两个分类标签，只需一次，使用 gh label create 或追踪器的 UI，然后它就停了。issue 里链接了一个尚未合并的社区修复分支。

五种状态不够——阻塞、延迟或已实现怎么办？ 这是该技能被提交最多的缺口，有三种形态。一个已完全规格化、但等待另一个 issue 关闭的 issue（#139）——报告人的抱怨是 ready-for-agent 在那里「技术上成立」却具有误导性，所以智能体捡起它就撞墙。已计划但尚不可执行的触发门控的未来工作（#297）。以及一个「已实现，等待验证」的终态，没有它，AFK 运行器可能会把已完成的任务重新排队。Matt 已同意阻塞情况是真实的，但对命名尚未决定（blocked versus paused）。其中没有任何一项已发布。人们使用的变通方案是在类别旁边加一个仓库内的额外标签，让标准状态槽被一个诚实的东西占据，代价是该技能对此一无所知。一个社区衍生版更进一步，增加了 needs-slicing, tracking 和投入标签——这能行，但那是他们的，不是该技能的。

这与 /diagnosing-bugs? 这里的验证步骤刻意做浅——足够回答「这是真的吗，大致住在哪里」，而不是找根因。当 bug 无法在几分钟内按报告人的步骤复现时，诚实的做法是 needs-info，或 diagnosing-bugs 如果你想现在去追它。两个技能的文本目前都没有提到对方；一位用户发现了那个接缝，它仍然开放。

我能让它指向我整个待办清单让它跑吗？ 你可以问，但注意它读什么。「显示需要注意的东西」扫描是一份廉价的清单，面向 selection ——你选定一个，然后它收集完整的 context 在你选中的那个上。一次跨二十个 issue 运行，智能体可能悄悄退回那份廉价的清单作为证据基础，而它只返回 issue 正文而不返回评论。一位用户正好撞上：三个 issue 已带着「已修复，建议关闭」的评论，而三个都收到了全新的智能体简报。如果你想要批量扫描，明确说必须逐个 issue 读取评论。

它能与 Linear 或 GitHub Issues 之外的任何东西配合吗？ 可以——追踪器是配置，不是硬编码假设，人们用它配合 Linear（通过 linear CLI）、GitLab，以及 .scratch/。常见的分工是：issue 和规划用 Linear，代码和 PR 用 GitHub：说「issue 追踪器」的技能映射到 Linear，说「PR」的技能映射到 GitHub。本地 markdown 追踪器上有一个开放的模板 bug：生成的文件可能携带两份验收标准，一份在顶层，一份在智能体简报里（#200）。

做到以下就算成功

• 它处理的每个条目都以恰好一个类别角色和一个状态角色收尾——从不为零，从不出现两个互相冲突的状态。
• 它给你带推理的推荐然后就停，而不是重新贴标签继续走。
• 在任何事情到达 ready-for-agent.
• 它写的简报点名类型和行为，不包含文件路径和行号。
• 六个月前被拒绝的请求又回来了，它说明情况并引用旧理由，而不是重新分流。
• 它发布的每条评论都以 > *This was generated by AI during triage.*

在流程中的位置

triage 是一个 on-ramp，而不是主链上的一步。主流程从你的一个想法开始——审问、规格、任务、实现、审查——而 triage 是替代的并行车道，用于「抵达的」工作。它在同一个地方汇合：一个标记为 ready-for-agent 上面带着简报， implement 接起它，就像接起来自 to-tickets。当请求在能写成简报之前还需要打磨时， triage runs 追问审视 and domain-modeling 一起，一次一轮问题，所以决策落在 CONTEXT.md 以及随做出的 ADR。当你不确定自己身处哪条道时， ask-matt 为你指路。