用途：在遇到任何 bug、测试失败或异常行为时，先做根因调查再提修复方案，避免随机修补掩盖真实问题。核心原则是“未完成根因调查前不得提出修复”。
主要能力：按四阶段推进。阶段一根因调查：仔细读错误与堆栈、稳定复现、检查近期变更（git diff、提交、依赖与配置）、在多组件系统中于各边界加诊断日志以定位失败层、沿调用栈回溯数据来源。阶段二模式分析：找可用的相似实现、完整阅读参考实现、列出工作与故障版本的全部差异、梳理依赖与假设。阶段三假设与测试：写下单一具体假设，做最小改动、一次只验证一个变量，失败则重新假设而非叠加修复。阶段四实现：先复现失败，再针对根因做单一修复，用同一复现验证，并检查是否破坏其他测试。
研究阶段：在阶段一与阶段二之间默认开启，收集外部上下文，包括网络搜索错误字符串与相关 issue、用 git log --grep 查历史修复、获取权威文档、检查 MEMORY.md。结果写入 .superpowers/debug-log-<slug>.md，建议将 .superpowers/ 加入 .gitignore。跳过需写明理由，如范围极小、7 天内同主题已有可验证研究、用户明确授权或重复相同任务。
适用场景：测试失败、生产缺陷、异常行为、性能问题、构建失败、集成问题；时间紧迫、看似只需“快速一改”、已多次尝试修复、不理解问题本质时尤其适用。
限制与提醒：若连续 3 次以上修复失败，应停止并质疑架构，与人类伙伴讨论，而非继续尝试。若调查显示问题确属环境、时序或外部因素，需记录调查过程并实现重试、超时、错误信息与监控。资料未提供安装命令、收费或平台信息。