What this prompt does
This prompt casts the AI as a senior engineer doing a behaviour-preserving refactor, and it returns a single applyable diff plus a semantic-risk note, not a rewrite from scratch. You supply the refactor [goals], the [language], a [interface_rule] for how to treat public interfaces, and the [code] itself. It applies the stated goals only, changes no observable behaviour or side-effect ordering, stops and asks before altering any public interface per your rule, keeps the change minimal and surgical without reformatting untouched lines, preserves or adds the smallest test proving identical input and output, and ends with a list of subtle semantic concerns.
The structure works because it separates intent from style: by emitting a diff plus a concerns list, you review what might change semantically rather than wading through a full rewrite where every line looks new. [goals] scopes exactly what the refactor touches, so it doesn't sprawl into reformatting or speculative abstractions. [interface_rule] is the safety valve; setting it to ask before changing exported signatures stops the model from silently breaking callers downstream. The CONCERNS list at the end surfaces timing, exception, and null-handling risks that a clean-looking diff can hide, which are precisely the changes that slip past a casual review and surface in production.
When to use it
- You want a refactor that provably preserves behaviour, not a rewrite.
- You need a diff you can review, not a wall of regenerated code.
- You are nervous a refactor might change a return shape or exception path.
- You want public interfaces protected unless you approve the change.
- You want subtle semantic risks called out explicitly.
- You are cleaning up inherited code and need surgical, reviewable changes.
Example output
You get one unified diff in a fenced block applying only your stated goals, followed by a short bulleted CONCERNS list naming any subtle semantic risks the diff could affect, such as timing, exceptions, or null handling. The model also preserves or adds the smallest test proving identical input and output before and after. If a goal would change a public interface, the model pauses and asks rather than proceeding. The diff is meant to apply cleanly and stay minimal, leaving untouched lines and formatting alone so the review stays focused on intent.
Pro tips
- Scope
[goals]tightly so the refactor stays focused and the diff stays small. - Set
[interface_rule]to ask before changing exported signatures to protect callers. - Lock down a characterization test first; it catches behaviour changes a clean diff hides.
- Read the CONCERNS list carefully; that is where hidden semantic risk surfaces.
- Paste complete
[code]with its imports so the diff applies without missing context. - Apply the diff and run the test before trusting that behaviour is truly preserved.
