Engineering

Legacy Code Review Prompt

Mentoring-style maintainability review: what makes the next change expensive, explained with corrected examples — teach, don't just judge.

Open in Code Review Prompt Generator

Overview

Legacy code review has a different goal: not gatekeeping a merge, but building a map for gradual cleanup — and teaching the developer doing it. This setup runs the maintainability focus (duplication that drifts, intent-hiding names, cohesion, coupling, dead code, test coverage of what changes) under Mentoring style: every finding explains WHY it matters, CRITICAL and MAJOR findings come with short corrected examples, and the review ends with the three most important things to learn — not a verdict to fear.

How to use this resource

Review before you change anything

The maintainability map tells you where changes will be expensive — before you're mid-change and finding out.
Use the corrected examples as patterns

Mentoring style shows the fix shape for major findings — apply the pattern, not just the instance.
Hand the top-three learnings to the team

The closing learnings generalize beyond this module — that's the compounding value.

Why This Works

Maintainability focus prices the NEXT change — the metric legacy code actually fails on
Mentoring style converts findings into transferable knowledge
A map-not-gate framing makes the review usable on code that would fail any gate

Best for

Modules everyone fears and nobody owns
Onboarding developers into old codebases
Cleanup work that needs a defensible priority order

Not for

Actually performing the refactor — that's the Refactor Prompt Builder, with behavior-preserving constraints
Blocking a release — mentoring style deliberately doesn't gate

Use cases

Mapping a legacy module before touching it
Teaching newer developers what good looks like, in context
Prioritizing cleanup by what makes changes expensive

FAQ

Does this legacy review prompt refactor the old code for me?

It reviews only. The REVIEW OBJECTIVE states "Review only — report findings; do not rewrite the code," so the generated prompt asks your assistant for maintainability findings and, for CRITICAL or MAJOR items, a short corrected example to learn from — not an applied refactor. You still run the prompt and act on the findings yourself.

Why does the legacy review prompt end with learnings instead of a pass or fail verdict?

By design the FINAL VERDICT asks for "the three most important things to learn from this review" rather than a gate. The Mentoring framing treats old code as a cleanup map, so it deliberately doesn't block a merge — every finding explains why it matters instead of issuing a verdict to fear.

How do the severity tags decide what to fix first in a legacy module?

Every finding gets exactly one of [CRITICAL], [MAJOR], [MINOR], or [NIT], and the SEVERITY RULES state severity reflects impact, not effort to fix. Findings group by severity with CRITICAL first, giving a defensible priority order — but the tags are the model's judgment in the prompt output, which you confirm against the actual code.

Customize This Resource

Opens this setup in Code Review Prompt Generator. Generate to get the full review contract — then adjust the focus, scope, language, and style.

Open in Code Review Prompt Generator

Prompt Template

Copy it as-is, or use Open in Code Review Prompt Generator to load it pre-filled and customize it with your own context.

REVIEW OBJECTIVE
Review this legacy module to guide its gradual cleanup — teach, don't just judge.
Primary focus: maintainability — find what makes the next change to this code expensive.
Review only — report findings; do not rewrite the code.

REVIEW SCOPE
You are reviewing a complete file — judge both the code and the file's structure: imports, ordering, and what this file owns.

REVIEW CRITERIA
- Duplication that will drift apart
- Naming that hides intent
- Cohesion: modules and functions doing one job
- Coupling: reaching into other modules' internals
- Test coverage of the logic that changes

SEVERITY RULES
- Tag every finding with exactly one severity: [CRITICAL], [MAJOR], [MINOR], or [NIT].
- CRITICAL: must be fixed before merge — bugs, vulnerabilities, data loss.
- MAJOR: should be fixed — real risk or real debt.
- MINOR: worth fixing — small risk or friction.
- NIT: style preference; fixing is optional.
- Severity reflects impact, not effort to fix.

REVIEW CHECKLIST
Work through every item; report only the items that fail:
1. Is there duplicated logic that will drift apart when one copy changes?
2. Do names reveal intent — could a newcomer guess what each thing does?
3. Does each function/class do one job (cohesion)?
4. Does the code reach into other modules' internals (coupling)?
5. Any magic numbers or strings that should be named constants?
6. Is there dead code that should be deleted, not kept "just in case"?
7. Do comments explain WHY, not narrate WHAT?
8. Is the changed logic covered by tests that would catch a regression?
9. Is the dependency direction sensible — stable things not depending on volatile ones?
10. Is the public surface minimal — nothing exposed that callers shouldn't touch?

REQUIRED OUTPUT FORMAT
- One finding per bullet: [SEVERITY] location — what is wrong and why it matters.
- Group findings by severity, CRITICAL first.
- Cite the exact line, function, or symbol for every finding.
- Do not mention checklist items that pass — findings only.
- Explain WHY each finding matters, not just what to change.
- For each CRITICAL or MAJOR finding, include a short corrected example.
- Frame findings as learning points for a developer growing into this codebase.

FINAL VERDICT
- End with the three most important things to learn from this review.
- Base the verdict only on the findings listed above.

CODE TO REVIEW
[Paste the file here]

More resources from Code Review Prompt Generator

Resource

Code Review Prompt — the Review Contract

"Review this code" gets shallow comments. The review contract gets findings with severities, a checklist, and a verdict.

Prompt Engineering

Resource

Security Code Review Prompt

Twelve security checks — injection, auth, secrets, SSRF, privilege escalation — reviewed the way an attacker would read the code.

Engineering

Resource

API Review Checklist Prompt

Architecture review for the public surface: abstractions that earn their place, dependency direction, seams, and the patterns the codebase already has.

Engineering

Resources that pair well

Resource

Refactor Prompt — the Behavior Preservation Contract

"Refactor this code" invites silent behavior changes. The refactoring contract preserves business rules, outputs, and side effects — and flags uncertainty instead of deciding it.

Prompt Engineering

Resource

Playwright Test Prompt

getByRole over CSS chains, auto-wait over sleep, web-first assertions — Playwright tests written the way Playwright wants.

Engineering

Resource

Compare Two ChatGPT Prompts

A side-by-side way to decide between two ChatGPT prompt drafts — scored on clarity, specificity, output control, and risk instead of gut feeling.

Prompt Engineering

Related tools

Tool

Code Review Prompt Generator

Generate code review prompts for any scope — snippet, file, diff, or full pull request — with focused review rules.

Coding Workflows

Workflows that use this resource

Workflow

AI Legacy Code Modernization Workflow

Update old, risky code you didn't write — safely — by understanding and pinning its behavior in tests before you change a single line.

4 steps 45–90 minutes

Tip: Save time by exploring related resources and tools that integrate with this resource.