plan-refactor

Plan behavior-preserving refactors as risk-ranked, always-green step sequences before editing code.

1|Updated Jul 13, 2026
One-click install
npx skills add https://github.com/dineshrevunuru/SuperSkills --skill plan-refactor-dineshrevunuru
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: plan-refactor
Source: https://github.com/dineshrevunuru/SuperSkills/tree/main/plan-refactor
Command: npx skills add https://github.com/dineshrevunuru/SuperSkills --skill plan-refactor-dineshrevunuru

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Vague requests like "just clean this up" invite big-bang rewrites that leave code red for days with no proof behavior survived. This Skill turns a refactor you're about to start into a plan whose every step keeps the program green and behavior unchanged, so you can always stop, ship, or tell if you broke something. ## Core Features & Use Cases - Risk-ranked sequencing: Reads blast radius, seams crossed (money/auth/data paths), and test coverage for each area, then orders steps so the highest-risk area is covered first and touched last. - Characterization tests first: Pins current behavior (bugs and all) with snapshot tests at the seam before restructuring, so any moved behavior shows up instantly. - Mode-switchable rigor: A scrappy 5-minute path for trivially reversible cleanups, and a full rigor path (scope in/out, risk read, always-green steps, stop points) for anything crossing a seam. - Use Case: Given a 400-line checkout.ts mixing cart math, tax calc, and a Stripe call, produce a plan that extracts computeTotals behind a small interface, snapshots today's totals first, and defers the duplicated refund-path collapse to a covered final step. ## Quick Start Ask the AI to plan a safe refactor of a messy module before touching it, for example: "checkout.ts is a mess — plan a behavior-preserving refactor with characterization tests and always-green steps."

Frequently Asked Questions about plan-refactor

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I plan a safe refactor before changing legacy code?

Fix the concrete target shape first, then rank each area by blast radius, seams crossed, and test coverage. Write characterization tests that pin current behavior, then sequence small always-green steps with the highest-risk area covered first and touched last.

What are characterization tests and when should I write them?

Characterization tests capture what code does today, bugs and all, rather than what it should do. Write them before restructuring any code with thin coverage, so a moved behavior shows up instantly as a test failure instead of a silent regression.

How do I avoid a big-bang rewrite when cleaning up a messy module?

Sequence the work into small steps that each compile, pass tests, and could ship alone, preferring parallel change (new form beside old, migrate, delete) over a flag day. Put the hardest, least reversible step last after the seam is covered.

When should I not use a refactor planning approach?

Skip it when you don't yet know which area to refactor (use architecture scanning first), when the target shape is undecided (decide the module design first), or when the work adds new user-visible behavior, which is feature slicing rather than refactoring.

Can a behavior change be included inside a refactor?

No. A refactor preserves behavior by definition, so any intended behavior change must be split out as its own separate step before or after. Smuggling it in means a red test suite could mean either a regression or the intended change, and you cannot tell which.