用途：在遇到任何缺陷、测试失败或异常行为时，先做根因调查再提出修复。核心原则是“没有根因调查就不修复”，症状式修补视为失败。
主要能力：提供四阶段流程。阶段一为根因调查：仔细阅读错误与堆栈、稳定复现、检查近期变更（git diff、提交、依赖、配置、环境差异），在多组件系统中于各组件边界加诊断日志以定位失败层，并沿调用栈反向追踪数据来源。阶段二为模式分析：寻找可用的相似实现、完整阅读参考实现、列出工作与故障版本的全部差异、理解依赖与假设。阶段三为假设与验证：提出单一明确假设，做最小改动、一次只改一个变量，验证后再继续。阶段四为实施：先写失败测试用例，再针对根因做单一修复，最后验证测试通过且未破坏其他测试。
使用方式：按阶段顺序执行，每阶段完成后再进入下一阶段。若修复无效，回到阶段一；若已尝试三次以上仍失败，应停止并质疑架构，与人类伙伴讨论，而非继续第四次修复。目录内还提供 root-cause-tracing.md、defense-in-depth.md、condition-based-waiting.md 等配套技术文档，并关联 agent-team:tdd 技能用于编写失败测试与验证修复。
适用场景：测试失败、生产缺陷、异常行为、性能问题、构建失败、集成问题；尤其在时间压力大、看似“只需快速修一下”、已多次尝试修复、前次修复无效或尚未完全理解问题时更应使用。
限制：资料未提供安装命令、平台支持、收费方式或具体工具集成细节，暂未提供。若系统化调查后确认问题确属环境、时序或外部因素，应记录调查过程并实现重试、超时、错误提示与监控日志；但资料指出约 95% 的“无根因”情况实为调查不完整。