用途：该技能用于规范 AI 代理处理任何技术问题的流程，包括测试失败、生产或本地缺陷、构建与 CI 流水线失败、无法解释的性能问题。其核心原则是先找到根因再尝试修复，铁律是未经根因调查不得动手修复；即使问题看似简单、时间紧迫或用户要求快速修复，也不跳过流程。
主要能力与阶段：第一阶段规划与根因调查。完整阅读错误信息与堆栈跟踪，记录准确文件路径与行号；用 view_file 读取出错处周边代码，用 grep_search 查找相关定义、用法与配置；在未检查或列目录前不假设文件内容。随后复现与隔离：确认能否稳定触发缺陷，若无现成测试则编写最小独立复现脚本（如 /tmp/ 下的 repro.py 或 repro.js），用 write_to_file 写入并通过 run_command 执行；无法本地复现则继续收集数据而非猜测。多组件系统需划定边界，例如前端到 API 再到数据库，不得猜测哪一层出错，可临时用 replace_file_content 在各组件边界加入 console.log、print() 或 logger，运行一次观察各层输入输出。
第二阶段执行假设与最小修复。根因被证明显非猜测后，先明确陈述单一假设再改代码；用 replace_file_content 一次只改一个变量，做最小改动验证假设；不要夹带格式化重构、清理或无关拼写修正；用第一阶段复现脚本或失败测试验证，若通过且不破坏邻近测试则视为证明已解决。
第三阶段验证与三振规则。确认最小改动是否解决问题、是否破坏邻近测试；若修复失败须立即还原并停止，不在失败修复上叠加新修复，并依据新失败重新评估假设。若已尝试三种不同修复仍失败，必须立即停止改代码，很可能面对根本架构缺陷、错误底层假设或幻觉依赖；此时应写下失败模式总结（例如 /tmp/bug-report.md）并通知用户进行架构对齐讨论，不得继续默默猜测。
危险信号：出现“先快速修复以后再调查”“改个 X 试试看”、未读出错文件内容就提方案、单次修复包含三个以上无关改动、每修好一个问题就冒出新的无关缺陷等情况时，说明违反协议，应停止并回到第一阶段。
使用方式与限制：技能通过自动触发使用，资料中给出的工具与命令包括 view_file、grep_search、write_to_file、run_command、replace_file_content；关于安装命令、具体平台支持、收费与价格，资料暂未提供。