用途：帮助用户在动手重构前制定结构化计划，把大型改动拆解为连续的小步骤。适用场景包括规划重构、需要重构策略，或希望把大改动拆小的时候。
主要流程：
- 理解问题：获取用户对问题的详细描述，询问其已考虑过的方案，并探索代码库核实当前状态。
- 定义范围：就实现细节访谈用户，给出带取舍说明的替代方案（可用时用 AskUserQuestion 让用户选择，否则以编号列表呈现）；明确哪些改动、哪些保持不变；检查受影响区域的测试覆盖。
- 拆解工作：遵循 Martin Fowler 的原则“让每个重构步骤尽可能小，以便始终能看到程序正常工作”，列出极小的提交；每个提交都保持代码库可运行；变更按顺序推进而非并行。
- 创建 GitHub Issue：用 gh issue create --title "Refactor: <title>" --body "$(cat <<'EOF' … EOF)" 生成 Issue，包含问题陈述、解决方案、提交计划、实现决策、测试决策和范围外内容。
规则与限制：每个提交必须保持代码库可用；计划中不写实现细节（聚焦行为）；开始前核实测试覆盖；方案需获用户批准。Issue 正文不要包含文件路径或代码片段，以免过时。
错误处理：若 gh issue create 失败，运行 gh auth status 验证认证，或改为输出 Markdown；若测试覆盖不足，记录缺口并把“为 X 添加测试”作为第一个提交；若范围超出预期，先与用户修订计划再继续。另可参见 tdd 技能，用测试驱动开发实现重构后的代码。
其他：价格、平台支持范围等信息资料未提供。