问题分诊助手

解决什么问题

Issue 跟踪器常沦为愿望清单：每条进来的 issue 都缺上下文、缺复现、缺明确的下一步，维护者被迫反复追问，代理（automation）也没法令牌可打。@kunlungrowth/kg-triage 不做代码改动，只把一个 issue 或外部 PR 推过一个明确的小状态机：先分类，再核验，必要时继续拷问，最后产出一份「代理可读、可长期留存」的简报，让开发者拿到就能上手。

核心能力

• 分类与状态各一：分类二选一（bug / enhancement），状态五选一（needs-triage / needs-info / ready-for-agent / ready-for-human / wontfix），每个 issue 恰好一个分类和一个状态。
• 待处理三桶展示：查询跟踪器后按 oldest 优先 列出未标、needs-triage、needs-info 且有新活动的条目，并用一行摘要提示，方便维护者快速点选。
• 上下文收集与两项检查：读全文与 diff，解析既有分诊笔记；随后跑冗余检查（按领域概念搜已有实现）和先验拒绝检查（对照 .out-of-scope/*.md），避免重问与重复拒绝。
• 核验与拷问：bug 按步骤复现，PR 检出 diff 后跑相关命令；如需打磨，则启动 /grilling 与 /domain-modeling 逐问推进，并内联更新 CONTEXT.md / ADR。
• 结构化落结果：ready-for-agent 输出含 current / desired / acceptance 的 agent 简报；ready-for-human 附不可代理原因；needs-info 留下待补信息笔记；wontfix 按「已实现」或「拒绝(bug / enhancement)」分别关闭并记录。

互操作与输出

输入可为 issue/PR 编号，或一句「看需要我注意的」。输出统一为 TriageOutcome（含 category、state、verified、agent_brief 等），其中 ready-for-agent 的简报可直接交给 implement 或 tdd 消费；enhancement 类型的 wontfix 会写入 .out-of-scope/，供日后去重。

适用边界与注意点

• 仅分诊，不修改代码；外部 PR 视为「带代码的 issue」走同一状态机。
• 所有分诊评论须以 > *This was generated by AI during triage.* 开头。
• needs-info 仅在报告者有实际回复时才回流；单次信息不足不足以支撑强信号。
• 快速覆盖（如「把 #42 移到 ready-for-agent」）会直接信任用户指示并跳过拷问，但仍需确认即将执行的动作。