Triage 是一套面向维护者的 AI 分流流程，把 .scratch/ 下的请求文件按一组分流角色推进。它不设外部问题跟踪器，每个工作产物都是 Markdown 文件。仓库若存在 .agents/issue-tracker.md（旧路径为 docs/agents/issue-tracker.md，由 /setup 生成），则按其中描述的布局读取。
外部 pull request 也可以作为请求来源：PR 是输入，会在 .scratch/ 下生成同样的 Markdown 分流文件，沿用相同角色、状态与状态机，只是下文标注「for a PR」的若干差异。笔记、简报和状态都保存在该文件中，始终不以 PR 托管平台作为记录系统。追加到 Markdown 文件中的每条分流笔记都必须以免责声明开头：「This was generated by AI during triage.」。
参考文档：AGENT-BRIEF.md（如何撰写可长期使用的智能体简报）、OUT-OF-SCOPE.md（.out-of-scope/ 知识库的工作方式）。
角色分为两类。分类角色记录在文件靠上位置，如 Category: bug，共两种：bug（某处损坏）、enhancement（新功能或改进）。状态角色以 Status: <role> 记录，共五种：needs-triage（维护者需评估）、needs-info（等待报告者补充信息）、ready-for-agent（已完整描述，可供后台智能体执行）、ready-for-human（需人工实现）、wontfix（不予处理）。对源于 PR 的文件，同样的状态针对所附代码理解：ready-for-agent 表示已附简报、智能体应就 diff 推进下一步；ready-for-human 表示可由人工合并。每个已分流文件应恰好有一个分类和一个状态；状态冲突时先标记并询问维护者。角色名可在 .agents/triage-labels.md（由 /setup 生成）中重映射；该文件缺失时直接使用上述名称作为 Status: 值。状态流转：无 Status: 的文件通常先进入 needs-triage，再转向 needs-info、ready-for-agent、ready-for-human 或 wontfix；needs-info 在报告者回复后返回 needs-triage。维护者可随时覆盖，遇到异常流转应先标记并询问。
调用方式：维护者用自然语言说明意图，智能体据此执行。示例包括「Show me anything that needs my attention」「Let's look at payment-refunds」（文件名、路径或标题）「Move payment-refunds to ready-for-agent」「What's ready for agents to pick up?」「Triage this PR」（从 PR 创建或更新 .scratch/ 下的 Markdown 文件）。
展示待关注项：扫描 .scratch/（存在 .agents/issue-tracker.md 时也按其布局），按最旧优先展示三组：无状态（从未分流）、needs-triage（评估中）、needs-info 且报告者在上次分流笔记后有活动（需重新评估）。外部 PR 在范围内时，还展示尚无对应分流文件的开放外部 PR，标记 [PR]。发现阶段只呈现外部 PR；协作者正在进行的 PR 不属于分流工作。该过滤仅用于发现；明确点名的 PR 无论作者都会分流。选中无文件的 PR 时会在 .scratch/ 下创建文件并继续分流。展示数量与每项一行摘要，让维护者选择（支持 AskUserQuestion 时以最旧项为选项、「Other」承接其余；否则在对话中选择）。
分流具体问题或 PR：先收集上下文，读完整 Markdown 文件（正文、评论、状态、分类、作者备注、日期）；PR 来源还需读 PR diff，笔记仍写入 Markdown 文件。解析既有分流笔记，避免重复询问已解决的问题。借助项目领域词汇表探索代码库，并遵守相关 ADR。对代码库做两项检查：(a) 冗余性——按领域概念（而非仅请求措辞）搜索是否已有该行为的实现，并报告搜索位置；若已存在，则归为已实现的 wontfix；(b) 既往拒绝——读取 .out-of-scope/*.md，指出任何相似请求。随后给出分类与状态建议及理由，附相关代码库摘要（含是否已实现），征求方向（支持 AskUserQuestion 时选项为 ready-for-agent、needs-info、ready-for-human、wontfix，建议项置首；否则在对话中）并等待。
验证主张：在追问前先确认主张成立。bug 按报告者步骤复现；PR 确认 diff 确实做了其声称的事，检出并运行相关测试或命令。报告结果：已确认（附代码路径）、失败或细节不足（强烈的 needs-info 信号）。已验证的结论会让智能体简报更有力。
按需追问：请求需补充时，与 grilling 和 domain-modeling 技能配合，每次一个问题打磨，同步锐化领域术语并就地更新 GLOSSARY.md/ADR。
落实结果（编辑 Markdown 文件）：ready-for-agent 设状态并追加智能体简报（AGENT-BRIEF.md）；ready-for-human 设状态，结构与简报相同，但注明为何不能委派（判断取舍、外部访问、设计决策、手动测试）；needs-info 设状态并追加分流笔记（模板见下）；wontfix 设状态并结项，按原因写笔记——已实现：指出代码位置，不写入 .out-of-scope/（该知识库用于被拒请求而非已建功能）；拒绝（bug）：礼貌说明后结束；拒绝（enhancement）：写入 .out-of-scope/ 并在文件中链接（OUT-OF-SCOPE.md）；needs-triage：设状态，有部分进展时可加可选笔记。
快速状态覆盖：维护者说「Move payment-refunds to ready-for-agent」时直接信任并应用状态，先确认将要执行的操作（状态变更、笔记、简报）再执行，跳过追问；若在无追问会话情况下移到 ready-for-agent，询问是否要写智能体简报。
needs-info 模板：标题「## Triage Notes」，下设「What we've established so far:」（列出要点）与「What we still need from you (@reporter):」（列出问题）。追问中已解决的内容都要归入「已确立」，避免工作丢失；问题须具体可操作，不能是「请提供更多信息」。
继续先前会话：文件已有分流笔记时先阅读，检查报告者是否已回答未决问题，在继续前呈现更新后的情况，不重复询问已解决的问题。