Prompts as Specifications
By the end of this module
- Name the four parts of a prompt and what each one is for
- Predict which part is missing from a prompt that answers badly
- Explain why a vague prompt produces answers that vary more
Definition
The previous module ended on a single point: the prompt is the only ground the model has. A prompt is therefore not a question. It is the complete specification of a job, and anything left out of it is filled in from the general case rather than from your situation.
This is the part of the work that transfers to people who do not write software, because it is not programming. It is the same skill as briefing a capable contractor who has never seen your company, cannot ask you a follow-up question, and will confidently do something reasonable if you leave a gap.
The Four Parts
Nearly every prompt that works is carrying these four things, whether or not its author separated them out.
| Part | What it does | What happens without it |
|---|---|---|
| Instruction | States the task and the role, including what the model must not do. | The model infers a task from the shape of the input, and often picks a nearby one. |
| Context | Supplies the facts the answer depends on: the record, the policy, the history. | Missing facts are replaced with the statistically ordinary case, fluently. |
| Examples | Shows the judgement you want on cases that are hard to describe in rules. | Edge cases are handled by the model's default taste rather than yours. |
| Format | Fixes the shape of the output: length, structure, and what must not appear. | The shape varies per call, which is what breaks anything downstream that parses it. |
An Underspecified Prompt
Below is a thin prompt. Generate from it several times. The temperature is fixed, so the only thing producing the spread is the prompt itself.
You are a helpful customer support assistant.
Write a reply to this customer: My payouts have been failing for 3 days.
Nothing generated yet.
Generate three or four times and compare. Each reply is competent, and they disagree with each other about the refund, the timeline and who follows up.
Every one of those replies is well written. That is the problem. They commit to different timelines, invent different internal processes, and make different promises on your behalf. If three customers got three of these, you would have three different policies.
A Specified Prompt
Same model, same temperature, same customer. The difference is that the job is now described.
You are a support agent for a payments company. Never promise a refund, a credit or a specific resolution time. Never invent a case number. If the cause is unknown, say so.
Write a reply to this customer: My payouts have been failing for 3 days. Context: payouts to this merchant failed on 14, 15 and 16 October. Cause is an expired bank mandate on the merchant's side. They must re-authorise it in Settings. Support cannot do it for them. Format: under 90 words. Acknowledge, state the cause, give the one action they must take. No sign-off block.
Nothing generated yet.
Generate several times. The wording still changes, because sampling has not gone away. What the reply commits to does not.
The variation did not disappear. It stopped mattering. Each run words the sentence differently and all of them say the same thing, because the parts that must not vary were specified and the only freedom left is phrasing. This is what good prompting buys: not determinism, but variance confined to the parts where variance is harmless.
A model keeps answering in a friendly paragraph when the team needed three bullet points. Which part of the prompt is missing?
Discussion
Take a prompt someone on the team actually uses. Read it out and have the room name which of the four parts are present. In most cases the instruction is there, the format is implied, and the context is assumed to be obvious.