triage-issue

Issue 分诊

基于证据决定如何处理 Issue，而不是凭感觉。避免过早开展工作（在触发条件尚未满足时处理延期事项），也避免问题悄然搁置（应立即修复的 Bug 被放任不管）。

回合约定 — 结束回合前核实

✓ One fixed-format verdict block per issue (Trigger / Checked / Evidence / VERDICT / Action) — plus the summary table when batched
✓ Nothing deferred was implemented inline
✓ Audit-finding mode (`<audit-id> F<k>`): the audit file carries its `↳ triaged` note, and any opened issue cites `Origin: product audit <id>, finding F<k>`
✓ Review-finding mode (`--prioritize-now <unit> F<k>`): every named unresolved finding gets a verdict, an immediate-fix attempt, or an explicit replan/user-decision route
✓ Batched input? The closing recommendation maps every issue/finding ID to its own next command, joined with ` + `; it never collapses to one generic action
✓ Artifact language: explicit user instruction > the project's declared docs language > English. The CONVERSATION language never decides — a Spanish prompt still produces English PRs/issues/commits/SPECs unless one of the first two says otherwise
✓ The closing `→ Next:` block is printed as the ABSOLUTE last output

准备结束回合时，如果有任何复选框尚未勾选？回合就尚未完成——先完成缺失项（弱模型容易遗漏文档末尾的职责清单；因此特意把它放在最前面）。

适用场景

• 任何需要决策的 Issue：刚提交的 Bug、标记为 postpone/needs-triage 的事项，或定期重新确认的延期权衡事项。
• 批量分诊 — 传入多个编号（triage-issue 12 14 17）：每个 Issue 都会独立给出结论和证据，最后再提供一张汇总表。批量处理仅适用于 分诊——由此产生的任何修复仍需有自己的分支和 PR。
• 审计发现项 — triage-issue <audit-id> F<k> [F<j> …] 会对已保存的 product-audit 报告中的发现项进行分诊，而不是处理现有 Issue（见下文的 审计发现项模式）。批量处理方式相同。
• 评审发现项 — triage-issue --prioritize-now <unit> F<k> [F<j> …] 会对当前功能/修复单元的 review-findings.md 中尚未解决的条目进行分诊。此路径适用于 fold-findings 无法关闭的发现项。--prioritize-now 表示尝试立即解决每个指定的发现项；不允许降级、延期或悄然丢弃。

步骤 0 — 了解项目（始终首先执行）

按照 Agent 指南中的 Workflow conventions 和 documentation map 执行，然后阅读本技能所需内容：修复索引（例如 docs/fix/README.md）、修复 SPEC 模板和路线图。检索辅助工具（可选，绝非权威来源）： 当索引入口存在时，在读取 forge 之前运行一次 — agentic-workflow doc --query "<topic terms>" --json-only — 查找与此主题相关的既有发现项、决策和会话日志条目。这是对同一语料进行搜索的快速途径：索引缺失、入口不存在或答案为空，都不会改变任何事情（grep 仍是完整的备用方案 — AC21），且索引绝不是决策依据。在评审发现项模式下，应阅读目标单元的 SPEC、验收标准、review-findings.md、当前差异和 PR，而不是查找 Issue 评论。否则，应完整阅读 Issue，包括评论和标签（使用项目 Workflow conventions 规定的 forge CLI — 示例使用 gh）：

gh issue view <N> --json number,title,body,labels,state,comments

渐进式加载 — 选择分诊来源

参考资料的允许列表恰好包含以下五个链接路径。步骤 0 之后：

• Forge Issue 编号：阅读 Issue 流程。
• 评审发现项：阅读 评审发现项流程。
• 已保存的审计发现项：先阅读 审计发现项，然后使用 Issue 流程中的核实和决策步骤。
• 应用紧急程度或处置标签之前，阅读 标签词汇表；此文件是名称、颜色和变更规则的唯一依据。
• 仅当结论为 fix-in-unit 时，才在填写条目前阅读 合并台账。

每项资源都只需从此文件跳转一级即可访问。缺少源材料或必需资源时，应停止处理该条目；批次中的各项仍相互独立。切勿编造标签、触发条件、台账条目、结论格式或参考文件名。Forge Issue 的 postpone 路径恰好加载 Issue 流程，然后加载标签词汇表；跳过审计发现项和合并台账。

防护措施

• 不要仅仅因为有人要求“看看”Issue，就着手处理延期工作——应指出触发条件尚未满足，然后停止。
• 确保 Issue、修复索引和文档与实际情况保持一致。
• 其他方面遵循项目的 Workflow conventions（文档语言、证据）：明确说明你具体核查了哪些内容。

可移植性

使用项目声明的 forge CLI，并逐条对应转换命令。分类、标签归属和持久化输出约定均保持不变。

与其他技能的关系

                 ┌─ fix-now ─────────▶ /unit-lane --fix <n> ─▶ the lane's implement step
                 ├─ fix-in-unit ─────▶ execute-phase <NN> P<k> (fold into phase)
triage-issue ────┤                    or fold-findings (ledger row)
                 │                    or unit-route <unit> → /unit-lane <unit> (replan)
                 ├─ promote ─────────▶ /unit-lane --from-issue <n> (feature from issue)
                 ├─ postpone ────────▶ dated comment, leave open
                 └─ wontfix ─────────▶ propose close

在审查发现模式下，replan-in-unit 运行 node scripts/unit-route.mjs <unit>：其 route: replan 行会打印规划器命令——功能对应 /unit-lane <unit>，修复对应 /unit-lane --fix <n>——该命令会重新运行此工作流的 plan 目录步骤，并向同一单元追加新的 P<n> 阶段。此工作流自身的 review 步骤是执行前的关卡。用户手动运行这些阶段；此技能绝不负责实现它们。

完成条件

• 问题有明确的结论，并附有引用证据。

• 每项审查发现都有明确的结论，并附有引用证据；对于过大的发现，需明确规划命令和手动 /execute-phase 交接。

• 已记录结论（已路由、已评论和/或已更新索引），且未在此处直接实现任何已延期事项。

• 按结论打印结尾的 → Next: 区块：

  Single issue:
  → Next: <command for the recorded verdict> — act on the issue's evidence-backed action
  
  Batch:
  → Next: apply every verdict: #<n1> → <command> + #<n2> → <command> + #<n3> → <command>
    · fix-now → /unit-lane --fix <n>   · promote → /unit-lane --from-issue <n>
    · fix-in-unit → /execute-phase <NN> P<k> or /fold-findings — never a new planner skill
    · postpone → dated comment, leave open   · wontfix → propose close
    · same inconsistency across several issues → /product-audit (a recurring pattern,
      not isolated tickets — sweep the product rather than triaging one by one)
  

  打印前，将每个占位符替换为所有实际的问题/发现 ID 及其已记录的路由；在实时批处理中，绝不打印 <n2>、<command> 或 …。

  只有出现反复发生的不一致时，才触发 /product-audit 行——即多个问题背后的同一根本问题，而非单次分流。