用途：遇到任何技术问题时使用，包括测试失败、生产环境 bug、异常行为、性能问题、构建失败、集成问题；尤其是在时间压力大、看似只需“快速改一下”、已尝试多次修复或未完全理解问题时。
核心原则：先找到根因再修复，修症状即失败；“未完成第一阶段调查前，不得提出修复方案”。
四个阶段： 一、根因调查：仔细阅读错误信息与完整堆栈，记录行号、文件路径、错误码；稳定复现问题（不可复现则继续收集数据，不要猜）；检查最近改动（git diff、提交、新依赖、配置、环境差异）；多组件系统（如 CI→构建→签名、API→服务→数据库）在各组件边界加诊断日志，先运行一次定位故障层，再深入该组件；深层调用栈错误可用同目录 root-cause-tracing.md 的逆向追踪技术，追到坏值来源并在源头修复。 二、模式分析：在同代码库找相似可用代码，完整阅读参考实现（不要跳读），列出可用与损坏代码的每一处差异，理解依赖、配置与环境假设。 三、假设与验证：只提出一个明确假设并写下，做最小改动、一次一个变量，验证后再继续；不成功则提新假设，不在旧修复上叠加；不理解就承认并求助或继续研究。 四、实施：先建失败测试用例（可用 test-driven-development 技能），只做一处针对根因的修改，不做顺带重构；验证测试通过且未破坏其他测试，宣称成功前使用 verification-before-completion 技能。
若修复无效：尝试少于 3 次则回到第一阶段重新分析；达到 3 次以上停止，质疑架构（反复出现新共享状态、耦合、需要大规模重构、产生新症状），与人类伙伴讨论后再继续。
红旗信号包括“先快速修一下回头再查”“改 X 试试”“一次改多处”“跳过测试手动验证”“大概就是 X”“不理解但也许有用”“再试一次修复”等，出现即停止并回到第一阶段。同目录还提供 defense-in-depth.md（根因确认后多层加校验）和 condition-based-waiting.md（以条件轮询替代固定超时）。
限制：若调查确属环境、时序或外部因素，需记录调查过程并加入重试、超时、错误提示与监控日志；但 95% 的“无根因”案例属于调查不完整。具体安装与调用方式资料未提供。