request-refactor-plan

name	request-refactor-plan
description	通过用户访谈创建一个详细的重构计划，并将其拆分成很小的提交（tiny commits），最后以 GitHub issue 的形式归档。适用于用户希望规划一次重构、创建重构 RFC，或把重构拆成安全的渐进步骤。

当用户希望创建“重构请求（refactor request）”时会调用本技能。你需要按下方步骤执行；如果你认为某些步骤不必要，可以跳过。

1. 向用户索要一份长篇、细节充分的问题描述：他们想解决的是什么问题；以及任何可能的解决想法。

2. 探索仓库：用于验证用户的判断，并理解当前代码库状态。

3. 询问用户是否考虑过其他方案，并把这些备选方案一并呈现给用户。

4. 围绕实现方案对用户进行访谈：要尽可能详细、透彻。

5. 明确重构实现的准确范围：梳理你计划改什么、以及你计划不改什么。

6. 查看代码库中该区域的测试覆盖情况：如果测试覆盖不足，询问用户他们打算如何安排测试。

7. 把实现拆解成“由一串微小提交组成”的计划。记住 Martin Fowler 的建议：让每一步重构都尽可能小，以便你随时能看到程序仍然在工作。

8. 使用该重构计划创建 GitHub issue。issue 描述使用如下模板：

问题陈述（Problem Statement）

从开发者视角来看，开发者正在面临的问题。

解决方案（Solution）

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

提交（Commits）

一份很长、很详细的实现计划。请用通俗英文（plain English）来写，尽可能把实现拆分成“最小粒度”的提交。每一次提交都应保证代码库处于可工作的状态。

决策文档（Decision Document）

实现决策列表。可能包括：

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

不要包含具体文件路径或代码片段。这些内容很可能会在很快之后变得过时。

测试决策（Testing Decisions）

测试决策列表。需要包含：

• 什么才算是“好测试”（只测外部行为，不测实现细节）
• 将要被测试的模块
• 测试的先例/参考（即仓库中类似类型测试的对照）

不在范围内（Out of Scope）

描述本次重构明确不包含哪些内容。

进一步备注（Further Notes，可选）

关于该次重构的其他补充说明。