用途：把错误追踪、可观测性、监控或崩溃上报工具暴露的缺陷，或他人粘贴的堆栈、日志、失败请求，转化为有证据支撑的根因，并在项目设计认为拥有该规则的位置落地修复——该位置往往不是错误被观察到的地方。
主要能力：这是一套方法而非工具，包含四项承诺：先复现再立论；隔离起源，剥离非关键层，区分“起源”与“显现点”；用可证伪假设驱动根因，一次只改一个变量；在设计正确的位置修复。流程分阶段：分诊追踪事件、确定性复现、最小化隔离、提出三到五个可证伪假设并逐一验证、运行“位置门”决定责任层、在责任层修复并写回归测试、闭环（更新追踪工具、验证不再复现、写简短复盘）。
使用方式：运行时先发现项目自身的约定并遵循。需发现两类信息：一是可观测性与错误追踪面（配置文件、环境变量、MCP 服务器、已装 SDK、仪表盘、项目文档），从中提取错误类型与消息、完整堆栈、变量与面包屑、会话回放、版本、环境、是否已处理、客户端或服务端、请求上下文、频率与首次出现、source map 等；二是设计约定（AGENTS.md、CLAUDE.md 等代理说明、风格指南、架构与设计文档、仓库内其他设计技能），据此判断不变量、校验、授权、业务逻辑所在层与模块边界。若缺少决策所需约定，应明确指出并询问人类，不得替项目发明架构或错误模型。
适用场景：通过错误追踪、可观测性、监控或崩溃上报工具报告的缺陷；提供堆栈、异常、日志行、失败请求或崩溃报告；要求找出失败原因并修复而非仅消除某个错误；运行系统中间歇性、依赖环境、数据或时序的失败。
限制：不适用于实现无失败可诊断的新行为、已复现且只需明显修改的本地测试、或明确要求压制告警而不解决原因（应指出原因未被处理）。修复位置应选拥有该规则的最高层，而非最快让测试变绿的最低层；逃逸到追踪器的未处理异常通常意味着错误模型缺口，应在上游建模或处理。资料未提供具体安装命令、收费或平台信息。