该技能用于在提出修复方案前系统性地定位根因，原则是始终先找到根因，只修症状视为失败。适用场景包括遇到缺陷或测试失败、代码出现异常行为、以及提出任何修复之前。
四阶段流程：第一阶段根因调查，完整阅读错误信息与堆栈、稳定复现问题、检查近期变更（git diff、依赖与配置）、在多组件系统中于组件边界收集诊断证据、从错误反向追踪数据流定位坏值来源。第二阶段模式分析，在代码库中找到可用的相似实现，完整阅读参考实现而非略读，列出可用与损坏代码之间的全部差异，理解所有依赖与假设。第三阶段假设验证，明确表述“我认为 X 因 Y 失败，证据是 Z”，用最小改动测试，每次只改变一个变量，验证结果后再继续。第四阶段实施，先写失败测试用例（TDD），实施只针对根因的单一修复，验证修复且不破坏其他测试；若无效则回到第一阶段。
警示信号：未理解问题就提修复、同时做多处改动、未经验证就假设、跳过证据收集、调查前做快速修补。若连续三次以上修复失败，应停止，这通常意味着架构问题而非可修缺陷，需回到第一阶段并评估是否重构架构。资料称系统化方法约15至30分钟解决且首次成功率95%，而试错约2至3小时且成功率40%并引入新缺陷。使用方式与安装命令暂未提供。