该技能用于系统化地调试与诊断技术问题，核心原则是：在尝试任何修复之前，必须先找到根因；只修症状视为失败。适用于测试失败、生产缺陷、异常行为、性能问题、构建失败、集成问题等任何技术问题，尤其在时间压力大、看似只需快速修复、已尝试多次修复无效或尚未完全理解问题时更应使用。
流程分四个阶段，每个阶段必须完成后才能进入下一阶段。阶段一为根因调查：仔细阅读错误信息与堆栈，稳定复现问题，检查最近变更（git diff、提交、新依赖、配置、环境差异）；在多组件系统（如 CI→构建→签名、API→服务→数据库）中，先在各组件边界加诊断插桩，记录进入与退出的数据、验证环境与配置传递、检查各层状态，运行一次收集证据以确定失败发生在哪一层，再分析该组件。若错误位于调用栈深处，可参考本目录的 root-cause-tracing.md 进行反向追踪，找到坏值来源并从源头修复。阶段二为模式分析：在同一代码库中寻找相似的可工作示例，完整阅读参考实现，列出工作与损坏版本之间的所有差异，并理解依赖、设置与假设。阶段三为假设与测试：提出单一明确假设并写明，做最小改动、每次只验证一个变量；验证成功则进入阶段四，失败则提出新假设，不要叠加更多修复。阶段四为实现：先创建可失败的最小测试用例（可借助 superpowers:test-driven-development 技能），只实施针对根因的单一修复，避免顺带改进或捆绑重构，然后验证测试通过且未破坏其他测试。
若修复失败：尝试少于三次则回到阶段一重新分析；达到三次及以上则停止，考虑架构问题而非继续尝试第四次修复，并与人类伙伴讨论。文档还列出危险信号（如“先快速修一下”“随便改改试试”“跳过测试手动验证”等），出现即应回到阶段一。支持技术包括 root-cause-tracing.md、defense-in-depth.md、condition-based-waiting.md；相关技能有 superpowers:test-driven-development 与 superpowers:verification-before-completion。若系统化调查确认问题纯属环境、时序或外部因素，则记录调查内容并实现相应处理（重试、超时、错误提示）并增加监控日志，但 95% 的“无根因”情况其实是调查不完整。资料未提供安装命令、收费方式或平台信息。