From 97
Enforces rigid pre-refactor checklist: read existing code, verify covering tests pass, state goal clearly, validate non-ego motivation, plan smallest first step. Use before restructures, renames, or cleanups.
How this skill is triggered — by the user, by Claude, or both
Slash command
/97:before-you-refactorThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
**Stop. Read the code that already exists. Understand the tests that protect it. Take small steps. Keep the tests green.** This is a **rigid** skill. Run the checklist; don't skip steps. When assessing code (not actively refactoring), steps 1–2 and 6 are the assessment; report findings without editing.
Stop. Read the code that already exists. Understand the tests that protect it. Take small steps. Keep the tests green. This is a rigid skill. Run the checklist; don't skip steps. When assessing code (not actively refactoring), steps 1–2 and 6 are the assessment; report findings without editing.
Invoke when you're about to:
If you're touching ≥3 lines of existing non-trivial logic to change its shape (not its behavior), invoke this skill.
clean-code instead)If you're not sure whether a change counts as a refactor, invoke anyway — the checklist is cheap, the consequence of skipping it is not.
Run every step in order. Do not start editing until step 5 is satisfied.
main before you change anything. If there are no tests, stop and add a characterization test that pins down current behavior before touching the code. (Attapattu, 97/6 — "Ensure existing tests pass after each iteration.")These thoughts mean STOP — restart the checklist:
| Thought | Reality |
|---|---|
| "I'll just rewrite this from scratch — it'll be faster." | Throwing away tested, battle-hardened code throws away every bug fix and edge case it absorbed. The rewrite will rediscover those bugs the slow way. (97/6) |
| "There are no tests, but the change is obvious." | "Obvious" is how production breakages are born. Pin behavior with a characterization test first, then refactor. (97/6) |
| "I'll do it all in one big PR — easier to review." | Big PRs hide bugs and frustrate reviewers. Many small commits keep tests green and changes reviewable. (97/6, 97/24) |
| "The old code is ugly and uses outdated patterns — I should modernize it." | Style is not a refactor goal. New framework / new language / personal preference are not valid reasons. State the actual user-visible benefit or stop. (97/6) |
| "It's just a small cleanup, no need for a checklist." | The small cleanups are exactly where the worst tangles hide. Run the checklist. (97/74) |
| "I'll fix everything I see while I'm in there." | Boy Scout rule says a little better, not perfect. Bounded improvement only. Write the rest down for later. (97/8) |
| "I can patch it directly on the staging/production server, just this once." | No. Refactors flow through your normal commit → test → review → deploy path. "Just this once" is how outages happen. (97/31) |
| "The tests are failing but it's just flaky — I'll keep going." | Failing tests during a refactor mean the refactor changed behavior. Stop, investigate, fix or revert. Don't push through. (97/6) |
| "Estimating is too hard — I'll figure it out as I go." | Open-ended refactors balloon. Identify the coupling hotspots up front and re-estimate. If it's now bigger than the ask, escalate. (97/74) |
| "I'll just rename some variables — the function isn't that long." | If the function scrolls, renaming alone won't help. Extract helpers whose names explain the why; the body shrinks to a sequence of named steps. (Fowler/LongMethod) |
| "The function does X and also Y, but they're related." | If you needed "and also" to describe the unit, it has more than one reason to change — the SRP refactoring trigger. State the unit's responsibility in one sentence; if you can't without "and also," split. See clean-code decision 4 for the discipline of writing the result. (97/76) |
| "The same change keeps forcing me to edit the same eight files." | Shotgun surgery: the behavior is conceptually one thing, physically scattered. Move related fields and methods together until the next instance of the change is one file. (Fowler/ShotgunSurgery) |
| "This function already takes seven primitives — I'll just add an eighth." | Data clump. The fields are a missing type. Extract a class / dataclass / parameter object before adding the eighth. (Fowler/DataClumps) |
| "Everything lives in one file — it's easier to find when it's all together." | Co-location by import convenience is not a single responsibility. If the pieces change for different reasons, split the module along the axes of change. (97/76) |
You are done when all of the following are true:
superpowers/test-driven-development).TODO: finish this.If any box is unchecked, you are not done. Either finish, or revert and re-plan.
| # | Principle | Author |
|---|---|---|
| 97/6 | Before You Refactor | Rajith Attapattu |
| 97/8 | The Boy Scout Rule | Robert C. Martin |
| 97/24 | Don't Be Afraid to Break Things | Mike Lewis |
| 97/31 | Don't Touch That Code! | Cal Evans |
| 97/74 | The Road to Performance Is Littered with Dirty Code Bombs | Kirk Pepperdine |
| 97/76 | The Single Responsibility Principle / SRP (refactoring trigger) | Robert C. Martin |
Fowler/LongMethod | Long Method → Extract Function | Martin Fowler |
Fowler/FeatureEnvy | Feature Envy → Move Method | Martin Fowler |
Fowler/ShotgunSurgery | Shotgun Surgery → Move Field / Inline Class | Martin Fowler |
Fowler/DataClumps | Data Clumps → Extract Class / Introduce Parameter Object | Martin Fowler |
See principles.md for the long-form distillations, citations, and source links.
npx claudepluginhub oribarilan/97 --plugin 97Applies disciplined refactoring in small, verifiable steps to improve code structure without changing behavior: extract functions, rename, move code.
Guides safe refactoring using Code Complete's fix-first-then-refactor discipline: separates bug fixes from refactoring, enforces small-change rigor, and helps decide between refactor, rewrite, or fix-only.
Proven refactoring patterns (Extract Method, Replace Temp, Introduce Parameter Object) to improve code structure safely. Use when improving existing code while keeping behavior unchanged.