用途：do-debug 是一个语言无关的系统化调试技能，用于处理可复现的运行时缺陷、间歇性失败，或已经尝试过但未生效的修复。其核心是“铁律”：未先做根因调查不得修复；未验证机制的修复被视为猜测。
四个强制阶段： 1）调查（Investigation）：精确定义症状（文件/行/帧、输入、期望与实际），建立 10/10 可复现的最小复现，采集可复制粘贴的证据（堆栈、日志、与已知良好版本的 diff、配置/环境值），写出“症状卡”。 2）模式分析（Pattern analysis）：从症状帧回溯到状态仍正确的最早帧，映射到模式家族（测试污染、竞态、错误吞噬、序列化边界、差一错误、空值传播、配置漂移、权限、资源泄漏等），产出 1–3 个证据支撑的候选机制并按可反驳成本排序。 3）假设检验（Hypothesis testing）：为每个候选设计可证伪实验，先写“若为真/若为假”的预测再运行，取最廉价实验优先，如实读取结果；全部被证伪则回到 do-think 重构候选空间后重入阶段 2。 4）实现（Implementation）：施加最窄修复（只恢复一个被破坏的假设），添加回归守卫（测试/断言/不变量），在相同条件下重跑阶段 1 复现须 10/10 通过，移除临时诊断代码，再交给 check-completion。
主要约束：阶段 1–3 只允许诊断性改动（临时日志、探针、复现测试、埋点），不得改动产品逻辑；每个论断须引用证据；一次只验证一个假设；三次修复失败即停止修复并交接 do-think（Mode: Interactive），返回后从阶段 2 重新进入，不回到阶段 1。禁止用语包括“让我先试试”“这我知道是什么”等无机制表述。
适用场景：盯着堆栈/panic/断言追问原因、修复未固定症状、间歇性失败（只在 CI、有时出现）、跨层残留问题、在未命名机制前就想“试一下 X”。不适用于设计/架构/重构类任务、需要用户参与的头脑风暴、已有专用诊断工具、仅需确认完成度、外部服务故障，或尚无环境可运行代码的情况。
输出契约要求按序产出：症状卡、排序候选机制、实验设计与结果、根因陈述、修复与回归守卫、验证证据以及下一步指向。具体命令、脚本用法与各语言参考文件由技能内 references 与 scripts 提供，真实使用需按文档加载。