用途：教授一套有纪律的四阶段调试流程，强制在动手修复前完成根因分析，防止最常见的调试失败模式——未理解问题成因就急于改代码。
主要能力：
- 铁律（先调查后修复）：在完成根因调查前不得改代码修复缺陷；即使修复看似显而易见，也应先调查。
- 阶段一 理解失败：收集事实，读完整错误信息与堆栈，定位出错文件与行，稳定复现，检查近期改动（git log --oneline -10 与 git diff），梳理数据流。
- 阶段二 寻找可用范例：对比正常与异常代码，比较设置、输入、状态与配置，找出差异，检查依赖或环境变化。
- 阶段三 单假设验证：提出明确假设，只做一处改动测试，观察结果；假设错误则完全撤销改动，再形成新假设。
- 阶段四 修复与验证：先写复现缺陷的失败测试，针对根因实现修复，确认新测试与既有测试全部通过。
- 三次失败升级规则：三次修复尝试失败后停止修复，记录尝试与失败原因，质疑假设，寻求架构评审、领域专家或升级给用户。
使用方式：可独立使用，无必需依赖。在流水线模式下作为门禁，修复提交需提供调试证据才能通过 TDD 门禁。可与 tdd、user-input-protocol、domain-modeling 等技能集成。缺少依赖时可用 npx skills add jwilger/agent-skills --skill tdd 安装。
适用场景：调试代码缺陷、TDD 中测试意外失败、需要根因分析而非症状修补的工程场景。
限制：独立模式下铁律为自我约束；三次失败后应回到调查而非停止工作；失败假设必须完全撤销，代码库需回到测试前状态。资料未提供具体收费、平台或效果数据。