request-refactor-plan

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

当用户想要创建重构请求时, 将调用此技能. 你应该执行以下步骤. 如果你认为没有必要, 可以跳过步骤.

1. 询问用户对他们想要解决的问题的详细描述以及任何潜在的解决方案想法.

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

3. 询问他们是否考虑过其他选项, 并向他们展示其他选项.

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

5. 敲定实现的确切范围. 明确你计划更改什么和不计划更改什么.

6. 在代码库中查找此区域的测试覆盖率. 如果测试覆盖率不足, 询问用户他们的测试计划是什么.

7. 将实现分解为微小提交的计划. 记住 Martin Fowler 的建议: "使每个重构步骤尽可能小, 这样你就可以始终看到程序正常工作."

8. 使用以下模板为 issue 描述创建 GitHub issue:

问题陈述

从开发人员的角度描述开发人员面临的问题.

解决方案

从开发人员的角度描述问题的解决方案.

提交

一个详细的实现计划. 用简单的英语编写计划, 将实现分解为尽可能小的提交. 每个提交都应该使代码库保持在工作状态.

决策文档

已做出的实现决策列表. 这可以包括:

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

不要包含特定文件路径或代码片段. 它们可能很快就会过时.

测试决策

已做出的测试决策列表. 包括:

• 对什么是好测试的描述(仅测试外部行为, 而非实现细节)
• 将要测试的模块
• 测试的先例(即代码库中类似类型的测试)

范围外

对此重构范围外事项的描述.

进一步说明(可选)

关于该重构的任何进一步说明.