用途：用于处理任何技术问题，包括测试失败、生产缺陷、异常行为、性能问题、构建失败和集成问题。核心理念是：在尝试修复前必须先找到根因，症状式修补视为失败；未经根因调查不得提出修复方案。
四个阶段（须逐阶段完成）：一、根因调查——仔细读错误与堆栈，稳定复现，检查近期变更（如 git diff、提交、依赖、配置），在 CI→构建→签名或 API→服务→数据库等多组件系统中先加诊断插桩，记录每层边界的数据进出，定位失败层后再深入；对深层调用栈可借助 root-cause-tracing.md 向上追溯数据来源。二、模式分析——在同一代码库中找可用示例，完整阅读参考实现，列出工作与损坏版本之间的每处差异，理解依赖与假设。三、假设与验证——只提出单一明确假设，做最小改动、一次只改一个变量进行验证；不成立则形成新假设，不在旧修复上叠加。四、实施——先创建失败测试用例（可用 superpowers:test-driven-development），实施单一修复，再验证原有测试未被破坏。
失败处理：若修复尝试少于3次，回到阶段一并结合新信息重新分析；达到3次及以上则停止，质疑架构是否为根本问题，并与人类伙伴讨论后再修。附带技术有 defense-in-depth.md（多层校验）、condition-based-waiting.md（用条件轮询替代固定超时）。
限制：该技能假定可通过复现和证据收集定位问题；若调查确认问题属于环境、时序或外部因素，应记录调查过程并加入重试、超时、错误提示与监控日志，但资料指出约95%的“无根因”情况其实是调查不完整。