用途：code-debug 是一套针对疑难 bug 和性能回归的纪律化诊断循环，核心流程为复现→最小化→假设→插桩→修复→回归测试。除有明确理由外，不应跳过阶段。探索代码库时建议使用项目领域术语表建立模块心智模型，并查看相关 ADR。
主要能力：第一阶段构建反馈回路，这是整个技能的关键。可用失败测试（单元/集成/e2e）、对开发服务器的 curl/HTTP 脚本、带固定输入的 CLI 调用并对比 stdout 快照、无头浏览器脚本（Playwright/Puppeteer）、回放捕获的 trace、一次性最小 harness、属性/模糊测试、二分 harness、新旧版本差分对比，以及最后手段的人机 bash 脚本。回路本身也要迭代：更快、信号更锐利、更确定。非确定性 bug 的目标是提高复现率而非干净复现。
使用方式：第二阶段运行回路并确认复现的是用户描述的症状；第三阶段先列出 3–5 个可证伪的排序假设，格式为“若 X 是原因，则改变 Y 会使 bug 消失/改变 Z 会使其加重”，可先给用户看以利用其领域知识；第四阶段每个探针须对应具体预测，一次只改一个变量，优先调试器/REPL，日志须带唯一前缀如 [DEBUG-a4f2]；性能分支应先建立基线测量再二分。第五阶段先写回归测试再修复，但仅在存在正确接缝时；若无正确接缝，这本身就是发现，应记录并标记架构问题。第六阶段清理插桩、删除临时原型、确认原复现不再出现、回归测试通过，并在提交信息中写明正确假设。
适用场景：难以定位的 bug、性能回归、非确定性故障、需要结构化排查流程的调试任务。
限制：资料未提供具体安装命令、平台支持、收费方式或效果保证；无反馈回路时不应进入假设阶段，而应明确说明并请求环境访问、捕获产物或临时生产插桩权限。输出格式为调试总结，包含问题、根因、修复、验证与预防。