Triage 是一个用于项目问题跟踪器的智能体技能，核心方式是用一个小型状态机驱动 issue 从提出到定性的流转。
用途：当用户希望创建 issue、分诊 issue、审查新提交的 bug 或功能请求时使用。它把 issue 的评估与推进过程结构化，区分「什么问题」和「处于什么阶段」。
主要能力：
- 角色体系：两个分类角色（bug 表示某处损坏，enhancement 表示新功能或改进）与五个状态角色（needs-triage 待维护者评估、needs-info 等待报告者补充信息、ready-for-agent 规格完整可交给 AFK 智能体、ready-for-human 需人工实现、wontfix 不予处理）。每个已分诊 issue 应恰好携带一个分类角色和一个状态角色；若状态角色冲突，需先标记并询问维护者。
- 状态流转：未标注 issue 通常先进入 needs-triage，再转向 needs-info、ready-for-agent、ready-for-human 或 wontfix；needs-info 在报告者回复后回到 needs-triage。维护者可随时覆盖，遇到异常流转应先询问。
- 引用文档：AGENT-BRIEF.md 说明如何撰写耐用的智能体简报；OUT-OF-SCOPE.md 说明 .out-of-scope/ 知识库的运作方式。
- 角色名称为规范名，实际标签字符串可能不同，映射应预先提供，否则运行 /setup-matt-pocock-skills。
使用方式：维护者调用 /triage 并用自然语言描述意图，例如「显示所有需要我关注的内容」「看看 #42」「把 #42 移到 ready-for-agent」「哪些已就绪可供智能体领取」。
- 查看待办：查询跟踪器，按最旧优先呈现三个桶——未标注（从未分诊）、needs-triage（评估进行中）、needs-info 且自上次分诊记录以来报告者有活动（需重新评估），显示计数与每项一行摘要供选择。
- 分诊具体 issue：先收集上下文（完整正文、评论、标签、报告者、日期，解析既有分诊记录避免重复提问，借助项目领域词汇表浏览代码库并遵循相关 ADR，读取 .out-of-scope/*.md 并指出相似的既往拒绝）；然后给出分类与状态建议及理由和代码库摘要，等待指示。
- bug 复现：在深入追问前尝试复现，阅读报告者步骤、追踪相关代码、运行测试或命令，报告结果（成功复现及代码路径、复现失败或细节不足，后者是 needs-info 的强信号）。确认复现能让智能体简报更有力。
- 追问：若需补充细节，运行 /grill-with-docs 会话。
- 应用结果：ready-for-agent 发布智能体简报评论；ready-for-human 结构相同但注明不可委托的原因（判断性决策、外部访问、设计决策、手工测试）；needs-info 发布分诊记录；wontfix（bug）礼貌说明后关闭；wontfix（enhancement）写入 .out-of-scope/，在评论中链接后关闭；needs-triage 仅应用角色，如有部分进展可选评论。
- 快速状态覆盖：维护者直接指定移动目标时信任并直接应用角色，确认角色变更、评论与关闭动作后执行，跳过追问；若在未追问情况下移至 ready-for-agent，询问是否要撰写智能体简报。
- needs-info 模板：分两部分——「目前已确立的内容」（列出要点，保留追问中已解决的问题）与「仍需你（@reporter）提供的内容」（列出具体可操作的问题，避免笼统的「请提供更多信息」）。
- 恢复会话：若 issue 上已有分诊记录，先阅读、检查报告者是否回答未决问题，呈现更新后的全貌再继续，不重复已解决的问题。
约束：分诊期间发布到跟踪器的每条评论或 issue 都必须以声明「This was generated by AI during triage.」开头。
适用场景：需要以一致流程评估、分类、补充信息并决定由智能体还是人工实现的 issue 跟踪场景，尤其适合希望把可委托工作交给 AFK 智能体的维护者。
限制：资料未说明具体支持的跟踪器平台、安装命令、配置方式、收费或价格信息。