---
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 描述使用如下模板：

<refactor-plan-template>

## 问题陈述（Problem Statement）

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

## 解决方案（Solution）

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

## 提交（Commits）

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

## 决策文档（Decision Document）

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

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

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

## 测试决策（Testing Decisions）

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

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

## 不在范围内（Out of Scope）

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

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

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

</refactor-plan-template>