request-refactor-plan

name	request-refactor-plan
description	通过用户访谈创建包含微小提交的详细重构计划，并将其录入 GitHub Issue。当用户想要规划重构、创建重构 RFC，或将重构分解为安全的渐进步骤时使用。

当用户想要创建重构请求时，将调用此 skill。你应按照以下步骤进行。如果认为某些步骤不必要，可以跳过。

1. 请用户详细描述他们想要解决的问题以及任何潜在的解决思路。

2. 探索仓库以验证他们的陈述并了解代码库的当前状态。

3. 询问他们是否考虑过其他选项，并向他们展示其他可选方案。

4. 就实现方案对用户进行访谈。要极其详细和彻底。

5. 敲定实现的确切范围。确定你计划更改什么以及不计划更改什么。

6. 查看代码库，检查该区域是否有测试覆盖。如果测试覆盖不足，询问用户的测试计划是什么。

7. 将实现拆解为微小提交的计划。牢记 Martin Fowler 的建议："让每个重构步骤尽可能小，这样你始终能看到程序处于正常工作状态。"

8. 创建一个包含重构计划的 GitHub Issue。对 issue 描述使用以下模板：

问题陈述

开发者面临的问题，从开发者的角度描述。

解决方案

问题的解决方案，从开发者的角度描述。

提交计划

一份详细的实现计划。用通俗语言编写，将实现拆解为尽可能小的提交。每个提交应使代码库保持可工作状态。

决策文档

已做出的实现决策列表。可以包括：

• 将要构建/修改的模块
• 这些模块将修改的接口
• 开发者的技术澄清
• 架构决策
• 模式变更
• API 合约
• 具体交互

不要包含具体的文件路径或代码片段。它们可能很快就过时了。

测试决策

已做出的测试决策列表。包括：

• 关于什么构成好测试的描述（只测试外部行为，而非实现细节）
• 哪些模块将被测试
• 测试的参考先例（即代码库中类似类型的测试）

不在范围内

描述本次重构不在范围内的内容。

补充说明（可选）

关于重构的任何额外说明。