How to Write a Prompt Brief That Makes AI Writers Stop Sounding Generic (2026 Guide)

Key takeaways

• Generic output is mostly a brief problem. "Write a blog post about X" gives the model nothing to push against, so it falls back on its default enthusiastic-assistant voice.
• A good brief has six parts: role, audience, goal, voice samples, constraints with reasons, and output format.
• Real writing samples beat style adjectives. Anthropic calls examples "one of the most reliable ways to steer" tone and structure.
• Banned-word lists help a little, but they go stale. Name structural crutches (summary paragraphs, dramatic adjectives) as well as vocabulary.
• Keep the brief in a reusable file, test it on someone with no context, then edit the draft by hand.

Why AI writing sounds generic in the first place

A language model asked to write something with no context produces the most statistically average version of it. That's the whole mechanism. No audience, no opinion, no stakes, so you get the safe middle: an upbeat opener, three tidy points, a summary paragraph that restates everything.

I see people respond to this by adding adjectives. "Make it engaging." "Make it professional but friendly." That doesn't work, because "engaging" is exactly what the model already thinks it's being. The fix is information, not adjectives. The model needs to know who is reading, what they already believe, what you sound like, and what you refuse to write.

Anthropic's prompting guidance puts it well: treat the model as "a brilliant but new employee who lacks context on your norms and workflows." A new employee handed one line of instructions would also hand you something bland. A prompt brief is just the onboarding document you'd give that person.

George Kao's April 2026 piece on avoiding AI-isms describes a workflow many writers share: draft with AI, go back and forth to refine ideas, then edit the result to sound like yourself. The brief is the first step of that, and a better one makes the last step much shorter.

The six parts of a brief that works

Here's the structure I'd use. It borrows from the "contract" style of system prompt that practitioners like (role, goal, constraints, what to do when unsure, output format) and adds the two pieces that matter most for voice: audience and samples.

Role

Setting a role in the system prompt, even in one sentence, changes behavior and tone. Anthropic says so directly. But the role should carry a point of view. "Expert writer" does nothing. "Editor who hates filler and writes like she talks" gives the model a personality to imitate.

Audience

This is the most skipped part and probably the most valuable. A Quora answer that circulates in prompt-engineering circles makes the point with an example: asking for an email to "a skeptical coffee distributor" explaining why light roasts are a better investment for young consumers, in a "persuasive but dry, data-heavy tone." The specific reader forces specific claims. A vague reader allows vague platitudes.

Write the audience as a person. What do they know? What do they doubt? What would make them close the tab?

Goal

One sentence on what the piece must accomplish. If you can't write it, the draft won't have a point either. Models are very good at producing text that looks like it has a thesis.

Voice samples

Covered in detail below, because it's where most of the gain comes from.

Constraints, with reasons

Anthropic's guidance includes a small trick worth stealing. Give the reason behind a rule, because the model generalizes from the explanation. Their example:

• Weak: "NEVER use ellipses."
• Better: "Your response will be read aloud by a text-to-speech engine, so never use ellipses."

The second version also teaches the model to avoid other things that read badly aloud. Apply that to writing style. Instead of "don't use bullet points," try "this is a personal essay for a newsletter, and bullets make it feel like a slide deck."

Output format

Length, heading structure, paragraph size, whether to include a conclusion. One practitioner keeps a hard limit of three sentences per paragraph in a persistent writing-rules file. That sort of concrete limit is easier for a model to follow than "keep paragraphs short."

Voice samples do the heavy lifting

Masset's widely shared "sound less like AI" prompt has 14 principles: active voice, parallel structure, concision, familiar words, avoiding overstatement, and so on. It's a reasonable style guide. It's also generic, which is its main limit as a brief. It describes good writing in general and says nothing about how you write. Masset itself notes that "the more your AI knows how you actually write, the less it sounds like AI."

So paste in your own writing. Two or three paragraphs, ideally from different pieces. Anthropic's guidance on examples is useful here. Good examples are:

• Relevant: they mirror the real use case. A newsletter intro is a bad sample for a technical tutorial.
• Diverse: they vary enough that the model doesn't pick up unintended patterns. If all three samples open with a question, you'll get a question opener every time.
• Structured: wrapped in tags so the model can tell sample from instruction.

A skeleton looks like this:

<role>
You are a senior editor for a B2B software publication. You write plainly,
prefer concrete examples to abstractions, and distrust hype.
</role>

<audience>
Heads of content at 20-200 person SaaS companies. They've tried AI writers
and been disappointed. They skim, and they notice filler.
</audience>

<goal>
Get the reader to audit their prompt brief before blaming the model.
</goal>

<voice_samples>
<example>
[Paste a real paragraph of yours here]
</example>
<example>
[Paste a different one, ideally in a different register]
</example>
</voice_samples>

<constraints>
- First person is fine. No invented statistics or quotes.
- No summary paragraph at the end, because the closing line should be a concrete next step.
- Max 3 sentences per paragraph, since readers will mostly be on mobile.
- If a claim needs a source you don't have, flag it. Don't guess.
</constraints>

<format>
900 words. H2 headings only. One short list at most.
</format>

<topic>
...
</topic>

One honest caveat on the tags. Some people claim XML is Claude's "native language," and one practitioner who uses tags admits they can't verify that. The defensible reason is simpler: tags remove ambiguity between instructions, context and examples. Keep tag names consistent and you're fine. Anthropic recommends them for the same reason.

