Safe Refactor Planner

The Prompt

You are a principal {{language}} engineer planning a safe refactor. I need a low-risk, staged plan that protects production behavior.

Current code:
{{current_code}}

Refactor goal:
{{refactor_goal}}

Constraints:
{{constraints}}

Performance budget:
{{performance_budget}}

Return exactly:
1) Current architecture assessment (coupling, complexity, hotspots)
2) Refactor strategy (phases with entry/exit criteria per phase)
3) Risk map (top risks, blast radius, mitigation)
4) Guardrail tests to add before changes
5) Step-by-step implementation checklist
6) Rollback strategy for each phase
7) Performance validation plan against budget
8) Definition of done

Constraints:
- Preserve external behavior unless explicitly noted.
- Prefer small, reversible commits over large rewrites.
- Call out dependencies that must be upgraded first.
- Explicitly separate "must do now" vs "defer later."

When to Use

Use this when code quality needs improvement but stability is non-negotiable. It is ideal for legacy modules, high-traffic services, and areas where quick rewrites could create regressions.

Common scenarios:

• Breaking apart a large, multi-responsibility file
• Replacing brittle abstractions with clearer boundaries
• Preparing code for new features without adding more debt
• Improving testability before expanding functionality

This prompt emphasizes planning discipline. Instead of generating immediate rewritten code, it gives you a phased roadmap with explicit safety checks and rollback paths.

Variables

Variable	Description	Good input examples
language	Main implementation language	TypeScript, Java, C#, Go
current_code	Existing code or representative slice	Current class/module, plus key dependencies
refactor_goal	Desired improvement outcome	”Split service into domain + infrastructure layers”
constraints	Non-negotiables and limits	”No API contract changes, 2-week window, no DB migration”
performance_budget	Latency/throughput/error constraints	”p95 <= 180ms, memory +5% max”

Tips & Variations

• Add “team skill constraints” when juniors will implement most changes.
• Request “ADR-style summary” if you want architecture decision records from the plan.
• For very risky modules, ask for “parallel run strategy” before cutover.
• If deadlines are tight, ask for a two-track plan: minimal safe refactor now, deeper refactor later.
• Pair this with the test-generation prompt to produce guardrail tests for each phase.

Refactors fail when scope expands mid-flight. Keep this prompt anchored to concrete goals and explicit out-of-scope items.

Example Output

Phase 1: Add characterization tests around pricing rules and invoice formatting.

Top risk: Hidden side effects in shared utility used by billing and reporting.

Mitigation: Introduce adapter layer, dual-run old/new path behind a feature flag.

Rollback: Toggle flag off, revert only phase-2 commits, preserve phase-1 tests.