How to write a content brief: the AI template that works

How to write a content brief comes down to one idea: it is the actual spec an AI draft gets judged against, not a nice-to-have you skip when you're in a hurry. Most teams either skip it and hand a model a one-line prompt, or write one in a Google Doc that nobody reopens once the draft comes back. Both produce the same result: a fluent post that reads fine and ranks nowhere. This post is the template that fixes it, plus the reasoning for treating a brief as a PR description or issue template instead of a doc, so it stays the artifact a reviewer actually checks the draft against.

How to write a content brief that beats a prompt

The brief matters more than the prompt because the prompt only shapes tone, and tone was never the problem. 96.55% of pages in Ahrefs' search-traffic index get zero organic traffic from Google, and the study attributes that to three causes: no real search demand for the topic, no backlinks pointing at the page, or a mismatch between the page and what the searcher actually wants (Ahrefs, 2023-2026). A brief cannot build backlinks, but it can force the other two decisions before a draft exists: it names the query the page is supposed to win, so demand gets checked up front, and it states the search intent explicitly, so the page is built to match what the searcher wants instead of a shape the writer assumed.

This lines up with what separates B2B teams that improve from those that stall. 97% of B2B marketers report having a content strategy, but among those, 74% say refining that strategy, not adding budget or headcount, is what actually drove better results (Content Marketing Institute, B2B research). The lever most teams reach for (more posts, a better prompt, a bigger budget) is not the one that moved the number. The lever that worked was tightening the spec each post gets written against, which is exactly what a brief is.

A prompt describes a mood, a brief describes a spec

"Write in a formal, professional voice" tells a model almost nothing it can check itself against. A brief that says "the primary keyword must appear in the title, the first 100 words, and two H2s, cite the Q3 pricing page for the price claim, and answer the H2 'what does it cost' in the first sentence under it" gives the model a spec it can satisfy or fail, visibly.

This is not a Lyra-specific claim. A methodology write-up on controlling AI writing style argues that vague, mood-based instructions to a model ("write formally," "sound analytical") do not recover a target style, because the model has nothing specific to reproduce and defaults to a generic, statistically average register instead (Tricontinental: Institute for Social Research). Concrete, checkable rules did what the vague instruction couldn't. A content brief is that same idea applied to a blog post instead of a paragraph of prose.

What happens when a model gets a spec instead of a vibe

It stops hedging and starts committing. Ask for "a helpful post about SEO content briefs" and you get a competent, forgettable survey of the topic that could have been written about any topic in the category. Ask for a post that must open by answering "why does a content brief matter more than a prompt," must cite a named study for that claim, and must place the primary keyword in the first 100 words, and the model has three specific things to get right instead of one vague thing to approximate.

Generic output is not a minor complaint either. In a survey of 132 marketers using AI for content, 87 named generic-sounding output as their top quality complaint, ahead of outdated information (51) and content that misses real expertise (43) (Brafton). A vague brief is the direct cause of the complaint marketers rank first. Voice consistency is a separate problem from scope and sourcing, and it's worth keeping the two apart: a brand voice style guide fixes how every post sounds, while the brief fixes what this one post has to cover, cite, and prove. Confuse the two and you end up with a voice guide trying to also carry keyword placement, or a brief trying to also carry tone rules, and neither does its job well.

What a good AI content brief includes

A brief that actually constrains a draft has five parts: the audience and intent, the keyword placement, the required outline, the sources, and the post type. Miss any one of them and the model fills the gap with a plausible guess, which is exactly the failure mode a brief exists to prevent.

Audience and search intent, stated explicitly

Name who is searching the target query and what they want when they find it: to learn a concept, compare two options, or buy something. This single sentence decides format before anything else does. "How to write a content brief" is informational intent from someone about to write one, not someone comparing brief-writing tools, so the post needs a template and a worked example, not a feature comparison. Get intent wrong and the rest of the brief optimizes the wrong shape of page.

Primary keyword, secondary keywords, and where they must land

List the primary keyword and 3-5 secondary or related phrases, then say exactly where each one has to appear: the title, the first 100 words, at least two H2s. "Use the keyword naturally throughout" is not an instruction a model can verify it followed. "The primary keyword appears in the title and in the first paragraph, and two of the secondary keywords each appear in one H2" is.

Required structure: the H2/H3 outline the draft cannot skip

Every section gets a heading, a one-line note on what it has to answer, and a rough depth target. Depth guidance matters as much as the outline itself: a brief that lists ten H2s with no word-count or coverage note produces a draft that spends 400 words on the easy section and 60 words on the section that actually needed the depth. A worked example from this exact post: the brief for the section you are reading specified "explain the five brief components in roughly 150-250 words total, one short paragraph per component, no component skipped." That constraint is why this section is a list of five short paragraphs instead of one long one about "structure" in general.

Sources the model must cite, not sources it might find

Name the specific reports, docs pages, or datasets the draft has to pull facts from. "Cite reputable sources" is not a source; it is permission for the model to invent one that sounds reputable. Structured, labeled context handed to the model ahead of generation changes this dramatically: one benchmark found that tagged context prompts (source material labeled and fed to the model before it writes) eliminated hallucinated claims with 98.88% effectiveness compared to prompts given without that structure (arXiv:2306.06085). A brief that names its sources is doing, by hand, what that structured-context approach does automatically: it removes the gap where a model would otherwise have to guess. The fact-checking pass that runs after the draft comes back is what verifies the citation actually holds up, but it can only check a claim against a source the brief named. A brief with no sources gives the fact-check step nothing to check against except the model's own word.

Turning a brief into a reviewable artifact

A brief only does its job if someone can hold the finished draft up against it and see, line by line, what it did and did not deliver. That requires the brief to live somewhere a reviewer will actually open it back up, at the same moment they're reviewing the draft.

