What makes a good AI prompt brief

Why a topic sentence is not a brief

"Write something about our new pricing" names a topic. It does not name a deliverable, a reader, a length, or a way to tell whether the result succeeded. Handed to a language model, that sentence produces a genre-appropriate essay rather than a usable artifact, because a topic gives the model nothing to specify against except its own training-data average for "pricing announcement."

A brief converts the topic into a specification. "Write a 200-word email to existing customers, in plain language, explaining that the Starter plan rises from $29 to $34 on November 1, why the change is happening, and what to do if they want to lock in the old price before then" is not longer for its own sake — every added clause removes one decision the model would otherwise make at random, including the price, the audience, the reason, and the deadline.

The distinction matters because people often blame the model for a brief's gaps. A vague result from a vague request is not a hallucination or a failure of the tool; it is the correct output for the input that was actually given.

The six fields a working brief always has

Regardless of the task, six fields carry almost all the value in a brief. Each answers a question the model would otherwise decide by averaging its training data.

Anthropic's published prompt engineering documentation, updated through 2025, describes a similar structure under the name IDEAL — instruction, data, examples, additional context, and leave room for reasoning — while OpenAI's own prompting guidance, also revised in 2025, converges on the same underlying logic under different labels: be specific, provide reference text, split complex tasks into simpler subtasks, and give the model time to think. Google's Gemini documentation and Microsoft's Copilot guidance both publish comparable checklists. Four vendors converging independently on the same six or so elements is itself evidence that the elements are properties of good specification rather than an artifact of any one company's house style.

The convergence has a practical use: a brief written against this list transfers across tools with almost no rewriting, because the six fields describe the task rather than a vendor's syntax. Provider-specific settings — temperature, system-versus-user message separation, function-calling schemas — sit on top of the brief and can change without touching it.

Start with the deliverable, then work backward

Writing the deliverable line first forces early clarity that a topic-first approach postpones until the draft is already wrong. A useful test: state what a person will do with the finished artifact within 48 hours. "Send it to 400 subscribers on Thursday" or "read it aloud on a 90-second video" both carry a format and a length inside them. "Have it on the website" carries neither, and a brief built on that answer will need a second pass no matter how well the rest is written.

If the deliverable cannot be named in one sentence, the problem usually sits upstream of any prompt. A request such as "help with our marketing" has not yet decided what is being produced, and no amount of prompt craft substitutes for that decision. Push the person requesting the work to name the artifact before drafting the brief; it is a five-minute conversation that prevents a much longer one after a wasted draft.

The pattern is easy to observe without a formal study: ask a colleague to draft "something about the outage" and watch how many clarifying questions come back before any writing starts, compared with asking for "a 150-word incident summary for the status page." The deliverable line is doing that clarifying work up front, before a single word of the actual content gets written, and a model has no way to ask the follow-up question a colleague would.

Name the reader as a specific person, not a segment

"General audience" and "our customers" both function as instructions to write for the statistical average of the model's training data, which for business prose tends toward a mildly promotional, mid-level, generic register — the exact voice most complaints about "AI writing" are describing. Naming a specific reader is how a brief escapes that default.

A working reader line covers who they are, what they already know, and what they are trying to decide. "A restaurant owner who runs one location, has never used inventory software, and is deciding this month whether a monthly food-waste cost of roughly $600 justifies switching from a paper order sheet" tells the model to skip jargon, to address the cost of switching in the same terms the reader already thinks in, and to end somewhere a decision gets made — three things "our customers" cannot specify.

Where a brief must serve more than one reader, name each one and either produce two artifacts or explicitly instruct the model to write for the less experienced reader and let the more experienced one skim. Writing for an unstated blend of two readers produces prose that serves neither.

The Plain Writing Act of 2010 requires US federal agencies to write public-facing documents in plain language, and the government's own plainlanguage.gov guidance built from that law recommends identifying a specific reader before drafting begins — the same first move this section describes, arrived at independently by a federal mandate rather than by AI-prompting research. The overlap suggests the underlying skill predates language models by well over a decade; what has changed is how quickly a missing audience definition shows up as a defect in the output.

Source material belongs in the brief, not in a reference to it

A brief that says "using our pricing sheet" without attaching or pasting the sheet is not supplying source material — it is naming a document the model cannot open. Ask for a three-tier comparison table and an unattached brief will return one, complete with plausible numbers like $29, $79 and $199 a month, none of which trace to anything you actually charge. The table looks like the finished product and is entirely fictional.

Three delivery routes actually work: paste the relevant passage straight into the brief, attach the document and check the model registered it by having it repeat back the opening line, or wire in a retrieval tool that pulls the passage in at request time. Whichever route you take, pair it with an explicit rule for gaps: "where the attached material has no matching figure, write UNKNOWN instead of estimating." That single clause prevents more invented numbers than any instruction to "be accurate" ever will, because it hands the model a legitimate way to report absence rather than a genre expectation to fill.

Format is a contract, not a suggestion

"Make it engaging" cannot be checked by a reader in under a minute. "Five sections, none under 100 words or over 200, each closing with one specific next step" can. The difference is whether the format line describes a mood or specifies a shape, and only the second kind survives contact with an actual draft.

For machine-readable output, the format field should name exact fields and types — "JSON with keys model (string), year (integer), price_usd (number or null)" — and state what happens when a value is unknown, because asking for JSON does not guarantee the result parses. Validate structured output with software rather than a read-through; a single trailing comma passes a human eye and fails a parser every time.

