triage 用于把项目 issue 跟踪器中的 issue 推进过一个小型状态机；若仓库把外部 PR 也视为请求入口，则 PR 同样适用，视作附带代码的 issue，使用相同角色与状态。
用途与角色：两个分类角色为 bug（功能损坏）与 enhancement（新功能或改进）；五个状态角色为 needs-triage、needs-info、ready-for-agent、ready-for-human、wontfix。每个已分诊 issue 应恰好带一个分类角色和一个状态角色；状态冲突时先标记并询问维护者。角色名为规范名，跟踪器实际标签字符串可能不同，映射应由环境提供，否则提示用户运行 /setup-matt-pocock-skills。
状态流转：未标记 issue 通常先进入 needs-triage，再转向 needs-info、ready-for-agent、ready-for-human 或 wontfix；needs-info 在报告者回复后回到 needs-triage。维护者可随时覆盖，异常流转需先询问。
使用方式：维护者以自然语言调用 /triage，例如查看待处理项、查看 #42、把 #42 移到 ready-for-agent、查看可供智能体接手的项。查看待处理项时按最旧优先列出未标记、needs-triage、以及报告者有新活动的 needs-info 三类，PR 在范围内时标注 [PR] 或 [issue]。
分诊具体 issue 或 PR 时：先收集上下文（正文、评论、标签、作者、日期，PR 还需 diff），解析既有分诊笔记，按领域词汇与 ADR 探索代码库，检查是否已实现（已实现则 wontfix）以及 .out-of-scope/ 中是否有类似拒绝记录；给出分类与状态建议并等待指示；验证声明（bug 复现、PR 确认 diff 行为）；必要时调用 grilling 与 domain-modeling 技能追问；最后按结果应用：ready-for-agent 发布 agent brief，ready-for-human 用相同结构但说明不可委派原因，needs-info 发布分诊笔记，wontfix 关闭并视原因处理（已实现则指向代码位置，不写入 .out-of-scope/；拒绝的 enhancement 写入该知识库并链接后关闭）。快速状态覆盖时信任维护者直接应用角色，跳过追问；若直接移到 ready-for-agent 且未追问，询问是否撰写 agent brief。
限制：分诊期间发布到跟踪器的每条评论或 issue 必须以“This was generated by AI during triage.”开头。恢复先前会话时读取既有笔记、检查未答问题并更新情况，不重复已解决的问题。具体标签映射、跟踪器配置与外部 PR 定义依赖环境提供，资料未给出具体实现细节。