用途：当用户想要创建重构请求时调用此技能，帮助把重构意图整理成可执行、可评审的计划，并最终以 GitHub issue 形式提交。
主要能力与流程：先请用户描述要解决的问题及可能的解决方案；探索仓库以验证其说法并了解代码库现状；询问是否考虑过其他方案并展示备选；就实现细节进行极其详细彻底的访谈；确定实现的确切范围，明确计划改变与不改变的内容；检查该区域的测试覆盖率，若不足则询问用户的测试计划；把实现拆分为微小提交，遵循 Martin Fowler 的建议“使每个重构步骤尽可能小，以便你始终可以看到程序在工作”。
GitHub issue 模板包含：问题陈述（从开发者角度描述面临的问题）、解决方案（从开发者角度描述解决方式）、提交（长篇详细的实现计划，用通俗英语编写，拆分为尽可能小的提交，每次提交都应使代码库处于工作状态）、决策文档（已做出的实现决策，可包括将构建/修改的模块、被修改的模块接口、来自开发者的技术澄清、架构决策、模式更改、API 契约、特定交互；不要包含具体文件路径或代码片段，以免很快过时）、测试决策（良好测试的描述，仅测试外部行为而非实现细节、哪些模块将被测试、代码库中类似测试的先例）、超出范围（描述此重构范围之外的内容）、进一步说明（可选）。
使用方式：按上述步骤与用户交互，必要时可跳过不必要步骤，最终生成并提交 GitHub issue。
适用场景：计划重构、创建重构 RFC、将重构分解为安全的增量步骤。
限制：资料未提供具体安装命令、平台支持、收费或价格信息；模板明确要求不包含具体文件路径或代码片段。