| name | request-refactor-plan |
| description | 通过用户访谈创建一个详细的重构计划，并将其拆分成很小的提交（tiny commits），最后以 GitHub issue 的形式归档。适用于用户希望规划一次重构、创建重构 RFC，或把重构拆成安全的渐进步骤。 |
当用户希望创建“重构请求（refactor request）”时会调用本技能。你需要按下方步骤执行；如果你认为某些步骤不必要，可以跳过。
-
向用户索要一份长篇、细节充分的问题描述：他们想解决的是什么问题；以及任何可能的解决想法。
-
探索仓库：用于验证用户的判断，并理解当前代码库状态。
-
询问用户是否考虑过其他方案，并把这些备选方案一并呈现给用户。
-
围绕实现方案对用户进行访谈：要尽可能详细、透彻。
-
明确重构实现的准确范围：梳理你计划改什么、以及你计划不改什么。
-
查看代码库中该区域的测试覆盖情况：如果测试覆盖不足，询问用户他们打算如何安排测试。
-
把实现拆解成“由一串微小提交组成”的计划。记住 Martin Fowler 的建议：让每一步重构都尽可能小，以便你随时能看到程序仍然在工作。
-
使用该重构计划创建 GitHub issue。issue 描述使用如下模板：
问题陈述（Problem Statement）
从开发者视角来看，开发者正在面临的问题。
解决方案（Solution）
从开发者视角来看，针对该问题的解决方案。
提交（Commits）
一份很长、很详细的实现计划。请用通俗英文（plain English）来写，尽可能把实现拆分成“最小粒度”的提交。每一次提交都应保证代码库处于可工作的状态。
决策文档（Decision Document）
实现决策列表。可能包括：
- 将要构建/修改的模块
- 将要修改的这些模块的接口
- 开发者提供的技术澄清
- 架构层面的决策
- schema 变更
- API 合约
- 具体交互方式
不要包含具体文件路径或代码片段。这些内容很可能会在很快之后变得过时。
测试决策（Testing Decisions）
测试决策列表。需要包含：
- 什么才算是“好测试”（只测外部行为，不测实现细节）
- 将要被测试的模块
- 测试的先例/参考（即仓库中类似类型测试的对照）
不在范围内（Out of Scope）
描述本次重构明确不包含哪些内容。
进一步备注（Further Notes，可选）
关于该次重构的其他补充说明。
