用途：面向既有代码库的缺陷诊断与修复，强调“bug 是证据”，目标是找出真实行为与预期模型不一致的原因，在正确层级修因，而非让症状消失。其核心主张是速度来自理解而非敲代码。
主要能力与原则：先读后写，禁止编辑未完整阅读的文件，不猜 API、字段名或调用签名；不把注释、文档、提交信息、工单当作事实，只有可执行代码与观察到的行为是证据；先复现再诊断，再修复；修根因而非症状，若写不出一句“缺陷因 X 产生，因此正确修复处是 Y”即诊断未完成；像架构师思考、像外科医生动手，做最小且正确的切口；不写多余代码，不做投机抽象、顺手重构；用证据验证，修复前后需有测试失败转通过；同类缺陷常不止一处，要搜索克隆并报告；当正确修复会改变契约、删除数据、改变安全行为或超出范围时应停止并询问。
工作流分阶段：0 框定问题（观察行为、预期行为及其来源、范围与影响面、环境与版本、近期变更）；1 确定性复现（最小可靠复现，优先写成失败测试，间歇性问题需量化，无法复现则明说并转为收集日志、追踪、指标等证据）；2 读代码并绘制领域（从失败点向外追踪调用与数据流，识别层边界与契约、未强制的不变量，查 git 历史，盘点可复用工具）；3 找真正根因（假设循环，五问法，差分分析、二分、插桩、逆向追踪等，并按输入校验、契约不匹配、状态生命周期、并发、逻辑、配置、资源、集成、设计等分类决定修复位置）；4 像架构师一样设计修复（修复应属于拥有不变量的层级，最小改动，评估影响面、兼容性与迁移、可能破坏什么、是否产生重复）；5 实施（只改诊断所需，匹配现有约定，正确处理错误，原子提交，删除死代码，不为通过而削弱测试或安全控制）；6 验证（复现测试改前失败改后通过，补测根因类别，跑相关测试，核对影响面，并发/性能/内存用测量验证，搜索克隆，确认症状因预测的原因消失）；7 报告（症状、根因、明显修法为何不对、修复内容与层级、验证、影响面与兼容性、未修复的相关发现）。
限制与说明：资料还提到症状补丁与根因修复的对比（吞异常、空值兜底、sleep 重试、特例硬编码、跳过失败测试等反模式），以及生产事故中可接受临时缓解但需标注、可回滚、记录后续跟进；另含系统思维检查清单。完整根因技术、反模式与报告模板位于 references/root-cause-techniques.md、references/anti-patterns.md、references/report-templates.md。资料未提供安装命令、收费方式或平台信息。