Verified against Claude Code · 2026-08-02
Refactor safely and get the diff explained, not just dumped
A refactor prompt that makes preserving external behavior an explicit, checkable constraint and requires the model to justify each change before you review the diff.
The prompt
Ready to copy — highlighted parts are example details you can swap.
You are refactoring, not rewriting. The observable behavior of this code — inputs, outputs, side effects, error conditions, and public signatures — must be identical before and after, unless the preservation constraint below explicitly allows something to change. SCOPE OrderProcessor.calculateTotal in services/order-processor.ts — reduce the nested if and else into something readable, no other goal. MUST PRESERVE The public method signature and its Decimal return type must not change; internal helper functions may be renamed freely. PROCESS 1. Before writing any code, list what you intend to change and why, for example extract X into its own function because it is duplicated in three places. Do not start editing until this list is written. 2. Make the change. 3. Run the existing test suite. If any test needs to change to keep passing, that is a signal you changed behavior, not just structure. Stop and explain rather than editing the test to match. 4. For each hunk in the diff, write one line: what changed structurally, and confirm what stayed behaviorally identical. CONSTRAINTS - Do not change public function signatures, exported names, or return shapes unless the preservation constraint explicitly permits it. - Do not fix unrelated bugs you notice mid-refactor. Note them separately instead. - If achieving the goal in scope is impossible without a behavior change, stop and say so before writing code. Do not make the change silently and mention it only at the end.
Customize the highlighted detailsoptional — the prompt above already works
Why this works
Refactor this is underspecified in a way agentic assistants exploit — without an explicit definition of what must stay the same, a model will change a signature, alter an edge-case return value, or improve error handling while still calling the result a refactor, because nothing told it not to. Naming behavior preservation as a checkable constraint covering inputs, outputs, side effects, error conditions, and signatures gives it a specific target to verify against rather than a vague quality bar. Requiring the change list before the edit, and requiring the existing test suite to pass without modification, converts trust the diff into verify the diff against a stated plan and a green test run — if a test needs to change to keep passing, that is the exact signal a refactor silently became a behavior change, and the prompt makes stopping there the explicit instruction rather than leaving it to the model's judgment. Asking for a one-line structural-versus-behavioral note per hunk also produces a paper trail a reviewer can check line by line, instead of a diff with no stated intent behind it.
What you get back
Change list before editing: extract the nested discount-eligibility checks in calculateTotal into a helper named isEligibleForDiscount, no other change. After running the existing suite: 14 passed, 0 failed, 0 skipped — no test needed modification, which confirms behavior did not change. Per-hunk note: lines 42 to 58 moved into isEligibleForDiscount with no logic change, only extraction; the public calculateTotal signature and its Decimal return type are unchanged.
Verified against
Claude Code Sonnet 4.6 · 2026-08-02
Changelog
- 2026-08-02 — Initial publish, verified against Claude Code (Sonnet 4.6).
Building this for real?
This is a free starting point. If you'd rather have custom software built and running for your business, that's Scult's day job.
EXPLORE CUSTOM SOFTWARE
