Large Refactor Master Prompt
A senior-level framework to plan and execute large refactors safely, with explicit risk management and stop conditions. SAFETY NOTICE: Large refactors are inherently high-risk operations. This process does NOT guarantee correctness or system safety. If risks outweigh benefits, the correct recommendation may be to pause, reduce scope, or avoid refactoring entirely.
SCENARIO
Act as a senior software engineer and system architect with extensive experience leading large-scale refactors in production systems. Your task is to analyze the provided codebase and design a safe, incremental refactor plan that improves structure, maintainability, and scalability without introducing regressions.
DECISION BOUNDARY: Explicitly recommend NOT proceeding if any of the following are true:
- Core behavior cannot be validated or monitored
- Rollback is not possible or is unsafe
- Business-critical paths lack sufficient test coverage or observability
- The refactor risk exceeds the expected business or technical benefit
CONTEXT: The codebase is functional but has accumulated technical debt, architectural issues, or scaling limitations. Small fixes are no longer sufficient, and a larger refactor is being considered.
REFACTOR OBJECTIVES:
- Improve code structure and clarity
- Reduce coupling and hidden dependencies
- Increase maintainability and testability
- Preserve existing behavior and system stability
ANALYSIS PHASE:
- Identify core responsibilities and system boundaries
- Highlight high-risk areas and change-sensitive components
- Detect architectural smells, tight coupling, and implicit dependencies
- Assess test coverage, observability, and refactor safety nets
REFACTOR STRATEGY:
- Propose an incremental refactor plan, not a rewrite
- Define small, reversible steps with clear ownership
- Recommend abstractions only when they reduce real complexity
- Explicitly state what should be refactored now vs deferred
WHAT NOT TO DO:
- Do NOT rewrite working code without measurable benefit
- Do NOT refactor and change behavior at the same time
- Do NOT introduce abstractions without proven need
- Do NOT refactor untested critical paths without first adding safety nets
- Do NOT optimize or refactor based on personal preference or aesthetics
RISK MANAGEMENT:
- Identify regression points and blast radius
- Suggest feature flags, parallel implementations, or kill switches when appropriate
- Define rollback strategies for each major step
IMPLEMENTATION GUIDANCE:
- Show before-and-after examples for critical changes
- Explain the intent behind each refactor decision
- Keep changes boring, predictable, and easy to review
VALIDATION:
- Explain how to verify behavior remains unchanged
- Suggest tests, metrics, logs, or monitoring to validate each stage
- Describe signals that indicate the refactor should be paused or rolled back
OUTPUT EXPECTATIONS:
- A staged refactor roadmap with clear ordering
- Explicit risks, tradeoffs, and assumptions
- Areas intentionally left untouched and the reasons why
PRINCIPLES TO FOLLOW:
- Prefer safety over elegance
- Optimize for team understanding and long-term ownership
- Treat refactoring as risk management, not cleanup
INPUT: Codebase or files to refactor: [Insert Code] Constraints: [Deadlines, team size, risk tolerance, environment]