-0260.png&w=3840&q=75)
Most prompt guides focus on generation - give the model a blank slate, get a first draft back. That's useful maybe 20% of the time. The other 80%? You already have something. You just need it fixed.
Key Takeaways
- Diff-style prompting tells the model what to keep, cut, rewrite, and restructure - no full regeneration needed
- It works across writing, code, and structured documents like specs or reports
- A reusable scaffold with four explicit zones (KEEP / CUT / REWRITE / STRUCTURE) eliminates vague edit requests
- The biggest failure mode is under-specifying constraints, which lets the model over-edit
- Editing loops are more efficient than generation loops for anything beyond a first draft
Why Editing Prompts Beat Generation Prompts
Once you have a draft, regenerating it from scratch is almost always a mistake. You lose the sentence that was already perfect. The model forgets the tone you spent three iterations establishing. The structure shifts in ways you didn't ask for.
Editing prompts treat the existing output as a constraint, not a starting point. You're telling the model: "Here is the artifact. Here is what is wrong with it. Change only those things." That's a fundamentally different instruction than "write me a thing."
The mental model I use is a code diff. In version control, a diff doesn't rewrite the whole file - it marks specific lines as removed (-) and added (+), leaving everything else untouched. Diff-style prompting applies the same logic to prose, code, and structured documents.
The Four-Zone Editing Scaffold
The core of this technique is breaking your edit instruction into four explicit zones. Every editing prompt you write should answer all four.
KEEP: [what must not change - tone, structure, specific phrases, logic]
CUT: [what to remove - redundant sections, filler, incorrect content]
REWRITE: [what to change and how - specific paragraphs, functions, tone shifts]
STRUCTURE: [layout constraints - heading order, section length, format rules]
Here's why each zone matters. Without KEEP, the model treats everything as fair game and will "improve" things you were happy with. Without CUT, it tends to compress rather than delete, leaving ghost versions of the content you wanted gone. Without explicit REWRITE targets, edits are applied inconsistently. And without STRUCTURE, the model will reorganize your document if it decides a different layout makes more sense - which it often does, whether you wanted that or not.
Applied to Writing: Before and After
Take a product update email that's too formal and too long. The instinct is to paste it back in with "make this shorter and friendlier." That instruction is a trap. The model will rewrite everything, including the specific technical details you need to keep accurate.
Before (vague edit request):
Rewrite this email to be shorter and friendlier.
[paste of 400-word email]
After (diff-style):
KEEP: All technical details in paragraphs 2 and 3. The sign-off. The subject line.
CUT: The opening paragraph - it's context the reader already has.
REWRITE: Paragraph 1 (new opening) - match the tone of a Slack message from a trusted teammate.
Paragraph 4 - condense to 2 sentences maximum.
STRUCTURE: Keep as single-column prose. No bullet points. No headers.
[paste of 400-word email]
The output from the second prompt is predictable. The model knows its constraints. You're not gambling on what it decides to "improve."
Applied to Code: Surgical Refactoring
Diff-style prompting is, if anything, even more powerful for code. Developers are already familiar with the diff metaphor, and the failure modes of vague code prompts are immediately visible - broken tests, changed function signatures, renamed variables that break imports.
Before (vague):
Clean up this function and make it more readable.
[paste of 60-line Python function]
After (diff-style):
KEEP: Function signature, return type, all business logic, existing variable names.
CUT: The inline comments - they restate what the code does, not why.
REWRITE: The error handling block (lines 34-45) - replace bare `except` with specific
exception types and add a log statement before re-raising.
STRUCTURE: Keep as a single function. Do not extract helper functions.
[paste of 60-line Python function]
That second prompt won't accidentally rename your variables or split your function into three pieces because it "looked cleaner." The constraint is explicit. [1]
Applied to Structured Documents
Specs, reports, and PRDs are where editing prompts get really interesting, because these documents have rigid structural conventions that a model will cheerfully violate if you don't anchor them.
Say you're editing a technical spec. One section has scope creep and needs cutting. Another section uses passive voice throughout. The rest is fine.
KEEP: All sections except "Proposed Architecture" and "Timeline".
The numbered requirement IDs in section 3 - do not renumber.
CUT: The "Proposed Architecture" section in full.
REWRITE: "Success Metrics" section - convert passive voice to active.
No other changes to this section.
STRUCTURE: Preserve existing heading hierarchy (H1 → H2 → H3).
Keep the document under 1200 words total.
[paste of spec]
The model now has a clear map of what is and isn't in scope. It won't touch the timeline section to "make it more consistent" with the architecture section you just deleted.
Common Failure Modes
Even with this scaffold, there are patterns that will undermine your editing prompts.
The first is constraint inflation - adding so many KEEP rules that the model can't actually make the changes you asked for. If you tell it to keep every sentence and also rewrite the tone, something has to give. Be selective about what you lock down.
The second is ambiguous targets. "Rewrite the introduction" is underspecified. Which introduction? What should it accomplish? What's wrong with the current one? The more precisely you describe the problem, the more precisely the model can fix it.
The third is forgetting to anchor format. Models have strong opinions about formatting. If your document is prose and the model thinks bullet points would be cleaner, it will often make that change even if you didn't ask. Always include a STRUCTURE zone, even if it's just "preserve existing format exactly." [2]
The fourth is mixing generation and editing in one prompt. If you ask the model to edit existing content and also add a new section, you're running two different instruction types at once. Split them. Edit first, generate the new section second, then combine.
The Reusable Scaffold as a System Prompt
The scaffold above works best when you turn it into a template you can invoke instantly. Here's a version you can drop into a system prompt or a text expander:
You are an editor, not a writer. Your job is to apply only the changes I specify.
KEEP: [list what must not change]
CUT: [list what to remove entirely]
REWRITE: [list what to change and describe the target state]
STRUCTURE: [describe layout constraints]
Apply these changes to the text below. Do not make any other modifications.
If you are uncertain whether a change falls within scope, default to leaving it unchanged.
[PASTE TEXT HERE]
That last instruction - "default to leaving it unchanged" - is doing a lot of work. It shifts the model's default behavior from "improve everything" to "change only what's specified." That's the whole game.
If you find yourself running editing loops frequently across different tools - Figma, a browser, an IDE - Rephrase can trigger a pre-loaded editing scaffold on any selected text with a global hotkey, so you're not re-pasting the template every time you switch context.
Putting It Together
The diff-style pattern isn't complicated. Four zones, explicit constraints, a default of "leave it unchanged." What makes it powerful is that it treats your existing work as something worth preserving rather than something to regenerate.
First drafts are for generation prompts. Everything after that is an editing problem - and editing problems deserve editing prompts.
For more techniques on structuring prompts for specific output types, the Rephrase blog covers practical patterns across writing, code, and structured documents.
References
Community Examples
-0258.png&w=3840&q=75)
-0259.png&w=3840&q=75)
-0256.png&w=3840&q=75)
-0255.png&w=3840&q=75)