request-refactor-plan

name	request-refactor-plan
description	通过用户访谈创建一份带有微小提交（tiny commits）的详细重构计划，然后将其作为 GitHub issue 提交。当用户想规划一次重构、创建重构 RFC，或将一次重构拆分为安全的增量步骤时使用。

当用户想要创建一份重构请求时，会调用本技能。你应当按照下面的步骤进行。如果你认为某些步骤没有必要，可以跳过。

1. 请用户给出一段对他们想解决的问题的长篇、详细描述，以及任何可能的解决思路。

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

3. 询问他们是否考虑过其他方案，并向他们呈现其他方案。

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

5. 敲定实现的确切范围。弄清楚你计划改动什么、不打算改动什么。

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

7. 把实现拆分成一份由微小提交组成的计划。记住 Martin Fowler 的建议："让每一步重构尽可能小，这样你始终能看到程序正常运行。"

8. 创建一个 GitHub issue，写入重构计划。issue 描述使用以下模板：

问题陈述

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

解决方案

针对该问题的解决方案，从开发者的视角描述。

提交（Commits）

一份长篇、详细的实现计划。用平实的语言来写，把实现拆分成尽可能微小的提交。每一个提交都应让代码库保持在可运行状态。

决策文档

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

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

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

测试决策

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

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

范围之外

对本次重构范围之外内容的描述。

补充说明（可选）

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