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.
npx claudepluginhub oribarilan/97 --plugin 97This skill uses the workspace's default tool permissions.
**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.
Applies disciplined refactoring in small, verifiable steps to improve code structure without changing behavior: extract functions, rename, move code.
Safely refactors code using tests to improve readability, cohesion, and maintainability without changing behavior. Triggers on 'refactor', 'clean up code', 'simplify', 'reduce complexity', 'technical debt'.
Proven refactoring patterns (Extract Method, Replace Temp, Introduce Parameter Object) to improve code structure safely. Use when improving existing code while keeping behavior unchanged.
Share bugs, ideas, or general feedback.
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.