request-refactor-plan

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

该技能在用户想要创建重构请求时被调用。你应该按照以下步骤进行。如果你认为某些步骤不必要，可以跳过。

1. 请用户详细、长篇地描述他们想要解决的问题，以及任何潜在的解决方案思路。

2. 探索仓库以验证用户的断言，并了解代码库的当前状态。

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

4. 与用户面谈实现细节。要做到极其详细和全面。

5. 敲定实现的确切范围。确定你计划修改的内容和计划保持不变的内容。

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

7. 将实现拆分为一系列微小提交。记住 Martin Fowler 的建议："让每个重构步骤尽可能小，这样你就能始终看到程序在正常工作。"

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

问题陈述

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

解决方案

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

提交计划

一个详细的实现计划。用通俗易懂的英文编写计划，将实现拆分为尽可能小的提交。每个提交都应使代码库保持可工作状态。

决策文档

一份已做出的实现决策清单。可以包括：

• 将要构建/修改的模块
• 将要修改的模块接口
• 来自开发者的技术澄清
• 架构决策
• Schema 变更
• API 契约
• 特定的交互

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

测试决策

一份已做出的测试决策清单。包括：

• 什么样的测试才算好测试的描述（只测试外部行为，不测试实现细节）
• 哪些模块将被测试
• 测试的参考先例（即代码库中类似类型的测试）

不在范围内

描述本次重构不涉及的内容。

补充说明（可选）

关于重构的任何补充说明。