Outcome Over Instructions
By the end of this module you stop writing prompts and start writing briefs. You can name the five parts of a brief and the specific failure each one prevents, you can look at a disappointing output and say which part was missing rather than blaming the tool, and you can rebuild any request you make regularly into a form that works the first time. You leave with a file of your own briefs, written in your words, for the work you actually do.
the brief the failure it prevents ┌───────────────────┐ │ 1 the job │──▶ it optimises for the wrong thing ├───────────────────┤ │ 2 the material │──▶ it fills the gap by inventing ├───────────────────┤ │ 3 the constraints│──▶ right content, wrong reader ├───────────────────┤ │ 4 the output │──▶ an essay, when you wanted │ shape │ three lines you can send ├───────────────────┤ │ 5 the rules │──▶ the thing you always delete └───────────────────┘
Nothing here is politeness. Each part is in the list because of a specific way the output goes wrong without it.
- Name the five parts of a brief and the failure each one prevents.
- Diagnose a bad output by naming the missing part instead of retrying the same request.
- Describe an outcome rather than a sequence of steps, and say why that produces better work.
- Replace a paragraph of style adjectives with one example of what you want.
- Set length and format on purpose, every time, instead of accepting the default essay.
- Improve a request by editing the brief rather than arguing with the output.
ai-kit/requests.md — your three or four most repeated requests, each written out as a five-part brief you can paste and fill in, with the bad original kept above it so you can see what changed.
Here is a request of the kind that gets sent thousands of times a day.
write an email to my team about the project delay
What comes back is competent and useless. It is four paragraphs. It opens with "I hope this message finds you well". It refers to "the project" and "unforeseen circumstances" because it does not know which project or what happened. It apologises twice, offers to answer any questions, and would take you five minutes to fix and two minutes to write from scratch.
Nothing went wrong. Look at what it was given. It knows there is a delay, that there is a team, and that the output is an email. Everything else it had to supply, and Module 00 told you what it does when a fact is missing: it produces the most plausible version. The most plausible email about a delay, absent any specifics, is exactly the vague apologetic four-paragraph thing you got.
The request failed in five separate places, and each one has a name.
1. The job. What outcome you want, stated as an outcome. Not "write an email" but "tell six engineers the launch has moved two weeks so nobody hears it from someone else first". The failure it prevents: without it, the machine optimises for the wrong thing — it produces a well-formed example of the document type instead of something that achieves your purpose, and you cannot tell it is wrong until you have read it twice.
2. The material. The actual facts, pasted in or attached: what slipped, by how long, why, what changes for each person, what does not change. The failure it prevents: invention. Every fact you leave out is a gap, and the gap gets filled with something plausible. This is the part people skip most, usually because typing the facts feels like doing the work themselves.
3. The constraints. Who reads it, what they already know, what they will worry about, the tone the situation calls for, anything you must not say yet. The failure it prevents: right content, wrong reader. An announcement pitched at your director and an announcement pitched at the six people whose weekend it affects contain the same facts and are not the same message.
4. The output shape. Length, format, structure. Four sentences. A table with these columns. Three bullets and a closing line. The failure it prevents: the default essay. Left alone it produces prose of middling length with a windup and a wind-down, because that is the most plausible shape of a response, and you wanted something you could send.
5. The rules. What must not happen. No apology beyond one line. Do not invent a new date. Do not mention the client. Say "unknown" rather than guessing. The failure it prevents: the thing you delete every single time. If you find yourself removing the same phrase from every output, that deletion belongs in the brief as a rule.
Key insight: the five parts are not politeness and they are not magic words. Each one closes a specific hole that the machine will otherwise fill with the most plausible thing.
Same situation, five parts, roughly ninety seconds of typing.
The job: tell my six engineers the launch has moved from 14 March to
28 March, so that nobody hears it secondhand and nobody spends the
weekend on the old date.
The material: the delay is caused by the security review finishing
late. Two weeks. The scope has not changed and nobody's work is
wasted. The demo on 6 March still happens on the old build. I found
out this morning and told my director before writing this.
The constraints: these are six engineers who have already worked two
late nights on this. They will assume the scope grew. They read short
messages and ignore long ones. I do not want to name the reviewer or
imply anyone is at fault.
The output shape: under 120 words. Plain paragraphs, no bullets, no
subject line. The new date in the first sentence.
The rules: no more than one sentence of apology. Do not invent any
detail I have not given you, particularly reasons. Do not offer to
"answer any questions" at the end. If something important is missing,
say so instead of filling it in.The second output is not a better-written version of the first. It is a different message. It opens with the date, because you said so. It says the scope has not changed, because that is the thing the readers will be worrying about and you told it so. It runs to about a hundred words, so it can be read on a phone in one screen. It does not apologise twice and does not offer to answer any questions. And where the first version invented "unforeseen circumstances", the second names the security review, because you supplied the fact rather than leaving a hole.
Most of the difference came from parts 2 and 3. The material and the constraints are where the work is, and they are also where nearly everyone stops early.
There are two ways to ask for something. You can specify the steps — first summarise, then extract the dates, then group them by owner, then write it up. Or you can describe where you want to end up and what it should look like when you get there.
The second usually wins, because your route was built from your assumptions about what the material contains, and you were guessing. When you specify steps, you get your guess executed faithfully. When you specify a destination, you get the material handled on its own terms.
Steps become worth writing when the route itself is the requirement: when there is an order your organisation insists on, when one stage must be finished before the next begins, or when you have run the destination version and seen it consistently skip something. Then the steps are not a guess, they are a correction. Until then, say where you want to arrive.
This is also the first phrase of the course spine, quoted in Module 00: "Point it at an outcome, give it your context, check what comes back, keep what worked — and only then let it act." Point it at an outcome. Parts 1 and 4 of the brief are that phrase turned into something you can type.
"Professional but approachable, clear and concise, warm without being informal." Every word of that means something different to every reader, and the machine cannot know which meaning is yours. It produces the most plausible interpretation, which is the average of everything ever labelled that way.
Now paste two sentences you actually sent last month and write "like this". The example is not a description of your style, it is your style, and everything about it that you could not have named — sentence length, where you put the conclusion, whether you use contractions, how you open — arrives with it for free.
One caution: an example teaches shape as well as tone. If you paste an example and get back something suspiciously close to it in content, say what the example is for. "Match the register and length of this, not the subject matter." Module 07 builds this into a proper standards file from several samples of your own writing. For now, one example beats any paragraph of adjectives you could write.
Unless you say otherwise, you get an essay. Three to six paragraphs, an introduction that restates your question, a body, a summary of what was just said. It is the most plausible shape for a response, which is precisely why it arrives whether or not it fits.
So set the shape every time, and set it as something checkable: under 120 words, exactly five bullets, a table with these three columns, one paragraph and nothing else. "Be concise" is an adjective and will be interpreted generously. A number is not.
Format is worth as much as length. If the output is going into a spreadsheet, ask for a table. If it is going into a message, ask for something with no headings. If you are going to read it and decide something, ask for the recommendation in the first line and the reasoning after it, so you can stop reading when you have what you need.
Warning: asking for a specific length gets you approximately that length, not exactly. It cannot count its own words, for the reason Module 00 gave. Treat "under 120 words" as a strong instruction about shape, and check the number yourself if it matters.
When the output is wrong, the instinct is to reply in the same conversation: "shorter", "less formal", "you missed the bit about the demo". This works, and it is a trap, because the fix lives in a chat thread you will never find again. Tomorrow you write the same weak request and do the same repair work.
Do it the other way. When something comes back wrong, identify which of the five parts was missing, add it, and run the brief again from a clean start. The brief improves; the conversation does not need to. After three or four rounds you have a request that works first time, and that is the thing worth saving into ai-kit/requests.md.
There is a shortcut for when you are not sure what is missing: ask it to ask you. End your request with "before you answer, ask me up to five questions whose answers would change what you write." The questions are diagnostic. If it asks who the audience is, your constraints were thin. If it asks what actually caused the delay, your material was thin. Answer the questions, then fold the answers into the brief rather than leaving them in the chat.
Briefing costs ninety seconds and there are cases where it is not worth it, or is actively counterproductive.
Do not brief when you are thinking rather than producing. Half-formed, rambling, contradictory input is the right input when the goal is to find out what you think — a rigid five-part brief on a problem you have not understood yet just locks in your first framing and gets it executed. Talk first, brief second.
Do not brief a task you will do once and never repeat, where the whole job is two lines long. "Fix the grammar in this paragraph" needs no constraints section. The material is right there, the job is unambiguous, and a brief around it is ceremony.
And do not brief when what you need is a person's judgement. If the hard part is deciding whether to move the launch at all, no arrangement of five parts helps. The brief is for producing work, not for making the decision about what work to produce.
Twenty minutes, your own material, no installation.
- Your rebuilt brief contains at least one fact the original made the machine guess at.
- Your constraints section names a specific reader and something that reader already knows or will worry about.
- Your output shape contains a number or a named format, not the word "concise".
- Your rules section contains something you have personally deleted from an output more than once.
ai-kit/requests.mdholds at least three briefs, each headed with the task it is for.
Use this when you have a task in your head and do not want to type the five parts yourself. It interviews you briefly and hands back a finished brief you can paste into a fresh conversation. Run it separately from the work: this prompt produces the brief, and the brief produces the output. Keeping the two apart is what lets you save the brief and reuse it.
<task> Turn a task I describe loosely into a complete five-part brief I can paste into a fresh conversation to get the work done. </task> <context> My standing context, so the brief does not repeat what is already known: [paste the contents of ai-kit/about-me.md] </context> <input> The task, described however it comes out of my head, including the messy parts: [describe what you want done, who it is for, and anything you already know about why previous attempts were disappointing] </input> <instructions> First ask me up to five questions, one message at a time, choosing only questions whose answers would change what the finished work says. Prioritise missing facts and missing audience information over questions about style. Then write the brief in five parts: the job stated as an outcome rather than a document type; the material, listing exactly which facts or files I must paste in; the constraints, naming the reader and what they already know; the output shape, with a specific length and format; and the rules, stating what must not happen. Where I have not given you a fact, put a clearly marked placeholder in the material section rather than inventing the fact. </instructions> <output_format> One fenced code block containing the brief, with the five headings "The job", "The material", "The constraints", "The output shape" and "The rules", in that order. After the code block, one line naming which single part will do the most work for this task, and one line naming the fact I still need to supply. Nothing else. </output_format> <rules> Ask one question per message and wait for my answer. Do not do the task itself. Produce only the brief. Do not invent facts, names, dates or figures I have not given you. Do not use adjectives such as "professional", "engaging" or "concise" anywhere in the brief. Use lengths, formats and examples instead. Keep the whole brief under 250 words. </rules>
Use this on a request you have already sent that came back wrong. It is the diagnostic version: it tells you which parts were missing before it fixes them, which is the part that teaches you something. Keep the diagnosis it gives you; over three or four uses you will notice you leave out the same part every time, and that is the habit worth fixing.
<task> Diagnose a request that produced disappointing output, then rebuild it as a five-part brief. </task> <context> The five parts of a brief are: the job, stated as an outcome; the material, the facts and files; the constraints, the reader and the situation; the output shape, length and format; and the rules, what must not happen. </context> <input> The exact request I sent, unedited: [paste your original request, including its vagueness] What came back that was wrong with it, in my own words: [say what disappointed you about the output, or paste the output itself] </input> <instructions> Work through the five parts in order. For each one, state whether it was present, partly present, or absent in my original request, and if it was missing say what specifically was missing, naming the fact, reader or format rather than saying "more detail was needed". Then connect each missing part to the disappointment I described, where there is a connection. Say plainly if a problem I described was not caused by a missing part. Then write the rebuilt brief, carrying over everything usable from my original wording. </instructions> <output_format> First a five-row markdown table with the columns: Part, Present?, What was missing, Which problem it caused. Then a fenced code block containing the rebuilt brief under the five headings. Then one sentence naming the part I most often leave out, based on this request alone. </output_format> <rules> Do not soften the diagnosis or compliment the original request. Do not invent facts to fill the gaps. Where the rebuilt brief needs a fact I have not supplied, write a bracketed placeholder saying exactly what I must paste in. Do not produce the finished work. Produce the diagnosis and the brief. </rules>
Keep a note beside you for a week. Every time you fix an output by hand, write down which of the five parts would have prevented that fix. Your tally will point at one part more than the rest. Material and constraints are the two that go missing under time pressure, because typing the facts and naming the reader feel like doing the work rather than asking for it. Once you know your missing part, adding it deliberately for a fortnight is enough to make it automatic, and you will not need either prompt again.
You have three briefs written in your own words for work you actually repeat. Keep them where you can paste from them, because the next module opens them up: the material section is about to stop being something you retype and become a set of files.
Save as: ai-kit/requests.md — read again in Module 03 and Module 05.
Say these out loud. If one stalls, reread the section named beside it.
- I can name the five parts and the failure each one prevents. (The Five Parts of a Brief)
- I can point at all five parts in the last request I sent. (The Same Request, Rebuilt)
- I can name one task where writing a brief would be the wrong move. (When a Brief Is the Wrong Move)
Module 03, Context Is the Whole Game, takes the material section of your briefs in ai-kit/requests.md and turns it into reusable context files in ai-kit/context/, so you stop pasting the same background every time you ask for something.