| name | request-refactor-plan |
| description | 通过用户访谈创建一份由微小 commits 组成的详细 refactor plan,并将其提交为 GitHub issue。适用于用户希望规划 refactor、创建 refactoring RFC,或将 refactor 拆分为安全的增量步骤。 |
当用户希望创建 refactor request 时调用此 skill。按照下列步骤执行;你认为某些步骤没有必要时可以跳过。
-
请用户详细描述希望解决的问题,并说明可能考虑过的解决思路。
-
探索仓库,验证用户的判断,并理解 codebase 当前状态。
-
询问用户是否考虑过其他选项,同时向他们提出其他选项。
-
围绕实现方案访谈用户。访谈必须非常细致、全面。
-
确定实现的精确范围。明确计划修改什么,以及明确不修改什么。
-
在 codebase 中检查相关区域的 test coverage。覆盖不足时,询问用户准备如何测试。
-
将实现拆成一份由微小 commits 构成的计划。记住 Martin Fowler 的建议:“make each refactoring step as small as possible, so that you can always see the program working.”
-
创建包含 refactor plan 的 GitHub issue。Issue description 使用以下模板:
问题陈述
从开发者视角描述他们面对的问题。
解决方案
从开发者视角描述问题的解决方案。
Commits
一份篇幅充分、细节完整的实现计划。使用直白英语编写,把实现拆成尽可能小的 commits。每个 commit 完成后,codebase 都必须保持可工作状态。
决策文档
列出已经作出的实现决策,可以包括:
- 将要构建或修改的 modules
- 将要修改的 module interfaces
- 来自开发者的技术澄清
- 架构决策
- Schema changes
- API contracts
- 具体交互
不要包含具体文件路径或代码片段。它们可能很快过时。
测试决策
列出已经作出的测试决策,包括:
- 描述好测试的标准(只测试外部 behavior,不测试 implementation details)
- 将测试哪些 modules
- 可参考的既有 tests(codebase 中类似类型的测试)
范围外内容
描述本次 refactor 明确不处理的事项。
补充说明(可选)
与 refactor 相关的其他说明。