用途：用于遇到任何 bug、测试失败或异常行为时，在提出修复前进行系统化排查。资料强调核心原则：先找到根因再动手修复，症状式修补视为失败。
主要能力：提供四阶段流程。阶段一根因调查：仔细读错误与栈、稳定复现、检查近期改动、在多组件系统中于各组件边界加诊断日志收集证据、沿调用栈向上追踪数据流（深层错误需配合 trace 技能）。阶段二模式分析：找同一代码库中相似的可用实现、完整阅读参考实现、列出所有差异、理解依赖。阶段三假设与验证：提出单一明确假设并写下，做最小改动只验证一个变量，成功进入阶段四，失败则重提新假设而非叠加修复。阶段四实现：按复杂度决定是否写测试，复杂算法、业务逻辑、数据转换建议写确定性单元测试；UI 组件、React hooks、简单 CRUD、映射等可跳过，改用类型检查、lint 和手动验证。一次只做一个修复，验证根因已解决且无回归。
限制与规则：若修复两次仍失败，应返回阶段一重新分析；累计三次以上失败则停止并质疑架构，与人类伙伴讨论，而非继续尝试第四个修复。资料列出多种需停止并回归流程的红旗信号，以及常见合理化借口与其反驳。资料指出多数“无根因”情况实为调查不完整；若确属环境、时序或外部因素，应记录调查内容并加监控日志。集成方面明确需要 trace 技能，测试可选 tdd。
适用场景：测试失败、生产缺陷、意外行为、性能问题、构建失败、集成问题，尤其适用于时间紧迫、看似有“快速修复”、已多次尝试修复或尚未完全理解问题的情况。
缺失信息：安装方式、具体命令示例与运行入口暂未提供。