用途：当用户希望规划一次重构请求时使用。该技能会引导完成访谈流程，并在范围完全达成一致前，不创建 GitHub issue 或编写重构计划。
主要流程：先请用户详尽描述要解决的问题及可能的解法思路；浏览代码仓库核实其说法并了解当前代码状态；询问是否考虑过其他方案，并给出其他选项；就实现细节进行非常详细彻底的访谈；敲定确切的实现范围，明确计划改什么、不改什么；检查代码库中该区域的测试覆盖情况，若覆盖不足则询问用户的测试计划；把实现拆解为“微小提交”计划，遵循 Martin Fowler 的建议——让每个重构步骤尽可能小，以便始终能看到程序正常运行。
产出：创建一个 GitHub issue，描述按模板组织，包含问题陈述（从开发者视角描述其面临的问题）、解决方案（从开发者视角给出解法）、提交计划（用平实英文写成尽可能细的微小提交，每个提交都应让代码库保持可运行状态）、决策文档（列出所做实现决策，可含将构建/修改的模块、被修改的模块接口、开发者的技术澄清、架构决策、schema 变更、API 契约、具体交互；不要包含具体文件路径或代码片段，以免很快过时）、测试决策（含好测试的描述，即只测外部行为而非实现细节、要测试哪些模块、可参考的同类测试先例）、范围外（说明本次重构不涉及的内容）、进一步说明（可选）。
限制：访谈步骤完成且范围达成一致前不得创建 issue 或写计划；计划中不写具体文件路径与代码片段。