用途：在遇到任何缺陷、测试失败或意外行为时，先进行系统化根因调查，再提出修复方案。核心原则是必须先找到根因，症状式修补被视为失败。
主要能力：提供四阶段流程。阶段一为根因调查，包括仔细阅读错误信息与堆栈、稳定复现问题、检查近期变更，并在多组件系统中于各组件边界添加诊断日志以定位失败层，必要时沿调用栈反向追踪数据流。阶段二为模式分析，寻找可用的相似实现、完整阅读参考实现、列出工作与故障版本之间的所有差异并理解依赖。阶段三为假设与测试，形成单一明确假设，做最小改动验证，一次只改一个变量。阶段四为实施，先创建失败测试用例，再实施单一修复并验证。
使用方式：按阶段顺序执行，未完成阶段一不得提出修复。若修复失败，少于三次时回到阶段一并结合新信息重新分析；达到三次及以上应停止并质疑架构，与人类伙伴讨论后再继续。目录中附带 root-cause-tracing.md、defense-in-depth.md、condition-based-waiting.md 等支持技术，并关联 test-driven-development 与 verification-before-completion 技能。
适用场景：测试失败、生产缺陷、意外行为、性能问题、构建失败、集成问题；时间紧迫、看似只需一处快速修复、已尝试多次修复、前次修复无效或尚未完全理解问题时尤其适用。
限制：资料未提供安装命令、平台支持、收费方式或具体版本信息。若系统化调查确认问题确属环境、时序或外部因素，应记录调查过程并实现重试、超时或错误提示等处理，但资料指出约 95% 的“无根因”情况属于调查不完整。