Anatomy of a Prompt
Role, instruction, context, input data, output format — the five working parts of a prompt, and why their order changes behavior.
Most production prompts decompose into five parts. Role: who the model is and who it's writing for. Instruction: the task, and what 'done' means. Context: background the model needs — product facts, house style, prior decisions. Input data: the specific thing to process, clearly delimited. Output format: the exact shape of the response, ideally with an example. Few prompts need all five, but naming them changes how you debug. A prompt stops being a blob of text and becomes a machine with parts — and when output goes wrong, you can ask which part failed instead of rewriting the whole thing blind.
Each part fails differently. Wrong tone or audience? Role problem. The model did the wrong task, or the right task to the wrong standard? Instruction problem. Confidently wrong claims about your product? Missing context. The model obeying instructions buried inside a pasted email? Delimiter problem — wrap input data in tags like <email>...</email> so content can't masquerade as commands. Output that's correct but unparseable? Format-contract problem. This diagnostic habit is the fastest upgrade most people can make: surgical fixes to the failing part, instead of superstitious rewrites of everything at once.
Order matters more than it should. Models attend most reliably to the beginning and end of a prompt; material in the middle of a long context gets less weight — the 'lost in the middle' effect. So lead with role and instruction, put long context and input data in the body, and restate the critical output constraint at the end, right where generation begins. For long prompts that end-restatement is one of the cheapest reliability wins available. There's an economic reason for disciplined ordering too: prompt caching bills a repeated prefix at a fraction of the normal rate, so structure prompts static-first — role, instructions, examples — with the per-request input last.
A worked shape to internalize: role and goal in two sentences, then instructions as a short list, then context in a labeled block, then <input> tags around the data, then the format contract with a one-line example, then a final reminder of the one constraint that must not break. This ordering isn't sacred — but every deviation should be a decision, not an accident. The rest of Module 1 sharpens each part in turn.