用途：面向已损坏、需要根因排查的技术问题，核心原则是先完成根因调查再提出修复，违反流程即视为调试失败。
主要能力：分为四个必须依次完成的阶段。阶段一，根因调查：完整阅读错误与堆栈，记录行号、路径、错误码；稳定复现，不能复现则继续收集证据而非猜测；检查近期变更（git diff、提交、依赖、配置、环境差异）；多组件系统（如CI→构建→签名、API→服务→数据库）须在组件边界加诊断日志，确认数据进出与环境配置传播，定位失效层。阶段二，模式分析：查找同类可用范例，完整阅读参考实现，列出可用与损坏之间的全部差异，梳理依赖与假设。阶段三，假设与验证：明确写下单一假设，做最小改动、一次只验证一个变量；不成立则提出新假设，不叠加修复。阶段四，实现：先建立最小失败用例（可借助superpowers:test-driven-development），再做单一修复，验证测试通过且未破坏其他用例。多次失败后（3次及以上）应停止并质疑架构，与协作者讨论。
适用场景：测试失败、生产缺陷、异常行为、性能问题、构建失败、集成问题；时间紧迫、已多次尝试修复、或问题尚未完全理解时尤其适用；不可用于TDD新行为、测试报告打包、完成前验证、Windows/Git Bash/WSL钩子失败等相邻问题。
限制：流程要求团队接受先调查后修复的节奏，需要能复现或能采集证据；对于确为环境、时序或外部原因的问题，需记录调查过程并采取重试、超时、报错、监控等处理。支持文档包括根因回溯、多层防御、条件等待等。资料未提供安装方式、价格与平台信息。