Safe step-by-step refactoring plan

Plan a refactor as small, reversible steps that keep tests green, instead of a risky big rewrite.

LLazyPrompt(@lazyprompt)CodingPlanWorks with any model
No ratings yetSign in to rate
Save 0 Fork Report
Prompt template
Create a refactoring plan for the {{language}} code below.

Goal of the refactor: {{goal}}
Constraints: {{constraints}}
Test coverage today: {{coverage}}

Code:
{{code}}

Produce:
1. Diagnosis: the 3-5 concrete problems in this code (name the specific functions, classes or lines) and how each one blocks the goal. No generic advice.
2. Target shape: a short description or sketch of the structure after the refactor (modules, key function signatures, data flow).
3. Ordered steps: each step must be small enough to ship on its own, leave the behavior unchanged, and be verifiable. For each step give what changes, how to verify it, and the risk level.
4. Safety net: if coverage is weak, the characterization tests to write first, and exactly which behaviors they should pin down.
5. What not to touch: related cleanups that are tempting but out of scope.
6. Stop points: where the work could pause and still leave the code better than before.

If the goal and constraints conflict, say so and offer the two best tradeoffs.
Example output
**Diagnosis** 1. `calculate_total` reads `CURRENT_REGION` global, so it cannot be tested without patching. 2. Tax, discount and shipping rules are interleaved in one 140-line function. 3. `Order` mutates itself inside `calculate_total`, so calling it twice changes the answer. **Target shape:** `PricingContext` (region, date) passed in; pure functions `subtotal`, `discounts`, `tax`, `shipping`; `calculate_total` composes them and returns a new `Totals` value. **Steps** 1. Write characterization tests from 10 real orders (low risk). 2. Add `PricingContext` and pass it through, defaulting to the global (low). 3. Extract `tax` as a pure function; verify the tests (low). 4. Extract `discounts`, then `shipping` (medium, discounts stack in an order-dependent way, so add a test first). 5. Make `calculate_total` return `Totals` and stop mutating `Order` (medium). 6. Remove the global default (low, grep callers). **Do not touch:** the currency formatting helpers. **Stop points:** after step 3 the module is already testable.

Why it works

Ordering the work as shippable steps with verification keeps the plan useful in a real team. Naming what not to touch prevents scope creep.

Licensed CC0 (public domain) Version 1 · history