Where this comes from
Primary sources
- Prompting best practices · Anthropic (Claude Platform Docs) (accessed 09/19/2026)
- Prompt engineering · OpenAI (API documentation) (accessed 09/19/2026)
Topics at every level
Briefing: saying what you want
Saying what you want clearly enough that the model does not have to guess.
Sourced
Concept at a glance
Make success and the boundaries explicit.
Read the connections in words
- Goal + context → Boundaries: Constraints and examples.
- Boundaries → Acceptance check: What counts as done.
Give the model enough information to work without inventing the missing requirements.
CHOOSE YOUR PERSPECTIVE
Same concept, different task and consequences. Switching starts a fresh walkthrough; prior answers and approvals do not carry over.
GUIDED WORKED EXAMPLE Fictional fixtures · scripted outputs · no live model or external actions
Briefing: saying what you want: see it in practice.
Describing the goal, context, constraints, deliverables, and uncertainties so work can proceed without unnecessary guessing.
What you’ll walk through
Follow a short task description into a usable working brief. Inspect which details constrain the work and which can remain open for proposals.
The task in this version
Plan a free repair workshop for 20 people under $300.
What you’ll learn to check
Brief before/after, explicit unknowns, acceptance criteria, and a plan checked against them.
The setting makes the example concrete. Carry the underlying pattern into your own work; adapt the sources, tools, and level of oversight to your task.
Everyday lifeAn authored case with its own evidence, changed condition, and decision.
Plan a free repair workshop for 20 people under $300.
Authored case. Select any record below; nothing is sent to a model.FOLLOW THE EXAMPLE1 / 6
Interpret this honestlySample evidence, not your actual data.No real messages, tools, training, or hardware operations run.The sequence illustrates the concept; it is not a recorded agent trace.
THE VISIBLE WORKStarting evidence
Input record
AUTHORED TEACHING RECORD · NOT A LIVE RUN
Saturday; step-free venue required. Unknown: venue availability and borrowed tools.
What changed: Establish the facts supplied for this version of the task.
WHY THIS MATTERS
What this case assumes
A brief should supply the goal, relevant context, and success criteria without pretending every preference is already decided.
1 / 6
Apply this to your project
Describe your task to your own model and use Briefing: saying what you want as a reference. Ask whether it fits, which alternatives meet the same automation needs, and how you would implement and check the result.
Go deeper: practical guidance, failure modes, and implementation
A brief is everything a model needs in order to act without guessing. Six parts: the goal, the context you have that the model does not, the constraints it has to respect, what a finished result looks like, what to do when something is unclear, and the format to answer in. Leave one out and the model supplies it itself, usually with something plausible rather than a question back to you.
Anthropic’s own prompting guidance makes the point directly: “Think of Claude as a brilliant but new employee who lacks context on your norms and workflows”, and offers a test it calls the golden rule: “Show your prompt to a colleague with minimal context on the task and ask them to follow it. If they’d be confused, Claude will be too.”[1] The six parts are that rule taken apart.
This page is about what a request must contain. The moves inside a request (worked examples, an assigned role, asking for reasoning first) are prompt engineering; how much of the six parts you have to spell out grows with how much the model is left to decide, which is operator craft’s thesis applied to one skill.
This page is sourced, not measured: the advice below is checked against primary sources, but no result file exists for any of it, so no number here is one this site took.
Practical guidance
Here is the same job briefed three ways, from lightest to heaviest. A contracts manager wants renewal dates pulled from supplier agreements.
One chat message. Before: “Summarize this contract.” After: “List every renewal and termination
date in this agreement, one line each, as date / clause number / what happens on that date.
Quote the clause. If a date depends on a condition, say so instead of picking one. If the
agreement does not state a date, write ‘not stated’ rather than inferring it.” That’s the whole
brief in four sentences: goal, format, constraint, and what to do when unsure. Anthropic’s own
guidance backs two of these as plain instructions: “Be specific about the desired output format
and constraints” and, for research work, “Define what constitutes a successful answer to your
research question”[1].
You’ll know the brief worked when the reply follows the format on the first try and writes “not stated” instead of guessing at a missing date. If it invents a date instead, the constraint didn’t land; fix it by putting that line on its own, not by repeating the same paragraph louder.
An agent working for an hour over forty agreements needs everything above, plus what a single message never had to say: which folder, which file types, that it must not modify the source files, and what “done” means, a table with one row per agreement, including the ones it failed on. Skip writing any of this down for a question you’re asking once, with nothing to reuse and no one else who has to follow it; that’s not what a brief is for.
A standing policy, for an assistant that runs every week unasked, has no next message from you to catch a wrong guess, which is exactly why it needs a stated rule for what waits for a person and what doesn’t, before the first run rather than after.
How much detail suits the model also matters. OpenAI’s guidance draws the line by model type: “A reasoning model is like a senior co-worker. You can give them a goal to achieve and trust them to work out the details. A GPT model is like a junior coworker. They’ll perform best with explicit instructions to create a specific output.”[2] Test which kind you’re briefing before assuming more detail always helps, or that it never does.
Implementation details
No runnable example accompanies this page: a brief is a written artifact, not an algorithm with a fixed answer to test against. What a builder decides is whether the six parts get written down at all.
A free-text box makes the brief and the request the same blob of prose, so a constraint typed in sentence four is one rewrite away from vanishing without trace. A task input with separate fields (goal, context, constraints, done looks like, what to do when unsure, output format) costs more to build and pays for itself the first time someone can point at the field that was left blank instead of re-reading a paragraph to guess what went missing. Two of those fields deserve default values rather than a blank box: “stop and ask” for uncertainty, and a house format for the output. A default is a policy nobody has to remember to state.
The uncertainty field earns its place at exactly the level where a person stops reading every response. An agent that is not told what to do when the brief runs out will pick something, because silence reads as permission rather than as an open question; the checkpoint that catches that is on the human approval page.
For a standing brief (a system prompt, a project’s instructions file, a document an agent loads before a task) the same six parts apply, written once and reused. Two things change at that scale. The brief now has versions, so it needs to be stored and diffed like code rather than edited in a settings box nobody can audit; and it can be tested, which is the evals topic applied to a document instead of a model. The test to run is not “does the model do something reasonable” but the colleague test above, applied to the document: hand it to someone who does not know the task and see whether they can say what the goal is, what they may not do, and when they should stop and ask. This site’s own recommendation, from the same reasoning: when a result comes back wrong, find which of the six parts was missing before writing a stronger version of the same words, and fix it in the stored brief rather than in the one message.
At each level
- Conventional software: nothing to brief; a rule takes an input and produces an output with no instructions to interpret.
- Direct prompting: the brief is the whole interface, and it is cheap to fix: a bad result costs one retry.
- Added context: the brief has to say which material counts, because the retrieval step will otherwise choose for you and the answer will not say it did.
- Workflows: each step carries its own brief, so a vague one in the middle of a chain shows up as a bad result several steps later.
- Tool use: the brief has to name which actions are allowed, not only what answer is wanted: the model is choosing what to do, not only what to say.
- Agent loops: the brief has to define “done” for a loop that decides for itself when to stop, and say what to do when it is unsure, since there is no next message from you mid-run.
- Teams of Agents: a lead agent writes the briefs for the others, so yours now has to say how the work should be split, not only what should come back.
- Always-on agents: the brief becomes a standing policy (what it may decide alone, what always waits) and it is read at moments you are not present for. See always-on assistants.
Practices
- Write the six parts as separate lines. A missing constraint is invisible inside a paragraph and obvious in a list.
- State the output format every time. A model guesses a shape as readily as it guesses a fact.
- Say what to do when the brief runs out: stop and ask, or make a stated assumption and flag it. Silence is read as permission to guess.
- Include the failures in the definition of done: the list it could not process is part of the result, not an exception to it.
- Keep the fix in the brief, not in the retry. A stronger version of the same words fixes one output; the missing part fixes the next hundred.
- Judge the result against the brief, not against what you meant. That is where reviewing picks up.
Run it
What to monitor
How often a result is rejected for something the brief never said, rather than for something the model got wrong. A rising rate against an unchanged brief means the brief is the thing to fix.
Cost at volume
Writing a brief costs less over time as a house style forms and the same fields get reused. Skipping it costs more over time, because the same gap is now read by every run: a missing constraint in one chat message is a redo, and in a standing brief it is every result until someone notices.
How it fails in production
A brief written for a single chat reply is reused unchanged for an agent that now works on its own for an hour. The constraints were enough for one message and say nothing about what may happen on the way to it.
What to log
The brief as it stood at the time, with a version, next to what came back. Without the version you cannot tell a model regression from an edit somebody made to the instructions last Tuesday.
Try it
- Use it
Take a request you send a model often. Write the six parts on six lines: goal, context it lacks, constraints, what done looks like, what to do when unsure, format. Send that instead. Which of the six turned out to be missing from what you had been sending?
- Build it
Find a system prompt or task template you rely on, your own or one built into a product. Check whether it says what to do when the model is unsure, and whether it defines done in a way that includes the items the run could not handle. Add whichever line is missing.
- Either lane
Run the colleague test on that brief: give it to someone who does not know the task and ask them what the goal is, what they may not do, and when they should stop and ask. Whatever they cannot answer is what the model is currently guessing.
How it connects
Before, after and instead of this
Often used with
Optional: products, tools, and models
Concrete examples
In practice
Specify a test-plan draft
Supply requirements, available equipment, limits, and what a complete test plan must contain.
An illustrative task example. No verified product or tool is currently listed for this concept.
Out there
Named products, tools and models
No product, tool or model is registered against this page yet. The names index lists every one the site does name, and which technique each belongs to.
Names listed 09/19/2026. 223 of 223 registry entries have been checked against the maker's own page; the registry marks the rest as unchecked.
Last reviewed 09/19/2026. Pages unreviewed for 90 days are flagged for another pass. Markdown version of this page