用途：recursive-debugging 是 recursive-mode 工作流中的 Phase 1.5 阶段技能，用于在需求涉及修复缺陷、调查测试失败或异常行为、性能问题、集成问题时执行系统化调试。其铁律是：未先完成根因调查，不得实施修复；只治症状视为失败。
主要能力：按四个步骤推进。步骤一为根因调查，包括逐字阅读报错与堆栈、确认可稳定复现、检查最近变更（git 历史、依赖、配置、环境）、在多组件系统各边界加诊断埋点以定位失败层，以及从错误位置沿调用栈反向追踪坏值来源。步骤二为模式分析，找出可用的相似实现、完整阅读参考实现、列出工作代码与故障代码的全部差异、梳理依赖与假设。步骤三为假设与验证，一次只提一个明确假设，做最小改动测试，失败则重新形成假设，不得叠加修复。步骤四为修复交接，先写最小失败测试用例，再向 Phase 2 输出根因摘要与修复方案。
使用方式：当 Phase 1 识别出需要修复的缺陷时，锁定 01-as-is.md，新建 01.5-root-cause.md 并置为 DRAFT，执行上述调查，找到根因后锁定该文件，再进入 Phase 2。工件路径为 /.recursive/run/<run-id>/01.5-root-cause.md，内含错误分析、复现验证、最近变更、多层证据、数据流追踪、模式分析、假设测试、根因摘要、覆盖门与审批门等小节；文件同时提供 TODO、覆盖检查清单与审批检查清单模板。若调试涉及委派评审、外部日志检查等路由模型协助，须在选用委派 CLI/模型前重新读取 /.recursive/config/recursive-router.json 与 /.recursive/config/recursive-router-discovered.json，遵循当前路由策略，不得硬编码模型假设。
适用场景：时间紧迫、看似只需一处快速修复、此前修复已失败、对问题尚未完全理解时尤其适用；简单问题、赶进度、被要求立即修复时也不应跳过。
限制：技能明确列出应停止的自我提示（如先快速修再调查、一次改多处、凭感觉猜 X、跳过测试手动验证），以及常见借口与现实的对照。若修复尝试达 3 次以上仍失败，应停止并质疑架构，记录架构性担忧并考虑重构、升级或接受风险。该技能不提供具体语言或框架的调试工具、命令与配置，相关资料暂未提供。