Why a brief that lives in a doc nobody reopens doesn't work

A brief written in a shared doc gets read once, at the start, by the person who wrote it or the model that consumed it. By the time the draft is back for review, the doc is a tab nobody has open. The reviewer ends up judging the draft against their memory of what the brief said, or worse, against no brief at all, just a gut sense of whether the post "looks right." That is the same failure mode a vague prompt produces: no spec to check against, so nothing to fail against either.

The brief as a PR description or issue template

If your content lives in a git repo, the brief belongs in the pull request that carries the draft, or in an issue the PR links back to. This is not a novel idea borrowed loosely from engineering; it is the same mechanism engineering teams already use for exactly this reason. A well-structured PR template reduces review back-and-forth by clarifying expectations up front, so context, what changed, and why don't have to get re-established in the comments (Axolo). A content brief as a PR description does the identical job: state the audience, the keyword placement, the outline, and the sources up front, and the reviewer checks the diff against that instead of re-deriving what the post was supposed to do. If your review process also runs automated checks, a GitHub Actions workflow that gates the merge on broken links and valid schema is the layer that verifies the technical half; the brief-as-PR-description is what a human reviewer checks the editorial half against.

What a reviewer checks the brief against once the draft is back

Five things, matching the five brief components: does the title and opening actually hit the primary keyword and intent, do the secondary keywords land where the brief specified, does the outline match section for section (and did any section get skipped or merged), does every named source actually get cited somewhere in the draft, and does the post type match what the brief called for. A reviewer working from a brief answers each of those in minutes. A reviewer working from memory ends up rereading the whole draft cold and guessing at what "good" was supposed to mean.

How to write a content brief for different post types

The five core components stay the same across post types. What changes is which one needs the most detail. A how-to brief lives or dies on its steps; a comparison brief lives or dies on its criteria; a GEO-focused brief lives or dies on its answer block and sourced claims.

How-to and tutorial briefs: steps, prerequisites, one worked example

Specify the numbered steps in the order the reader has to follow them, any prerequisite the reader needs before step one, and at minimum one worked example with real inputs and outputs, not a hypothetical. "Show an example" produces a vague, made-up scenario. "Walk through creating a brief for a comparison post, showing the actual keyword list and outline" produces the kind of concrete, checkable example a reader can copy.

Comparison and alternative-page briefs: the criteria table and the verdict

Name the specific competitors and the specific criteria the comparison has to score them on (price, a named feature, a support model), not "compare the tools." Specify that the post needs an actual table, not a paragraph pretending to be one, and state what the verdict has to commit to: which reader should pick which option, and why. A comparison brief with no named criteria produces a draft that restates each tool's marketing copy side by side instead of judging them against the same bar.

GEO/AEO briefs: the question the draft must answer in the first line, plus FAQ pairs

If the post is meant to get cited by an AI answer engine, the brief needs to specify the exact question each key section answers, and require that the direct answer come in the first two to four sentences under the heading, before any supporting detail. That is the same answer-first structure that makes a section quotable on its own: a passage a model can lift and cite has to make sense without the paragraphs around it. The brief should also list 2-5 real FAQ question-and-answer pairs the reader would actually search, since those are the exact shape an answer engine prefers to cite whole.

Common brief mistakes that produce generic AI drafts

Every one of these mistakes has the same signature: the brief leaves a decision open that the model then has to guess, and it guesses toward the generic, plausible-sounding average instead of anything specific to your post.

Vague tone words instead of checkable rules

"Write in a confident, authoritative tone" is not checkable. Neither the writer nor a reviewer can point to a sentence and say whether it satisfied that instruction. Replace tone words with rules a reviewer can verify against the finished draft: short declarative sentences for emphasis, active voice, contractions used naturally, one dated fact per major section. Those are the kind of specific, checkable rules a style guide should already carry, so the brief doesn't need to re-litigate tone at all; it just needs to point at the guide and spend its own space on scope, keywords, and sources.

No named sources, so the model invents or hedges

A brief with no source list produces one of two failure modes: a model that hedges everything into vague generalities to avoid a claim it can't back up, or a model that states a specific-sounding number that does not exist. Neither is acceptable, and neither is fixable after the fact by asking the model to "double-check its work," since the model that wrote the claim is the same model being asked to grade it. Name the sources up front and the ambiguity never has room to open.

An outline with no word-count or depth guidance per section

A ten-section outline with no depth notes tells the model that all ten sections matter equally, which is rarely true. One or two sections usually carry the real argument and need the most space; the rest are supporting context. Mark that in the brief (a rough word count, or "this is the core section, go deep" versus "this is a quick supporting point") or the draft will spread its attention evenly across sections that don't deserve equal weight.

Skipping the intent check, so the format fights the query

A comparison-shaped post written for an informational, how-to query reads oddly no matter how well it executes the comparison, because the format itself fights what the reader came to do. This mistake happens upstream of everything else in the brief: get intent wrong in the first line and no amount of keyword placement or sourcing in the rest of the brief will fix a page that answers the wrong kind of question.

A brief is only as good as the discipline behind checking a draft against it, which is the same discipline Lyra runs on every post she writes: she takes a brief like the one above, writes to your blog's existing voice, verifies every claim and link against the sources the brief named, scores the draft, and opens a pull request so you review the finished post against the same spec you'd have written by hand. If you're already comparing brief-and-score tools like Surfer against a pipeline that writes and verifies the whole post, Lyra vs. Surfer SEO covers where a scoring tool stops and a full writer-and-checker pipeline picks up, and the plans show what that costs beyond your own Anthropic key.

A content brief is the spec Lyra writes every draft against, and the pull request she opens is the reviewable artifact you check it with.

Try Lyra → · Talk to the founder