用途：面向任何技术问题的排查流程，包括测试失败、生产缺陷、意外行为、性能问题、构建失败与集成问题；在时间紧迫、看似只需“快速修一下”、已多次尝试修复或未完全理解问题时尤其适用。资料要求：仅在用户明确要求使用本技能并给出确认后才使用。
主要能力：以“铁律”约束流程——未完成根因调查不得提出修复。四阶段为：一、根因调查，仔细读错误与堆栈、稳定复现、检查近期变更（git diff、新依赖、配置与环境差异），多组件系统需在组件边界加诊断日志收集证据，并沿调用栈向上追溯数据流；二、模式分析，找同代码库中可用示例、完整阅读参考实现、列出所有差异、理解依赖与配置假设；三、假设与验证，提出单一明确假设，用最小改动单变量验证，不成立则重新提出假设而非叠加修复；四、实现，先写失败测试用例，再做单一修复（不夹带重构），验证测试通过与无回归。若修复无效，少于 3 次返回阶段一；达到或超过 3 次则停止并质疑架构，与人类伙伴讨论后再继续。资料另列出红旗信号、常见借口与人类伙伴的纠偏提示，并附支持技术文档：root-cause-tracing.md、defense-in-depth.md、condition-based-waiting.md，以及相关技能 superpowers:test-driven-development、superpowers:verification-before-completion。
使用方式与限制：资料未提供安装、调用命令或具体平台配置，仅说明按阶段执行并在修复前先建失败测试；所有阶段必须依序完成。若调查确认问题属环境、时序或外部因素，应记录调查内容并实现重试、超时、错误提示等处理，同时补充监控日志，但资料指出 95% 的“无根因”情况实为调查不完整。资料中给出的效果数据（如 15–30 分钟修复、95% 一次修复率）仅为经验性陈述，缺少可验证来源。