用途：该技能面向所有技术问题，包括测试失败、生产环境缺陷、意外行为、性能问题、构建失败和集成问题。尤其适用于时间紧迫、看似只需“快速修一下”、已尝试多次修复、上一次修复无效或尚未完全理解问题等场景。
主要能力：以四阶段流程约束调试行为。第一阶段根因调查：仔细阅读错误信息和完整堆栈，稳定复现问题，检查最近变更（git diff、提交、新依赖、配置），在多组件系统中于各组件边界加诊断日志以定位失败层，并沿调用栈向上追溯数据来源。若错误深在调用栈中，要求配合 trace 技能进行反向追踪。第二阶段模式分析：寻找同代码库中可用的相似实现，完整阅读参考实现，逐条列出可用与故障实现之间的差异，理解依赖、配置和环境假设。第三阶段假设与验证：写出单一明确的假设，做最小改动逐一验证变量，验证不通过则提出新假设，而不是继续叠加修复。第四阶段实施：判断是否编写测试，复杂算法、业务逻辑、数据转换等易出错处写确定性单元测试，UI 组件、React hooks、简单 CRUD 可跳过测试改用类型检查、lint 或人工验证；只做一处改动，不加“顺便”改进，随后验证问题是否解决、有无回归。
限制与边界：同一问题修复尝试达到 3 次仍未解决时，应停止并质疑架构，而不是尝试第 4 次修复。文档指出“无根因”结论中约 95% 属于调查不完整。修复 UI 组件时不建议编写单元测试，应通过类型检查或人工验证确认。使用该技能前不得跳过第一阶段；正文未提供安装命令、URL 用法、收费信息或具体平台支持，这些事实暂未提供。