用途
debug-prod 用于系统化地调查生产环境事故或线上缺陷。它的基本立场是：缓解优先于根因调查——先停止影响扩散，再追问为什么发生。适用于生产环境当下出现故障或性能退化、用户报告线上环境错误或异常行为、收到告警需要弄清状况，以及希望进行结构化的事后调查等场景。
核心原则
技能列出的“铁律”包括：先缓解再调查，降低用户影响优先于找到根因；在改动任何东西之前保存证据，回滚或重启前先抓取日志、链路与指标快照；不要靠猜，要埋点和观测，先形成假设再取证；修复前先复现，无法稳定触发问题就无法验证修复；保护上下文窗口，所有日志输出写入文件，不要直接内联倾倒原始日志，而应通过 grep/tail 只显示相关行；修复前先清理，用 git restore . 移除所有调试埋点。
阶段流程
阶段 1：分级与缓解（前 5 分钟）
评估影响范围：受影响用户或请求的数量（看错误率而非绝对数量）、受影响的服务/端点/功能、问题是恶化、稳定还是自行恢复。立即缓解选项按顺序评估：如果问题在部署后出现则回滚最近部署、用功能开关关闭出错功能、将流量从受影响服务或实例转移、若与负载相关则扩容、重启作为最后手段（会破坏证据，需先抓日志）。在任何缓解前保存证据，例如：
# Save current error logs to file before rollback/restart
grep "ERROR\|FATAL\|Exception" <log-source> > /tmp/incident-evidence.txt
在进入调查前先说明缓解决策与理由。
阶段 2：信号关联（第 5–30 分钟）
按可观测性漏斗推进：指标 → 链路 → 日志。
Step 1 指标：检查错误率、延迟（p50/p95/p99）与饱和度看板，找到事故开始的确切时间戳，寻找相关指标变化（内存、CPU、数据库连接、缓存命中率），并与部署时间交叉比对：
# Check recent deployments/commits relative to incident start time
git log --oneline --since="2 hours ago"
Step 2 链路：拉取事故窗口内失败请求的分布式链路，找到具体报错或变慢的服务、操作或 span，记录 trace ID 用于跨服务关联日志。
Step 3 日志：用 trace ID 提取关联日志：
grep "<trace-id>" <log-file> > /tmp/trace-logs.txt
cat /tmp/trace-logs.txt
找到确切错误信息、堆栈与请求载荷，记录首次出现时间戳，判断是否早于告警。
阶段 3：根因调查（第 30–120 分钟）
Step 1 提出 3–5 个排序假设，每个写成可检验的声明并列出支持与反驳证据，例如：
H1 [most likely]: <specific, testable claim about root cause>
Evidence for: <what supports this>
Evidence against: <what would refute this>
H2: ...
H3: ...
Step 2 在层边界埋点：为每个活跃假设在相关层边界添加定向日志，每条调试日志标注假设编号，例如 [DEBUG-PROD][H1-db-connection-pool] connections_active=47 connections_max=50 与 [DEBUG-PROD][H2-cache-miss] key="user:1234" result=miss latency_ms=450。所有输出写文件，不要内联：
# Route instrumented output to file
<your-service-start-command> 2>&1 | tee /tmp/debug-prod.log &
grep '\[DEBUG-PROD\]\[H1' /tmp/debug-prod.log
若添加埋点后行为发生变化，可能存在竞态或时序问题（海森堡 bug），应转向时序分析。
Step 3 反向追踪到源头：从观察到的症状回溯，思考是什么调用了失败函数/服务、每个层边界的输入与状态是什么，持续追问“是什么触发了它”，直到到达最初触发点，而不是只停在错误可见的第一处。
Step 4 确认根因：用一句话陈述确认的根因，列出证明它的证据，用反证排除其他假设。如果 3 个以上假设都被测试并失败，可能存在系统性或架构性问题，应停止打补丁并升级处理。
阶段 4：修复
先移除所有调试埋点 git restore .，再实施针对根因的最小修复，运行复现用例确认由红转绿，运行完整测试套件检查回归。提交信息结构包含：修复了什么、根因一句话、确认根因的关键信号、如何复现、改了什么及原因。
阶段 5：恢复与验证
逐步恢复正常流量并观察错误率与延迟，确认告警解除、指标回到基线，观察 10 分钟以上再宣布事故解决。
阶段 6：调查报告
在 .claude/incidents/<date>-<slug>.md 生成结构化报告，包含标题、日期、严重级别（SEV1/SEV2/SEV3）、持续时间、状态、摘要、时间线、根因、促成因素、证据、修复及行动项表格。对于 SEV1/SEV2，应在 24–48 小时内进行完整事后分析（5 Whys、无指责分析）。
快速参考
技能给出症状模式与首要检查项的对照：部署后错误率飙升查最近提交与回滚候选；延迟逐渐上升查数据库连接、N+1 查询、内存泄漏；间歇性错误查竞态、共享可变状态、异步顺序；单个服务宕机查健康检查、OOM、磁盘空间、依赖超时；所有服务退化查共享依赖（数据库、缓存、消息队列、DNS）；仅部分用户受影响查功能开关状态、A/B 分桶、区域路由。
限制
资料未提供该技能的具体安装命令、收费模式、支持平台或性能指标，这些信息暂未提供。技能主要面向具备生产可观测性（指标、链路、日志）与版本控制、部署流程的环境。