用途：将事故（bug、回归、生产故障）从症状推进到有证据的修复，并沉淀知识。触发场景包括运行出错、行为异常、回归或用户调用 /orca-issue。与功能开发流程不同，它有两个硬闸门：无法复现就不修，未从红转绿就不关闭。
主要能力：分诊并原文摘录错误；编写脚本或测试复现出红色结果并留存证据；用 code-graph、impact-check、git bisect 等定位根因，形成“根因在 X 因为 Y”的结论；经 safe-change 做外科式修复并验证；提交后写入 wiki 事故页、failure-flywheel 记录，必要时更新 problem-tree 节点。它只协调已有工具（impact-check、safe-change、verify-before-commit、failure-flywheel），不重复实现。
使用方式：依次执行五个步骤——分诊、复现闸门、定位、修复红转绿、双重沉淀。修复时每次只改一个假设，重新运行复现；连续三次修复失败即停止，怀疑架构层面问题。严重事故可升级到 orca-workflow 调度，但两个硬闸门不变。
适用场景与限制：适合有明确症状、可编写复现脚本的事故。症状不清时应先向用户询问；无法复现的 flaky 或 heisenbug 应记录已尝试条件、降级为加日志或探针的监控模式，而非盲修。该技能不部署，不在事故处理中顺手清理周边代码；功能请求不属于其职责范围。官网未提供独立安装命令或收费信息。