What a prompt is actually made of
A prompt is not a sentence you write once. It is an assembled document with parts that do different jobs, and knowing which part carries which job is the difference between fixing a problem and rewording it.
TL;DR: Every prompt is assembled from five parts that do different jobs: the role and rules, the task, the context, the examples, and the output contract. Most prompting problems are one part missing or one part doing another part's job. Learn to see the parts and you stop rewriting sentences and start fixing structure.
Where you are. Module 2 covered what the model does with what you send. What to send is the subject of this module. It opens here because the single most common beginner mistake is treating a prompt as a sentence rather than as a document with structure, and that misconception makes every later problem harder to diagnose.
Roles: who is speaking
Model APIs take a list of messages, each tagged with a role. The tags matter more than they look.
System is the standing instruction: who the model is acting as, what the rules are, what it must never do. It applies for the whole conversation.
User is the request. In a chat product this is genuinely the person's words. In a feature you built it is whatever your code assembled.
Assistant is the model's own previous turns, sent back so it can see what it already said.
The distinction is not cosmetic. Instructions in the system role are weighted more heavily and are harder to talk the model out of, which matters the moment user-supplied text enters the picture.
That leads to the rule worth learning now, before it costs you: never build a prompt by pasting user text into the same string as your instructions. Keep your instructions in the system role and the user's content in the user role, and treat everything in the user role as untrusted. Text from a person, a document, or a web page can contain its own instructions, and a system that glues everything into one string has no way to tell the difference.
The five parts
Inside those roles, a working prompt has five parts. They are not always labelled, and every one of them is present in any prompt that works.
1. Role and rules. Standing constraints. "You are reviewing support tickets. Never guess a customer's account number. If the ticket does not say, leave the field empty."
2. The task. One instruction, stated plainly. If you cannot express it in a sentence, you have two tasks and you will get better results from two calls.
3. Context. The material the answer must come from: the ticket, the retrieved passages, the conversation so far. This is the part that grows, and the part module 4 is about.
4. Examples. One to three worked cases. Usually the highest-value part per token spent, and covered in the third lesson of this module.
5. Output contract. The exact shape you require. Not "return JSON" but the field names, the types, the permitted values, and what to emit when there is no answer.
The diagnostic that saves you time
When output is wrong, the instinct is to reword. That is guessing. Instead, ask which part failed:
| Symptom | Missing part |
|---|---|
| Ignores a constraint it followed yesterday | Rules buried in the user role instead of system |
| Answers a slightly different question | Task states two things, or states one vaguely |
| Invents facts | Context is absent, thin, or does not actually contain the answer |
| Right content, unusable shape | No output contract, or one stated in prose |
| Right shape, wrong style or depth | No examples |
This turns "the prompt is not working" into a specific, testable question. It is the single most useful habit in this module, and it is why the parts are worth memorising.
What to do when it still fails
Two moves, in order.
Split it. A prompt asking for extraction, classification, and a summary at once will do all three adequately and none well. Separate calls each do one job, and each becomes independently testable and fixable. The cost is another model call, which is real; the benefit is usually larger.
Move the work out of the prompt. If a rule can be enforced in code, enforce it in code. Do not ask the model to return one of five statuses and hope. Ask it, then validate against the five in your own code and handle the miss. Prompting is not the last line of defence, and the next lesson is about what is.
Do this before moving on
Take any prompt you have written or found, and label its five parts. Mark which are present, which are implied, and which are missing.
Then find where the user-supplied content sits. If it is in the same string as your instructions, rewrite it so instructions are in the system role and the content is in the user role. That change takes two minutes and closes the most common security hole in these systems.
Go deeper
- Prompt engineering is the reference for the levers themselves and why prompting is a first resort rather than a last one.
- Prompt injection is the attack the roles rule defends against, and it is worth reading now rather than after you have built something.
- Context engineering is part 3 taken seriously as its own discipline, and the bridge into module 4.
- Practice question: How do you chain prompts and parse their outputs reliably? is the "split it" move as a design question.
- Practice question: How do you defend an agent against prompt injection? is where the roles rule becomes a real architecture problem. Harder than it looks, and a common senior probe.
Key takeaways
- A prompt is an assembled document with five parts: role and rules, task, context, examples, output contract.
- Diagnose by asking which part failed, rather than rewording and hoping.
- Instructions belong in the system role, user and document text in the user role, and everything in the user role is untrusted.
- If a rule can be enforced in code, enforce it in code. One prompt should do one job.
Check yourself before an interviewer does. Answer from memory first.
A model returns the right information in an unusable shape. Which part of the prompt is at fault?