该技能用于系统化排查生产事故或线上故障，原则是缓解优先于根因分析：先降低用户影响，再调查原因。
适用场景：生产环境正在出错或性能下降；用户报告线上错误；告警触发需要定位；需要进行结构化的事后调查。
核心铁律：先缓解后调查；改动前先保留证据（日志、追踪、指标快照）；不靠猜测，先埋点观测；先复现再修复；日志全部写入文件，避免刷屏，只显示相关行；修复前先清理调试埋点，可运行 git restore .。
主要阶段：一、前5分钟分诊与缓解，评估影响面（错误率而非绝对数、受影响服务与接口、趋势），按顺序评估回滚、功能开关、流量切换、扩容、重启（最后手段，需先抓日志）等手段。保留证据示例：grep "ERROR|FATAL|Exception" <log-source> > /tmp/incident-evidence.txt。
二、5至30分钟信号关联，按指标→链路→日志的漏斗排查。指标看错误率、延迟（p50/p95/p99）、饱和度、变更时间点，并对照部署记录，如 git log --oneline --since="2 hours ago"。链路定位出错服务与跨服务 trace ID。日志按 trace ID 聚合：grep "<trace-id>" <log-file> > /tmp/trace-logs.txt。
三、30至120分钟根因调查，先提出3至5个排序假设并写明支持与反驳证据；再在层边界埋点，日志带假设编号（如 [DEBUG-PROD][H1-db-connection-pool]）；若加入埋点后行为改变，提示竞态或时序问题；随后从症状反向追溯到最初触发点，并用证据确认根因、排除其他假设。若3个以上假设均被证伪，可能属于系统性或架构问题，应升级而非继续打补丁。
四、修复：先 git restore . 移除调试埋点，实施针对根因的最小修复，用复现用例验证红转绿，跑全量测试，并按根因、证据、复现、修复结构写提交信息。
五、恢复与验证：逐步恢复流量，观察错误率和延迟，确认告警解除、指标回到基线，观察10分钟以上再宣布解决。
六、输出报告至 .claude/incidents/<date>-<slug>.md，含摘要、时间线、根因、贡献因素、证据、修复、行动项；SEV1/SEV2 需在24至48小时内补充完整复盘。
限制：资料未提供具体收费、平台支持范围或效果保证。