用途：以系统化方式调试问题，先理解再修复。通过 “/dev-debug <description of the issue>” 调用，围绕 $ARGUMENTS 中的问题描述展开。
主要能力与流程：
- 理解问题：从问题描述生成简短 slug（如 “login fails after redirect” 对应 login_redirect_fail），创建 .llm/debug_<slug>/ 目录；阅读相关代码路径并追踪逻辑，列出 2-5 个按概率排序的可能根因，写入 .llm/debug_<slug>/tmp_root_causes.md，内容包含问题重述、根因排序、原因解释、代码证据和相关文件路径；随后向用户展示根因并询问是否同意排序或指定优先修复项。
- 修复最可能根因：在用户确认后（或默认采用第 1 项）实施最小且聚焦的修改，遵循现有代码模式与约定，不做顺带重构。
- 测试：运行覆盖受影响代码路径的现有测试；若没有测试或未覆盖该情况，告知用户需手动测试的内容及预期行为；测试失败则修复并重新测试。
- 提交：暂存并提交，命令为 git add -A && git commit -m "fix: <concise description of what was fixed and why>"。
- 检查剩余问题：若未完全解决或存在相关问题，更新 .llm/debug_<slug>/tmp_root_causes.md，标记第 1 项已处理并重新排序剩余根因，回到第 2 步处理下一根因，每次修复后提交；问题解决后告知用户：Debug complete. Fixed in N commit(s). See .llm/debug_<slug>/tmp_root_causes.md for the full analysis.
适用场景：需要基于代码证据定位并修复缺陷，且希望保留分析记录和逐次提交的调试任务。
限制：资料未提供所支持的语言、框架、平台、收费方式或性能保证；流程依赖用户确认根因排序，且需要可用的测试与 Git 环境。