用途：在真正实施修复之前，先生成一份完整的缺陷修复计划，并进行根因分析。它面向的是“先调查、后修改”的工作流，适合遇到需要先弄清成因再修的缺陷时使用。
主要能力：它会在 specs/*.md 中创建新计划，并严格按照指定的 Markdown 计划格式书写，不直接改代码。技能要求使用推理模型深入思考根因与解决方案，调查代码库以理解缺陷可能如何发生，并聚焦于相关文件。计划需填满格式中的每一个章节，其中根因分析被视为关键部分。计划还应包含能证明缺陷已修复且不会引发回归的验证命令，并考虑可能存在相同问题的相关代码。
必要用法：调用时会在 specs/ 下按 bug-<descriptive-name>.md 的命名生成计划文件。计划格式包含以下章节：Bug 描述、问题陈述、解决方案陈述、复现步骤（含预期与实际结果）、根因分析、相关文件、分步任务、验证命令、备注。相关资料建议关注的文件包括 README.md（项目结构）、CLAUDE.md（智能体说明，若存在）、src/ 或 app/（待调查的源代码）、tests/**（现有测试与测试模式），以及提供的错误日志或堆栈跟踪。验证命令示例包括运行 <test command> 验证修复、按上述步骤复现以确认解决、运行 <test suite> 检查回归。
适用场景与限制：适用于已有缺陷需要先规划、暂不实施修复的场合。它只产出计划文档，不负责编写修复；具体命令、文件路径与项目细节依赖实际仓库提供。资料的介绍中未给出的内容，如收费、价格、支持平台与具体效果，暂未提供。