You ask a new colleague to "look into why the newsletter numbers dropped". Three days later they hand you a twelve-page report on email deliverability, spam filters and industry trends. It is careful work. It is also not what you needed. You wanted one answer: was it the new subject-line style we started last month, yes or no?
Your colleague filled every gap in your request with a guess. AI assistants do the same, faster. When an assistant works alone for many steps, each guess compounds before you see anything.
Prompting Basics covered the four parts of a single request: task, context, shape and input. A brief is what you write when the job is bigger: a research question, a document, a change across a codebase, anything where the model will make many decisions without you. It has four parts too, aimed at those decisions.
Goal. The outcome you want and why. "Decide by Friday whether to revert the subject-line change" tells the model what matters.
Context. What it needs to know that it cannot find out: the data, who the result is for, what you already tried, what else changed.
Constraints. What it must and must not do, with the reason. Sources to use or avoid, files it may touch, time or length limits.
Done. What to hand back, in what form, and what to do if the answer is "I cannot tell".
Start with the one-line request about the newsletter. Then add the brief one part at a time, and watch which of a contractor's questions get answered.
Building a brief, one part at a timeUse the arrows or ← → keys
questions
0why?
1for whom?
2data?
3other changes?
4limits?
5how long?
6hand back?
open questions
7
brief parts
0
1The one-line request leaves all seven questions open. The model will guess each answer.
questions
0why?
1for whom?
2data?
3other changes?
4limits?
5how long?
6hand back?
open questions
5
brief parts
1
2Add the goal: decide by Friday whether to revert the new subject-line style; the editor reads the answer. Now it knows what the work is for and who reads it.
questions
0why?
1for whom?
2data?
3other changes?
4limits?
5how long?
6hand back?
open questions
3
brief parts
2
3Add context: results for the last 20 sends, and the fact that the send time also moved from 9am to 7am. Without that fact, the model could blame the wrong change.
questions
0why?
1for whom?
2data?
3other changes?
4limits?
5how long?
6hand back?
open questions
2
brief parts
3
4Add constraints: only the attached data, no general advice. That rules out padding.
questions
0why?
1for whom?
2data?
3other changes?
4limits?
5how long?
6hand back?
open questions
0
brief parts
4
5Add done: under 200 words, a verdict, the numbers behind it, and what to do if the data cannot decide. Nothing is left to guess.
One-line requestIllustrative example. Real replies vary.
You
Find out why our newsletter open rate dropped.
Model
Open rates usually drop for one of a few reasons:
1. Deliverability: emails may be landing in spam folders...
2. List fatigue: subscribers may be getting too many emails...
3. Subject lines: weaker subject lines can reduce opens...
I recommend reviewing your sender reputation and segmenting your list...
BriefIllustrative example. Real replies vary.
You
Goal: our newsletter open rate has fallen from about 41% to 32% over the last four sends. I need to decide by Friday whether to revert the new subject-line style we started on 2 September. I will forward your answer to our editor.
Context: the attached CSV has the last 20 sends (date, subject line, recipients, opens). Two weeks after the subject change, we also moved the send time from 9am to 7am. Nothing else changed that we know of.
Constraints: use only the attached data. No general email-marketing advice.
Done: under 200 words. Start with one of: revert, keep, or can't tell. Then give the two or three numbers that support it. If the data cannot separate the subject change from the send-time change, say so plainly and suggest the smallest test that would.
Model
Can't tell yet, but the send time looks more likely.
- The two sends after the subject change, still at 9am, had open rates of 40% and 39%, close to the earlier average of 41%.
- The drop starts with the first 7am send: 34%, then 32%.
- The timing matches the send-time change, but two sends on each side is too few to be sure.
Smallest test: next week, split the list in half. Send the new-style subject to both halves, one half at 9am and the other at 7am. Compare open rates.
The second reply is short because the brief said what to leave out. It is useful because the brief included a fact the model could not have known: the send time changed too. And it is easy to check: open the CSV and look at four numbers.
This request produced a generic list of ten tools with feature tables copied from their marketing. Rewrite it as a brief with a goal, context, constraints and a definition of done.
Show a sample answer
Rewritten briefIllustrative example. Real replies vary.
You
Goal: help me pick a task tracker for my team by the end of the month. We are moving off a shared spreadsheet that has become hard to keep up to date.
Context: six people, two part-time, working in two-week cycles. Half the team works mostly from phones. We want updates posted into our team chat.
Constraints: free or low-cost plans only. Skip tools built mainly for large companies. Where you are not sure a feature exists on the free plan, say so rather than guess.
Done: a table of at most four tools with columns: works well on phones, posts to chat, free-plan limits that would affect six people, biggest drawback for us. Then one paragraph recommending one, with the reason. Mark anything I should confirm on the tool's own pricing page.
Why it works: the goal and team details turn "best tools" into "best for us". The constraint invites an honest "not sure" instead of a confident guess. "Done" fixes the size of the answer and tells you which claims to verify.
Try it: Brief a coding agent
A coding assistant that can edit files and run commands was given this request. It renamed dozens of functions, deleted two files it thought were unused (one was not), and reformatted everything. Rewrite the brief.
Show a sample answer
Rewritten briefIllustrative example. Real replies vary.
You
Goal: utils/ has grown messy and new teammates cannot find things. I want it easier to navigate, without changing how anything behaves.
Context: utils/dates.js and utils/format.js overlap; both have date-formatting helpers. Some helpers in utils/ are used by the mobile app, which lives in a separate repository, so "no callers here" does not mean unused.
Constraints: do not delete any file or exported function. Do not rename exports. Do not reformat code you are not otherwise changing. Keep each change small enough to review on its own.
Done: first, reply with a plan only: which helpers overlap, and what you would merge or move. Wait for my approval. After I approve, make the changes, run npm test, and give me a list of every function that moved and where it went.
Why it works: the context holds the one fact that made the first run destructive: code is used from outside this repository. The constraints rule out the noise, and "plan first, then wait" puts a checkpoint before anything changes, the small-steps habit from Coding With AI.
Before your next long AI task, write the four parts as four short lines, even if you then merge them into prose. Then continue with Learning With AI, where the goal of the work is your own understanding.