What this prompt does
This prompt asks Claude to design a complete AI-assisted refactoring workflow for one specific codebase, not generic advice. You describe the [language], the [code_problems] it suffers from, its [codebase_age], and the [current_patterns] it follows, and the model builds a seven-stage process around that reality — from smell detection through to a documented refactoring report.
The structure works because it front-loads safety. Before any change, it generates characterization tests that capture current behavior, then ranks candidates in an impact-versus-effort matrix using [smell_types] so you fix what carries real bug risk first. Each refactoring becomes a single atomic commit a human reviews, validation prompts check that [quality_metrics] actually improved, and a [vcs_tool] branch strategy lets any phase be reverted independently. That ordering — tests, prioritize, small commits, validate, roll back — is what makes touching fragile code defensible rather than reckless.
When to use it
- You inherited a codebase with
[code_problems]like god classes or duplicated logic and need a safe plan. - You want refactoring tied to bug risk and impact, not cosmetic cleanup.
- You need characterization tests before changing untested legacy behavior.
- You want each change to be a reviewable, revertible commit rather than a big-bang rewrite.
- You need to prove improvement against
[quality_metrics]to a skeptical reviewer or lead. - You want a repeatable workflow your team can run module by module.
Example output
Expect a staged playbook rather than a single block of advice. It opens with a code-smell detection checklist and ready-to-paste analysis prompts you feed each file or module, then produces a ranked refactoring backlog from the prioritization matrix so you know what to tackle first. For each candidate it supplies characterization-test prompts, followed by a sequence of atomic refactoring steps — each scoped to one reviewable commit such as extract method or decompose class. Before/after validation prompts keyed to [quality_metrics] confirm the change actually improved things, a [vcs_tool] rollback strategy lets any phase be reverted independently, and a report template documents what changed, the coverage delta, and the performance benchmarks before and after.
Pro tips
- Be precise in
[code_problems]and[smell_types]; the more concrete the smells, the sharper the detection prompts the model writes. - Treat the characterization-test step as non-negotiable — skipping it removes the only real safety net for untested code.
- Keep
[quality_metrics]measurable (cyclomatic complexity, coupling, coverage) so the validation step has something objective to compare. - Run the backlog one item at a time and re-rank as you learn; the matrix is a starting point, not a fixed plan.
- If your repo uses something other than Git, set
[vcs_tool]accordingly so the rollback steps match your real branching model. - The AI proposes transformations, but the diff review is yours — never merge a refactor commit you have not read.
