request-refactor-plan
- 信任分
- 88/100
- 兼容 Agent
- 1
- 领域
- 工程开发
- 兼容 Agent
- Claude Code
- 信任分
- 88 / 100 · 社区维护
- 作者 / 版本 / 许可
- @mattpocock · 未声明 license
- 安装命令数
- 1 条
需要注意： 未限定 allowed-tools，默认拥有全部工具权限。
想读作者英文原文？ ↓ 滚到正文区切换 · 在 GitHub 查看 ↗
request-refactor-plan 的存在前提是：重构最大的风险不是技术，是「改到一半发现方向错了」。所以它强迫你在动一行代码之前，把问题陈述、方案、tiny commit 列表、决策、测试方案、out-of-scope 全部写进一份 GitHub issue，再开始执行。
设计思路
作者引用 Martin Fowler 的提醒：「make each refactoring step as small as possible, so that you can always see the program working」——每一步都要小到随时可回滚、随时能跑。这个技能不是直接重构，而是把重构 RFC 流程化，让人和 agent 都能盯着同一份计划干。
工作流（8 步）
① 让用户长篇详细地描述要解决的问题与初步想法；② 翻代码验证用户陈述、理解现状；③ 问是否考虑过别的方案，并主动提出备选；④ 极其详细地访谈实现细节；⑤ 把要改的 / 不改的范围钉死；⑥ 看测试覆盖，不够就问用户测试计划；⑦ 拆成「每个 commit 都让代码处于工作状态」的微步列表；⑧ 用模板创建 GitHub issue。
Issue 模板
作者给的模板包含：Problem Statement（开发者视角的问题）、Solution（开发者视角的方案）、Commits（plain English 的长详细实现计划，拆到最小 commit）、Decision Document（模块、接口、技术澄清、架构、schema、API 契约——但不写具体文件路径或代码片段，因为它们会过时）、Testing Decisions（什么是好测试、要测哪些模块、参考的同类测试）、Out of Scope（明确不做什么）、Further Notes（可选）。
适合谁
- 计划做跨模块 / 跨 schema 重构，要先和团队对齐
- 团队习惯把 RFC 走在 PR 之前
- 让 AI agent 跟人接力做长链路重构，需要一份双方都能 follow 的计划
何时不要用
- 改动只有一两个 commit、风险极低——直接做即可
- 项目没用 GitHub issue / 不接受 issue 驱动的开发节奏
配套
writing-plans（写非 RFC 类型的计划文件）、executing-plans（按计划落地）、subagent-driven-development（多 agent 接力执行 commit 列表）、ubiquitous-language（计划里用的领域术语锚定）。
This skill will be invoked when the user wants to create a refactor request. You should go through the steps below. You may skip steps if you don't consider them necessary.
Ask the user for a long, detailed description of the problem they want to solve and any potential ideas for solutions.
Explore the repo to verify their assertions and understand the current state of the codebase.
Ask whether they have considered other options, and present other options to them.
Interview the user about the implementation. Be extremely detailed and thorough.
Hammer out the exact scope of the implementation. Work out what you plan to change and what you plan not to change.
Look in the codebase to check for test coverage of this area of the codebase. If there is insufficient test coverage, ask the user what their plans for testing are.
Break the implementation into a plan of tiny commits. Remember Martin Fowler's advice to "make each refactoring step as small as possible, so that you can always see the program working."
Create a GitHub issue with the refactor plan. Use the following template for the issue description:
Problem Statement
The problem that the developer is facing, from the developer's perspective.
Solution
The solution to the problem, from the developer's perspective.
Commits
A LONG, detailed implementation plan. Write the plan in plain English, breaking down the implementation into the tiniest commits possible. Each commit should leave the codebase in a working state.
Decision Document
A list of implementation decisions that were made. This can include:
- The modules that will be built/modified
- The interfaces of those modules that will be modified
- Technical clarifications from the developer
- Architectural decisions
- Schema changes
- API contracts
- Specific interactions
Do NOT include specific file paths or code snippets. They may end up being outdated very quickly.
Testing Decisions
A list of testing decisions that were made. Include:
- A description of what makes a good test (only test external behavior, not implementation details)
- Which modules will be tested
- Prior art for the tests (i.e. similar types of tests in the codebase)
Out of Scope
A description of the things that are out of scope for this refactor.
Further Notes (optional)
Any further notes about the refactor.