用途：用于处理任何技术问题，包括测试失败、生产环境缺陷、异常行为、性能问题、构建失败和集成问题。核心原则是必须先找到根因再尝试修复，症状式修补被视为失败。
主要能力：提供四阶段框架。第一阶段根因调查：仔细阅读错误信息与堆栈、稳定复现问题、检查近期变更（git diff、提交、依赖、配置、环境差异），在多组件系统中于各组件边界添加诊断日志以定位失败层，并沿调用栈向上追踪数据流。第二阶段模式分析：寻找可用的相似实现、完整阅读参考实现、列出工作与故障版本之间的所有差异、理解依赖与假设。第三阶段假设与测试：提出单一明确假设，做最小改动验证，一次只改一个变量，验证后再继续。第四阶段实施：先创建失败测试用例，实施单一修复，验证修复且不破坏其他测试。
使用方式：按阶段顺序执行，每阶段完成前不得进入下一阶段。若修复失败，少于三次则回到第一阶段重新分析；三次及以上失败应停止并质疑架构，与人类协作者讨论。技能要求配合 root-cause-tracing（调用栈深层错误时）和 test-driven-development（编写失败测试时）使用，并可与 defense-in-depth、condition-based-waiting、verification-before-completion 互补。
适用场景：时间压力下的紧急故障、看似简单的缺陷、已尝试多次修复仍失败、对问题理解不充分时尤其适用。
限制：资料未提供安装命令、平台支持、收费或价格信息。资料称 95% 的“无根因”情况实为调查不完整，若确属环境、时序或外部因素，应记录调查过程并实施重试、超时、错误提示及监控日志。