Writing & Editing Patterns

You have a rough draft. It says roughly the right thing, in roughly the right order, at roughly the right length. "Roughly" is the problem — you know what "actually right" looks like when you see it, but getting from rough to right by hand takes twenty minutes you don't have on a Tuesday afternoon with four more drafts in the queue.

This lesson gives you five named patterns for that exact gap. Each one is a specific move, not a vague "make this better" prompt. Each one has a situation it's built for, and — just as importantly — a specific way it breaks when you reach for it in the wrong situation. If you already know why rewriting for tone or reordering an argument works at the mechanism level, that depth lives in Prompt Engineering Mastery. Here, you get the move.

Pattern 1: Voice-Match Rewrite

The pattern: Anchor the rewrite to a real writing sample from the target voice — not a description of the voice, an actual excerpt. "Rewrite this in the voice below" beats "make this sound more confident" every time, because the model has something concrete to imitate instead of an adjective to interpret.

Here is a sample of the target voice:
"[2-3 real sentences from an actual piece the target voice wrote]"

Rewrite the following in that voice. Match sentence length, vocabulary
level, and how directly it states claims. Do not add content that
wasn't in the original:

"[your rough draft]"

When it works: You have at least one real paragraph of writing in the target voice — a past newsletter, a Slack message, an old blog post. The sample does the describing; you don't have to.

When it fails: You don't have a real sample and try to substitute a description ("confident, warm, a little wry"). Adjectives are ambiguous — every writer's idea of "confident" is different — so the output drifts to a generic, competent, forgettable "professional" register that doesn't actually sound like anyone.

Pattern 2: Tighten-to-Length

The pattern: Compress to a target length while explicitly naming the claims that must survive the cut. The failure mode of "make this shorter" is that word count becomes the only optimization target, and the model has no way to know a throwaway sentence from a load-bearing one unless you tell it.

Compress this to under [N] words. These claims must survive intact —
do not cut or soften them:
1. [load-bearing claim 1]
2. [load-bearing claim 2]

Everything else is fair game to cut or condense.

"[your draft]"

When it works: You know which 2-3 claims are the actual point — the blocked dependency, the number that changed, the decision you need approved. Naming them protects them.

When it fails: You skip the naming step and just say "shorter." The compression is claim-blind — it can cut the sentence about the missed deadline exactly as readily as the sentence about team morale, because nothing told it those aren't equally important.

Pattern 3: The Line-Edit Pass

The pattern: A sentence-level critique pass, run only after the structure is settled — not a rewrite, a critique with specific fixes: weak verbs, passive constructions, redundant qualifiers, sentences that could be split or combined.

Line-edit this paragraph for sentence quality only — do not restructure,
do not cut content, do not change the argument. Flag: passive voice,
weak verbs, redundant qualifiers, and sentences over 30 words that
should split. Show the fix inline.

"[your paragraph]"

When it works: The draft's structure and content are already right — you just need the prose itself to read cleaner. This is the last pass, not an early one.

When it fails: Run before a structural question is resolved (wrong paragraph order, unclear whether a section survives). You end up polishing sentences that get deleted in the next pass — wasted effort, and worse, a false sense that the draft is closer to done than it is.

Pattern 4: Audience Downshift/Upshift

The pattern: Rewrite the same content for a different reader sophistication level — downshift from expert to novice (define jargon, add context) or upshift from novice to expert (cut the hand-holding, use precise terminology). The content stays the same; only the reading experience changes.

Rewrite this for a [specific audience: "a VP with no technical background"
or "a senior backend engineer who already knows our stack"]. Keep every
factual claim. [Downshift: define technical terms on first use, add one
sentence of context per unfamiliar concept.] [Upshift: remove
explanations a domain expert wouldn't need, use precise terminology.]

"[your draft]"

When it works: The target audience is specific — a named role, a known expertise level, a described relationship to the content. "A VP who joined the team last quarter and doesn't know our architecture" is specific. "General audience" is not.

When it fails: The audience is vague. A downshift aimed at "general readers" either over-explains to people who don't need it or still assumes background a true novice doesn't have — you can't hit a target you haven't defined.

Pattern 5: Structural Reorg

The pattern: Fix the order of an argument without touching the prose — move the ask above the justification, surface the conclusion that's currently buried in paragraph four, reorder evidence from strongest to weakest. This is an outline-level move, not a sentence-level one.

This document's argument is in the wrong order. The actual ask/conclusion
is currently in paragraph [N] but should lead. Reorder the following into:
1. The ask/conclusion, stated directly
2. The strongest supporting evidence
3. Secondary evidence and context
4. Next steps

Do not rewrite sentences — reorder the existing content and add only
the minimal transitions needed to connect sections.

"[your draft]"

When it works: The content is right but buried — a good argument told in the wrong order, common in status updates and proposals that were written in the order the thinking happened, not the order the reader needs it.

When it fails: The underlying argument is weak or unsupported. Reordering a thin argument just delivers the same thin argument faster — it cannot manufacture evidence or logic that was never written.

The Edit Loop

These five patterns are not interchangeable and they are not meant to run in one prompt together. They run in sequence, one pattern per pass, because each pass assumes the previous one is done. Structural questions get resolved before voice gets matched; voice gets matched before length gets tightened; length gets tightened before the line-edit pass polishes what's left.

Build It: The Edit Prompt Composer

Knowing five patterns by name is useful. Having a function that assembles a validated, structured rewrite prompt from the parts — voice sample, target text, word budget, audience level — is more useful, because it's a pattern you can call instead of one you have to re-derive under deadline pressure.

Bottom Line

Five patterns, one discipline: name what you're protecting before you ask AI to change the text. Voice-Match needs a real sample to anchor to. Tighten-to-Length needs named claims to protect. The Line-Edit Pass needs the structure settled first. Audience Downshift/Upshift needs a specific reader, not a vague one. Structural Reorg needs real content underneath the reordering. Run them in sequence — draft, structure, voice, length, sentences — and a rough draft on Monday becomes something you'd actually send by Friday. Next: research and synthesis — the patterns for turning six competing sources into one trustworthy answer.