用途：适用于任何技术问题，包括测试失败、生产缺陷、异常行为、性能问题、构建失败和集成问题；在时间紧迫、想用“快速修复”或已多次尝试修复无效时尤其适用。
主要能力：把调试分为四个阶段，必须依次完成。阶段一“根因调查”：仔细阅读错误信息与堆栈、稳定复现问题、检查近期变更（git diff、提交、新依赖、配置与环境的差异）、在多组件系统中在组件边界增加诊断埋点收集证据，并沿调用栈反向追踪数据流。阶段二“模式分析”：在代码库中寻找可用的相似实现，完整对照参考实现，列出全部差异，理解依赖与假设。阶段三“假设与验证”：提出单一明确假设，做最小改动进行验证，一次只变一个变量；验证通过进入阶段四，未通过则提出新假设，不要叠加修复。阶段四“实现”：先创建可复现失败的最小测试（可用自动化测试或一次性脚本），再针对根因做单一修复，最后验证修复，确认原问题解决且未破坏其他测试。
重要限制与规则：在没有完成阶段一之前不得提出修复；不得把症状修复当作完成；若连续三次以上修复失败，应停止继续尝试，转而质疑架构并与人类伙伴讨论。资料还列出常见借口（如“问题简单不需流程”“紧急没时间”“先试一下再调查”）及其反驳，并给出红旗信号：跳过测试、凭猜测改代码、一次改多处、未追溯数据流就提方案等。
辅助资料：目录中提供 root-cause-tracing.md（反向追踪调用栈）、defense-in-depth.md（找到根因后分层校验）、condition-based-waiting.md（用条件轮询替代任意超时）。相关技能包括 superpowers:test-driven-development 与 superpowers:verification-before-completion。资料称系统化方法通常 15-30 分钟解决，随机修复需 2-3 小时，首次修复率 95% 对 40%；此类效果数据仅为原文陈述，未提供更多验证信息。
支持的完整安装命令与具体脚本用法：资料暂未提供。