Topic 3.2
Writing Clear Instructions
In one line
A clear instruction names the task, the context, the audience, the output format and the constraints. Say what to do first; add what to avoid only when needed. Build the prompt from named parts in code.
Think of it like this
Briefing a new colleague on their first day. "Handle the shipping emails" gets you confusion. "Reply to shipping emails (task). Use the order sheet (context). Customers are often upset first-time buyers (audience). Two short paragraphs, no jargon (format). Never promise a date (constraint)" gets you good work from hour one. A model is the newest colleague you will ever have, with no memory of yesterday.
Words you'll meet
New words in this topic, in plain English. Come back here whenever one feels fuzzy.
- Task
- What you want done, in one verb: classify, extract, summarise, rewrite, answer.
- Context
- Facts the model needs and cannot guess, such as order status or a policy.
- Audience
- The person or system that will read the answer.
- Format
- The shape of the answer: bullets, one word, JSON, two sentences.
- Constraint
- A limit on the answer: length, tone, things to leave out.
- Temperature
- A setting that controls how random the model's choice of next piece is. Low is steadier, high is more varied (Topic 1.6).
Step by step
01Step 1: the task-only prompt
"Explain the shipping status." The fake model has nothing to go on and gives a general answer about logistics networks. A real model would do the same, or invent a status.
02Step 2: add context and audience
Now the prompt includes the facts (left the depot on Monday, due in 3 days) and the reader (a new customer). The reply uses the facts and a plain tone.
03Step 3: add format and constraints
Add "two bullet points" and two rules. The reply becomes two short bullets. Notice the rules are phrased as things to do or limits to meet, not as a pile of "don't"s.
04Step 4: build it in code, not by hand
A function turns the parts into a prompt and skips empty ones. Every prompt gets the same labelled lines, so a reader (and a model) can find each part.
def build_prompt(task, context="", audience=""):
parts = ["Task: " + task]
if context:
parts.append("Context: " + context)
if audience:
parts.append("Audience: " + audience)
return "\n".join(parts)05Step 5: try it on a real model
The lab below starts with a vague request. Rewrite it using the five parts and watch the goals turn green. The same prompt on a real model is allowed to vary a little between sends, so a good prompt is one that passes most of the time.
Try it yourself
- 1
Remove one part at a time
In the runnable example, delete the
audienceargument from the "full" prompt and run. Which reply do you get? Then delete only the format. Notice that each part changes a different thing. - 2
Turn a negative into a positive
Change the rule "Give no exact delivery date" into a positive instruction ("Say the delivery is expected within 3 days"). The fake model does not care, but think about which version a real model follows more reliably, and why.
- 3
Use the lab
In the lab, first ask "Tell me about the moon." unchanged and count the words. Then add the five parts one by one, sending after each. Which single change shortened the reply the most?
Code & diagrams
The fake model only reacts to the audience and the format lines. A real model uses all of them.
Expected output
== task only (20 words in the reply)
> Task: Explain the shipping status
Shipments move through a multi-stage logistics network, and arrival times depend on carrier capacity, customs, weather and many other factors.
== with context and audience (14 words in the reply)
> Task: Explain the shipping status
> Context: The parcel left the depot on Monday and is due in 3 days
> Audience: a new customer
Your parcel left our depot on Monday and should reach you within 3 days.
== full (16 words in the reply)
> Task: Explain the shipping status
> Context: The parcel left the depot on Monday and is due in 3 days
> Audience: a new customer
> Format: two bullet points
> Rule: Give no exact delivery date
> Rule: Use at most 25 words
- Your parcel left our depot on Monday.
- It should reach you within 3 days.Try: Press Send first and read the reply. Then rewrite the request with a task, an audience, a format (3 bullet points) and a length limit (under 40 words), and send again. Do the goals turn green?
Goals
- 40 words or fewer
- It uses bullet points
- The reply finished on its own
Sign in to send this request to a real model (free).
Break it on purpose
Errors are the best teachers. Make each change, read the error, guess what went wrong, then reveal the answer.
Break #1
Forget the audience
In the "with context and audience" prompt, remove audience="a new customer" (keep the context).
Myth vs fact
Myth
Telling the model what not to do is the best way to control it.
Fact
A positive target is usually followed more reliably than a bare prohibition, though it depends on the model, so test it. Use a short list of specific "never" rules for hard limits and say what to do for everything else.
Myth
Saying "please" or shouting in CAPS makes the model obey.
Fact
Clarity matters, not volume. Repeated capital-letter commands are often a sign of an unclear prompt. Bold the requirement by being specific.
Myth
The model knows my company's policies.
Fact
It knows only public text from training. Facts about your business must be in the prompt as context (or retrieved, Phase 8).
Pro corner
Extra depth for experienced readers. New to this? Skip it for now and come back later.
- ▸
Order matters a little. Put the stable instructions first and the changing data last. Providers can reuse (cache) a repeated prefix at lower cost, and a cached prefix needs the same text each time (Topic 6.6).
- ▸
Models treat numbers as targets, not guarantees. "At most 25 words" will be met most of the time, not always. Keep the validator (Topic 3.1) and decide what happens on a miss (trim, retry, accept).
- ▸
Prefer low temperature (0 to 0.3) for extraction and classification, where you want the same answer each time, and higher values for brainstorming. Temperature does not make a model smarter; it changes how much it varies. Even at 0 the same prompt is not guaranteed to give identical text on every call, and some reasoning models fix or ignore the setting, so check your provider's docs.
Remember this
- 1
Why this exists. Topic 3.1 showed that vague prompts give vague output. This topic gives you a checklist of parts so you stop forgetting something. Almost every weak prompt is missing one of five parts, and adding the missing part is the fastest fix there is.
- 2
The five parts. (1) The task: one clear verb (classify, extract, summarise, rewrite, answer). (2) The context: the facts the model needs and cannot guess (the order status, the policy). (3) The audience: who reads the answer, so it picks words and detail. (4) The format: bullet points, one word, JSON, two sentences. (5) The constraints: length, tone, things to leave out.
- 3
Say what to do, not only what to avoid. "Don't be wordy" tells the model one thing it must not do and nothing about what to do. "Use at most 25 words" is something it can aim at. Negative rules are still useful for hard limits ("never promise a delivery date"), but give a positive instruction first and keep "don't" rules few and specific.
- 4
Controlling length and tone. Length: use numbers ("two sentences", "at most 40 words"), not "brief". Tone: name it and give a reader ("warm and calm, for someone who is annoyed"). A model asked to be "professional" and "friendly" with no reader will pick a middle that sounds like an advert.
- 5
Build the prompt from named parts. The example builds the prompt with a function whose arguments are the five parts. Empty parts are skipped. This means every prompt in your product has the same shape, any part can be tested or changed alone, and nobody pastes text together by hand. Topic 3.7 takes this further with templates.
- 6
Context is data, so keep it true. If the context says the parcel is due in 3 days and the model says "tomorrow", the bug is in the model's reading, but if the context was wrong, the bug is yours. Check what you put in. Putting a whole document in when 3 lines would do costs money and distracts the model (Phase 6 and Phase 8).
Explain it without notes
Name the five parts of a clear instruction and say what each one prevents.
Why is "use at most 25 words" a better instruction than "don't be wordy"?
Why build prompts with a function that takes named parts instead of pasting strings together?
Practice
Write build_prompt(task, context, audience) that returns lines Task: ..., Context: ..., Audience: ... joined by newlines, skipping any part that is an empty string.
Write word_limit_ok(reply, limit) and use it to test the prompt "Reply in at most 5 words" against the replies "Late, refund wanted" and "The parcel is late and the customer wants a refund".
Trade-offs
- ↔
More parts make output more predictable but make the prompt longer, which costs tokens on every call.
- ↔
Strict format rules ease parsing but can make answers feel stiff for human readers; choose per feature.
- ↔
Lower temperature gives steadier answers but less variety; for creative tasks the variety is the point.
Done when you can
Done when you can name the five parts of a clear instruction.
Done when you can rewrite a vague request using all five parts.
Done when you can turn a "don't" into a positive instruction and keep only the hard "never" rules.
Done when you can build a prompt from named parts in a function.
Done when you can use the lab goals to judge whether a rewrite helped.