Also, if you're pasting a long source document (20k+ tokens), Anthropic suggests putting it at the top of the prompt, above the instructions and the request.

Name the crutches, not just the words

Every model has favorite moves. The Quora answer above says to name them: "Avoid exclamation points, dramatic adjectives, and summary paragraphs at the end." That's good advice because it targets structure, which is where generic writing actually lives.

Structural crutches worth banning by name:

• Opening with a sweeping claim about how important the topic is
• Closing with a paragraph that restates the piece
• Sentences built as "not just X, but Y"
• Triplets of adjectives or examples, every time
• Em dashes used as punctuation confetti
• Headings that are all title case and all the same grammatical shape

What about banned-word lists?

They help, with a catch. Pangram publishes a large list of words AI overuses relative to human text, and Juzek and Ward's study found 21 focal words whose use in scientific abstracts rose, probably because of LLMs. One secondary summary of that research puts "delve" at roughly +1500% versus 2022 across six scholarly databases, with "underscore" near +1000% and "intricate" near +700%.

But the same summary says that once "delve" became a meme, its use started declining around April 2024, while less conspicuous words kept growing. So a banned list goes stale. It also says words like "tapestry," "realm" and "landscape" are mostly community heuristics, with weaker corpus-level evidence than "delve." Treat your list as a living file, and pair it with the structural bans above. I found no hard numbers on how much a banned list improves quality, so don't expect miracles from it.

Give the model permission to say "I don't know"

The contract-style prompt I mentioned includes a line most briefs lack: "If unsure, ask one clarifying question, don't guess." That matters for voice too. When a model lacks a fact, it fills the gap with smooth, plausible, generic language. Letting it flag gaps gives you a visible hole to fill with something specific from you: a number, an anecdote, an opinion.

A few constraint lines that pay off:

• "No invented statistics, quotes or customer stories. Mark a placeholder instead."
• "If you don't have a concrete example, write [EXAMPLE NEEDED]."
• "Take a position. If the evidence is mixed, say which way you lean and why."

Test the brief before you run it

Anthropic offers a "key test": show your prompt to a colleague with minimal context and ask them to follow it. If they'd be confused, the model will be too. It's a pre-flight check, and it takes five minutes.

When I do this, the failure is almost always the same. The brief assumes knowledge in my head. "Our usual tone" means nothing to a stranger. "The enterprise segment" means nothing either. Fix those and the draft improves before you've generated a word.

Also note that a technique measured on one model should be re-checked against your own tests before you apply it to another. Newer models ship with their own prompting pages, some covering response length, verbosity and writing density, which bear directly on padding. Re-read them when you switch.

Keep the brief in a file, not in your head

Retyping instructions each time guarantees drift. One practitioner keeps a persistent writing-rules file covering tone, audience, never-use words, and standing requirements like "always: specific numbers, source links, one action item." Paste it in, or load it as a project instruction or system prompt.

A tidy setup looks like this:

1. A standing brand-voice file with samples, banned crutches and format rules.
2. A short per-piece brief with topic, audience, goal and source material.
3. A changelog line each time you add a rule after spotting a new tell.

That third step is the one people skip. Every time you edit a draft and delete the same phrase, that phrase belongs in the file.

Which tools to use for what

The brief matters more than the model, but tooling helps with the surrounding workflow.

For drafting, Claude is the one I'd reach for with long, structured briefs, since Anthropic's own documentation is where much of the tag-and-example guidance comes from.

ChatGPT works equally well with the same brief. The structure transfers, though per Anthropic's own advice you should re-test on your own examples when you switch models.

If you're running the same brief across a team, prompt libraries keep everyone on the current version.

For checking whether a brief change actually helped, an open-source evaluation framework lets you run variations side by side instead of trusting your gut.

For enterprise teams that need voice rules enforced across many writers and drafts, Writer is built around that problem.

After the draft, a readability editor is a cheap last pass for long sentences and adverbs.

A note if the content is meant to be cited by AI

If you're writing for AI search visibility, generic copy has an extra cost: it gives a model nothing distinctive to quote. Specific numbers, named sources and clear positions are more citable than smooth filler. Tools like Promptwatch can show which of your pages get cited and which prompts you're missing content for, which helps you decide what the next brief should cover.

Edit after the draft anyway

No brief removes the editing pass. The Quora thread this guide draws on makes a blunt point: if you hand the model your text and let it rewrite freely, it stops being your writing. Use the model for structure and first drafts, then put your own hands on the result.

A short editing checklist:

• Cut the first sentence. It's usually throat-clearing.
• Cut the last paragraph if it restates the piece.
• Replace every abstract claim with one concrete detail.
• Read it aloud. Anything you wouldn't say to a colleague gets rewritten.
• Look for rhythm. If every sentence is the same length, break two of them.
• Add one thing only you know: a mistake you made, a number from your own data, a disagreement you have with the common advice.

That last item is the real fix for "generic." A model can't invent your lived experience. The best brief leaves deliberate gaps for it.

A quick-start version

If you only do five things after reading this:

1. Describe the reader as a specific person, with a doubt.
2. Paste two or three real samples of your writing.
3. Ban structural crutches by name, and give a reason for each rule.
4. Tell the model to flag missing facts instead of inventing them.
5. Show the brief to a colleague before you run it.

Run it once, edit the draft, and add whichever phrase you deleted most often to the never-use list. Do that for a month and your brief will say more about your voice than any style adjective could.