For prose, put the length and structure requirement early in the brief rather than as an afterthought at the end, since models weight instructions near the beginning and end of a long prompt more reliably than instructions buried in the middle — a pattern documented by Liu and colleagues in "Lost in the Middle" (Transactions of the ACL, 2024, arXiv:2307.03172).

Limits are enforceable only when they are observable

A limit works when a reader can hold the draft against it and answer yes or no in a glance. "No exclamation marks, no rhetorical questions, no claim that we are the leading provider, no invented statistics" is enforceable. "Keep it professional" is not, because two people will disagree about what counts as unprofessional and the model has no external reference to check against either.

Keep the limits list to four or six items. Beyond that, items in the middle of the list start to slip — the same positional effect that governs long contexts generally, documented by Liu and colleagues across multiple model families including GPT-3.5 and earlier Claude models in their 2024 Transactions of the ACL paper. Put the two limits that matter most last, immediately before the instruction to begin drafting, since recency within the prompt improves adherence.

The pass/fail test is the field almost everyone skips

A test converts "does this look right" into "does this meet the stated bar," and it does double duty: it tells the model what to optimise for while it drafts, and it gives the reviewer a checklist rather than a vague impression. A useful test names an observable outcome: "a new employee can complete step 3 without asking a question," "every number traces to the attached report," "word count falls between 850 and 950."

Tests also expose disagreement early. If the person requesting the work and the person reviewing it cannot agree on the test, they were never going to agree on the finished draft either, and finding that out before the model starts is far cheaper than finding it out after.

A useful habit borrowed from software development: write the test in a form that a person other than the original requester could apply without asking a follow-up question, the same standard the IEEE 830 software requirements specification standard sets for acceptance criteria in engineering contexts. "Every number traces to page 3 or page 7 of the attached report" meets that bar. "Feels aligned with our brand" does not, no matter how confidently it is stated.

A brief template you can reuse

The following structure covers the six fields in a form that takes about two minutes to fill in for a routine task:

Save filled-in versions of this template for the two or three tasks your team repeats most often, and keep them in a shared file rather than rebuilding them each time. The A-Z AI Prompt Encyclopedia follows the same logic across all 120 of its chapters, listing the exact inputs each kind of work needs before the 30 prompt cards for that chapter begin.

A brief before and after, on a real request

The weak version of a common request:

The same request with all six fields present:

The second version takes roughly ninety extra seconds to write and removes the two most common failure modes for this exact request — generic enthusiasm and unverifiable superlatives — before the model produces a single word.

Common brief mistakes that look like good practice

Padding a brief with adjectives feels thorough and adds nothing. "Write a detailed, comprehensive, in-depth, specific analysis" stacks four intensifiers and supplies zero facts; the Princeton GEO study's finding that keyword stuffing produced no measurable benefit in AI visibility (ACM SIGKDD 2024) applies with equal force here — volume of enthusiastic language is not the same as volume of information.

Another common mistake is writing the brief as a narrative rather than a specification. A paragraph explaining company history and market context before stating the deliverable buries the instruction where it is least likely to be honoured, per the positional effects noted above. Lead with the deliverable and the reader; move background to a labelled "context" field the model can skip if it is not load-bearing.

A third mistake is confusing tone words with limits. "Make it punchy" and "make it sound like us" are aspirations, not constraints — neither can be checked against the finished draft. Replace tone words with the specific patterns that make a voice recognisable: average sentence length (a target such as "under 20 words" is checkable in any word processor's readability statistics, most of which implement the 1975 Flesch-Kincaid formula), whether questions are used rhetorically, whether numbers below ten are spelled out per the Associated Press Stylebook convention or written numerically throughout, and whether contractions appear at all.

When a brief should be split into two prompts

Not every job belongs in one brief. Drafting, reviewing and revising want different instructions and different inputs — a Create brief needs the deliverable and reader, a Review brief needs the original brief plus the draft plus the source material, and a Refine brief needs the approved corrections rather than a general instruction to "make it better."

The practical test: would you hand the whole job to one person in a single sitting? If the answer is no because reviewing a draft against a brief is genuinely a different task from writing it, the model should not receive it as one undivided request either. The A-Z AI Prompt Encyclopedia structures all 1,200 of its workflows this way, with a Create card, a Review card and a Refine card for every one of its 120 topics.

Splitting also solves a subtler problem: a single prompt asked to both produce and judge a draft has an incentive, baked into how these models are trained on helpfulness signals, to present its own output favourably. Handing the Review stage the original brief, the draft, and the source material — but not the instruction that produced the draft — removes that built-in bias and gives the review a genuinely independent basis for its findings, closer to how an editor works from a manuscript rather than from the author's notes on their own intentions.

Testing whether a brief is actually good

A brief is good if two different people, handed only the brief and no other context, would produce recognisably similar work. If two competent people would go in different directions, the brief has a gap — usually in the reader, the format, or the test — and the model will exploit that gap the same way a human would.

A faster proxy: read the brief aloud and count how many times you would need to add "and also" to cover something you assumed but never wrote down. Each "and also" is a missing field. Write it into the brief and reread; a brief that needs no additions on the second pass is close to complete.

A third check is the swap test. Take a finished brief for Client A and replace only the reader field with Client B's details, leaving the rest untouched. If the resulting brief still reads as coherent and specific, the other five fields were doing too little work and probably drifted toward generic language somewhere along the way. A genuinely specific brief usually breaks in an obvious way when you try to reuse it for a different reader, because the source material, the format, and the test were built around that one reader's actual situation.