用途：处理未知 bug、脚本报错、静默失败（表面正常但结果错误）以及一般查问题场景。已知根因需直接修复、代码理解、GitHub Issue/PR 分析或部署后只读验证时，资料建议改用 /bug-fix、/code-explore、/issue-analyze、/feature-verify 等替代技能。
主要能力与流程：分为六个阶段。Phase 0 解析症状、范围与环境并尝试复现，只有可复现观察才能作为根因依据。Phase 1 按失败模式分类并选定首个探测策略。Phase 2 是假设驱动的探测循环，每轮定义假设、设计探测命令、预测预期结果、执行并观察、更新假设，最多 6 轮；若出现两个以上难以区分的竞争假设，会调用 /codex-brainstorm 做对抗辩论；连续两轮无新信息或达到轮次上限则上报人工。Phase 3 总结根因（What/Why/Impact/Evidence），必须执行 /seek-verdict --intent confirm 做独立验证，可选 /code-investigate 双视角确认。Phase 4 修复并验证：简单修复直接编辑加回归测试，复杂多文件修复交给 /bug-fix，架构级改动上报人工。Phase 5 输出 Debug Report，默认仅对话输出，可用 --export [path] 写文件。
使用方式：以 /debug 加问题描述或命令触发，例如 /debug bash scripts/deploy.sh 返回 exit code 1。探测默认只读（cat、curl -s、grep、ls、git log），写操作探测需标记 [WRITE_PROBE] 并在非沙箱环境经用户确认；单条探测超时不超过 30 秒，输出不超过 500 行，禁止记录密钥与密码，禁止 rm、drop、delete、truncate 等破坏性操作。配置项 debug.max_probe_rounds 默认 6。修复后必须回归测试并进入复审循环直至通过。
限制：该技能只除错与修复，不执行 git add/commit/push，提交需按 git-workflow 规则另行提供选项；根因声称必须基于可复现观察而非静态推测。资料未提供收费、价格与平台支持信息。