Build a reusable writing brief before polishing the prompt

The brief is the contract; the prompt is only transport

A clever prompt can produce an impressive first draft and still leave the next writer guessing. A reusable brief states what must remain true across tools, people, and revisions. Keep it in the project repository or shared workspace, not only inside a chat. Link to it from the task, and version it when the audience, evidence, or acceptance rules change.

Start with the reader and the job. The UK Department for Education’s content-strategy guidance says a strategy should identify the product or service, users, purpose, user goals, how content supports those goals, and how success will be measured. A single article brief can use the same skeleton at smaller scale.

Use four blocks that do different work

The facts block is not a bibliography dump. For each load-bearing claim, give the source and a note about what it supports. Mark facts that may change and say when they were checked. If the writer may add research, specify allowed source classes and how new claims must be recorded. This keeps evidence separate from instruction and makes the later revision-diff review much faster.

The style block should establish a hierarchy. Google’s developer documentation style guide recommends project-specific guidance first, then the broader house guide, then third-party references. Apply that logic even outside technical writing: project decisions override a generic style sheet, and any deliberate exception should be recorded. Include a short “prefer/avoid” list and one small original example written for the project. Do not paste a large imitation sample from another publisher.

Turn taste into acceptance criteria

Acceptance criteria are checks a reviewer can perform. Replace “authoritative tone” with “distinguish source fact from recommendation; no unsupported superlatives.” Replace “concise” with a useful range and structural limit. Replace “SEO-friendly” with “title names the reader problem; headings describe actual sections; links use descriptive text.” Add content-specific checks such as every date having a basis, every hypothetical example being labeled, and every unresolved contradiction remaining visible.

Include a rejection boundary. State what the piece must not become: a product roundup, legal advice, an invented case study, or a disguised sales page. A boundary is particularly useful when an assistant is asked to improve prose, because fluency can conceal scope drift.

Test the brief with a cold reader

Give the brief and source pack to someone who did not attend the planning conversation. Ask them to outline the piece and identify what would make it fail. If they need oral context, add that context to the brief. A hypothetical test could ask two writers to produce only an outline and evidence map; comparing those artifacts reveals ambiguity before anyone spends time on full prose.

1. Write the reader need and destination in one sentence each.
2. List approved facts with source and uncertainty notes.
3. Define the project style hierarchy and key exclusions.
4. Express acceptance as observable checks.
5. Run a cold-reader outline test and revise the brief.

Store the final brief beside the output and note which version governed the draft. The archive’s document-drafting feature record and writing-assistant launch record show interfaces changing over time; a project brief should remain usable when the drafting surface changes.