refactoring-plan
GitHub指导对混乱代码进行安全、增量式重构，不改变行为。通过先建立测试安全网，再规划一系列小型、可独立提交的步骤，避免高风险的大规模重写，确保代码始终处于绿色状态。
Trigger Scenarios
Install
npx skills add mohitagw15856/pm-claude-skills --skill refactoring-plan -g -y
SKILL.md
Frontmatter
{
"name": "refactoring-plan",
"homepage": "https:\/\/mohitagw15856.github.io\/pm-claude-skills\/skill\/refactoring-plan.html",
"metadata": {
"openclaw": {
"emoji": "🪚"
}
},
"description": "Plan a safe, incremental refactor of messy code without changing behavior. Use when code needs restructuring, is hard to change, has grown tangled, or you want to clean it up before adding a feature. Produces a sequenced plan of small behavior-preserving steps, the safety net (tests\/characterization) to add first, and the target structure — refactoring as a series of green commits, not a risky big-bang rewrite."
}
Refactoring Plan Skill
Refactoring means improving structure without changing behavior — and the danger is doing it in one big risky sweep. This skill plans the opposite: a safety net first, then a sequence of small, behavior-preserving steps, each leaving the code green and committable. It separates refactoring from feature work, so you're never doing both at once.
Required Inputs
Ask for these only if they aren't already provided:
- The code & the pain — what's being refactored and why (hard to change, duplicated, slow, untestable).
- Test coverage — what tests exist around it (and the framework). If none, that's step zero.
- The goal — the target structure or what you want to make easy next (e.g. "so I can add payment provider #2").
- Constraints — what must not change (public API, behavior, performance), time budget.
Output Format
Refactoring plan: [target]
Why & goal — the current pain in one line, and what "better" enables.
Safety net (do first) — the tests that must exist before touching anything. If coverage is thin, add characterization tests that pin current behavior (even bugs) so you'd notice any change. Don't refactor untested code blind.
Target structure — a short sketch of where you're going (the shape, the seams, the names).
Steps (small & sequenced) — each step is behavior-preserving and independently committable:
| # | Step | Refactoring move | Stays green by | Commit after |
|---|---|---|---|---|
| 1 | … | (extract function / rename / introduce interface / move) | run tests | ✅ |
Order them so risk drops early and each step is reversible.
Definition of done — behavior identical (tests still green), the goal structure reached, no feature changes smuggled in.
Quality Checks
- A safety net (existing or characterization tests) is established before any change
- Every step is behavior-preserving and independently committable
- Steps are small and sequenced so the code is green throughout
- Refactoring is kept separate from behavior/feature changes
- The target structure is explicit and tied to what it makes easier next
Anti-Patterns
- Do not refactor and add features in the same commit — separate them
- Do not start without tests — add characterization tests first if coverage is thin
- Do not plan a big-bang rewrite — sequence small, reversible steps
- Do not change behavior and call it refactoring — behavior must stay identical
- Do not skip running tests between steps — that's the whole safety mechanism
Based On
Refactoring discipline (Martin Fowler): behavior-preserving transformations, characterization tests, small steps.
Version History
- 54fad50 Current 2026-07-19 12:30
