What to put in an AI writing brief

A blank prompt box encourages a familiar shortcut: name the topic, choose a word count and ask for an article. The resulting draft may be grammatical and still miss the assignment. It might explain a concept the reader already understands, invent an example that sounds like a customer story, or end with a recommendation the available evidence cannot support.

A writing brief gives the writer and the tool the same assignment. It records the reader’s problem, the material available to solve it and the boundaries of the finished piece. You can reuse the structure across tools. The details should change with each job.

The following method is an editorial workflow, not a promise that any prompt will produce a publishable draft. The purpose is to make the assignment clear enough that a person can judge the result.

Begin with the decision the reader needs to make

“Small business owners” is a market description. It is too broad to guide a useful article. A better brief might say: “An owner of a five-person design studio needs to decide who should approve client deliverables while the project manager is away.” That reader has a situation, a decision and a practical constraint.

Write one sentence describing what the reader should be able to do after reading. For this example: “Create an approval plan that names a backup reviewer and explains which decisions still require the owner’s attention.” The sentence becomes a test for the outline. A section about the history of project management probably does not earn its place.

The GOV.UK guidance on learning about user needs starts with understanding what people are trying to accomplish and their existing circumstances. For an editorial brief, that suggests a useful habit: capture the reader’s task before choosing the article’s format.

Add the reader’s starting knowledge. If they already manage client projects, define unfamiliar approval terminology but skip a general explanation of deadlines. If they are hiring their first employee, more foundational context may be necessary. This prevents the draft from swinging between beginner explanations and unexplained specialist language.

State the deliverable and its stopping point

Describe the output in concrete terms: a 900-word guide, a customer email, a product comparison or a short internal procedure. Include where it will appear and what surrounds it. An email with an existing subject line and attachment has different responsibilities from a page that must stand alone.

Then set a stopping point. The approval-plan article might include a sample handoff checklist but exclude software recommendations, employment policy and legal guidance. A boundary is especially useful when the topic invites adjacent advice. It lets the reviewer distinguish helpful detail from expansion that belongs in a separate piece.

Separate requirements from preferences. “Include the exact cancellation deadline supplied in the source packet” is a requirement. “Prefer short paragraphs” is a preference. When a word limit creates pressure, the draft should preserve the deadline before preserving a stylistic habit.

Build a source packet a reviewer can use

Attach or paste the actual material needed for the assignment. Give each source a short identifier, its owner or publisher, its date and the specific information it supports. For an internal procedure, the packet might contain an approved operations document, a manager’s written answers and a list of unresolved decisions.

A source packet is more useful than a pile of links. Identify the relevant sections and note any restrictions. If a product page supports the existence of a feature but says nothing about its performance, say so. If an interview contains an opinion, label it as an opinion. A quotation should have exact wording and a clear attribution.

Use a simple record such as: “S2, approval policy, revised 8 September: supports the backup reviewer’s authority to approve routine changes. Does not cover changes to the client’s budget.” That last sentence makes the evidence boundary visible.

Before using private material, check the tool and account against your organization’s information policy. Replace unnecessary personal details with neutral labels. Removing a person’s name may not be enough if the surrounding facts still identify them. The practical question is what information this assignment actually needs, and where you are authorized to process it.

Tell the tool what to do when information is missing

“Be accurate” is a goal. It does not explain how to handle an unanswered question. Give the draft a specific fallback: mark unsupported details as questions for the editor, omit claims that require unavailable evidence, and never fabricate a quotation or customer result.

For the approval example, the brief might say: “The backup reviewer’s spending authority is not confirmed. Put that issue in an editor note. Do not supply a dollar limit.” This instruction gives the model a permitted response to a gap and gives the editor a visible follow-up task.

Also explain how to handle conflicts. If two documents contain different dates, ask for the discrepancy to be reported instead of silently selecting one. Identify which document controls only when someone with authority has made that decision. A model should not settle an internal policy dispute by guessing which file looks newer.

Give examples with an explanation

Two short examples can make “plain and practical” less ambiguous. Show a sentence you would accept and explain its useful features. “Name a backup reviewer before the project manager leaves” works because it identifies an action and a timing requirement. “Improve your approval process for better outcomes” does not tell the reader what to do.

Keep example facts separate from assignment facts. Label invented examples as illustrative so they are not mistaken for real customer evidence. If the example concerns a different industry, explicitly say that its style may be borrowed but its details may not.

Anthropic’s prompt engineering overview puts success criteria and ways to test them before prompt refinement. The editorial application is straightforward: explain what a good result looks like before repeatedly adjusting the wording of your request. A clear rubric is more useful than another adjective describing the desired tone.

Use a reusable brief with an editable core

For the next assignment, fill in these fields in ordinary language:

• Reader and situation: Who is reading, and what has happened that makes this useful now?
• Reader outcome: What specific decision or action should the piece support?
• Deliverable: Format, destination, approximate length and required sections.
• Source packet: Labeled material, dates, supported claims and known limitations.
• Boundaries: Topics to exclude, claims to avoid and information that remains unresolved.
• Voice examples: Two short examples with reasons, plus any necessary terminology.
• Review standard: How to mark gaps and what a human must approve before publication.

Keep stable team rules in a shared reference, then include only the relevant ones in an individual assignment. A brief buried beneath several pages of unrelated policies becomes difficult for a human to maintain as well.

Test the brief before commissioning the whole draft

Ask for a proposed outline and a short list of missing information. Review the section headings against the reader outcome. Check whether the tool has introduced unsupported assumptions, particularly around who is allowed to make decisions or which benefits are guaranteed.

For the example article, a useful outline would cover choosing a backup, identifying approval limits, recording escalation contacts and telling the team where the plan lives. If the outline instead offers ten productivity apps, the assignment needs correction before drafting begins.

Save the brief alongside the final edited piece. Add a short note about what the writer had to ask and what the first draft misunderstood. After several assignments, those notes will reveal which fields deserve better instructions. Start by completing this brief for one real piece on your calendar. Its value appears when the next reviewer can understand the assignment without reconstructing it from a chat history.