Anatomy of a Prompt: Role, Instruction, Context, Examples & Format

Think about how you brief a junior teammate on their first day. You don't just say "handle the customer emails". You say who they are in this context, what exactly to do, what information they may use, show them one email you already handled well, and tell them what the reply should look like when it's done.

That briefing has five parts. So does a good prompt — and once you can see the five, a bad prompt stops being mysterious. You can point at the missing slot.

The five slots

Read that diagram as a checklist rather than a template. You are not obliged to fill every slot every time — but every slot you leave empty is a decision the model will make for you, and it will make it differently on Tuesday than it did on Monday.

1. Instruction — the only compulsory one

The instruction says what to do. It is the one slot you cannot skip, and the one people write worst, because they write an adjective where a verb and an object belong.

Notice what the strong column shares: an action verb, a specific object, and — in two cases — an explicit boundary on what not to touch. One prompt, one job. If your instruction contains "and also" twice, you probably want two calls (lesson 7 makes this a pattern).

2. Context — the facts it may use

Context is the background the model cannot know: your data, your situation, your constraints. This is the slot that decides whether the answer is about you or about the average case.

Suggest a laptop.

Suggest a laptop.

Context:
- Budget: under ₹60,000
- Use: B.Tech CSE — VS Code, Docker, occasional VMs
- Travels by train weekly, so weight and battery matter
- Already owns an external monitor, so screen size is not critical

There is a second, quieter use of this slot that matters far more in production: context is also a fence. "Answer only from the information above; if it is not stated, say so" turns the context block into the boundary of what the model is allowed to claim. That single sentence is the backbone of every RAG system.

3. Role — who is speaking

"You are a patient teacher explaining to a first-year student." "You are a code reviewer who is strict about naming." A role sets vocabulary, depth, and what the answer assumes the reader already knows.

Be clear-eyed about what it does not do: a role changes register, not knowledge. "You are a senior cardiologist" does not give the model medical facts it lacks; it makes it sound like one, which is arguably worse. This is a favourite interview trap.

💡 The most useful roles in practice describe the reader, not the speaker. "Explain to someone who has never used a terminal" changes the answer far more reliably than "You are an expert".

4. Examples — what good looks like

Some things are quicker to show than to describe. Tone is one. Formatting is another. Your own labelling conventions are a third — try writing a paragraph that fully defines what your team means by "P1 bug", then notice how two examples do it in a line each.

Classify each support ticket as P1, P2 or P3.

Ticket: "Payment failed but money was debited"  -> P1
Ticket: "The dashboard chart colours look odd"  -> P3

Ticket: "Cannot log in since this morning"      ->

Lesson 3 is entirely about this slot — how many examples, how to pick them, and the mistake that makes examples backfire.

5. Format — the shape of the answer

The format slot is the difference between output you read and output your program can use. "Return a markdown table with columns Name, Score, Reason." "Return JSON only, no prose." "Answer in at most 3 bullets, each under 20 words."

Anything countable is a gift here, because it is checkable — by you, and by an automated test. Lesson 5 goes deep on getting machine-usable output every single time.

Wait — do I always need all five?

No, and over-filling has real costs: more tokens, more money, more chances to contradict yourself, and — if you stuff in a persona and three examples for a task that needed neither — a longer prompt that performs no better.

A practical rule of thumb:

🎯 Selection-round radar: "What are the components of a good prompt?" is a near-guaranteed question in service-company rounds. Name the five, then add the sentence that shows judgement: "— and I'd only fill the slots the task needs; a persona on a JSON extraction task is wasted tokens."

Putting it together

You are an experienced customer-support lead at an Indian
e-commerce company.                                  <- ROLE

Write a reply to the customer message below.          <- INSTRUCTION

Facts you may use (use nothing else):                 <- CONTEXT
  Order ORD10024, placed 2 Sep, marked "in transit",
  promised delivery 5 Sep, currently 3 days late.
  Policy: refund available after 7 days' delay.

Style reference — a reply we were happy with:         <- EXAMPLES
  "Hi Rahul, you're right — that's later than we promised.
   Your order is at the Nagpur hub and should reach you by
   Friday. If it doesn't, reply here and I'll process the
   refund myself."

Format: 3-5 sentences, no bullet points, end with one    <- FORMAT
concrete next step. Do not invent dates or amounts.

Customer message: {{message}}

Long? Yes. But every line removes a decision the model would otherwise improvise — and this prompt runs a thousand times a day, so it's written once and reviewed like code.

Common mistakes

• Writing an adjective ("make it good") where a verb and an object belong.
• Assuming the model knows your project, your data or last week's conversation.
• Believing a role grants knowledge — it grants a register.
• Bundling three jobs into one instruction, then wondering which part failed.
• Describing a format in prose ("nicely structured") instead of specifying it.
• Filling all five slots on a task that needed two.

Quick recap

Practice Zone — PYQs from real selection rounds

Six MCQs, then two prompts to rebuild slot by slot.

Q1Prompt anatomyeasy

Which five parts make up a well-structured production prompt?

Asked in

aGreeting, question, thanks, signature, datebRole, task, context, constraints, output formatcTitle, body, footerdTemperature, top-p, max tokens, model, seed

Q2Prompt anatomymedium

Why use delimiters (triple quotes, XML-style tags) around user-supplied text?

Asked in

aThey make the prompt look professionalbThey separate instructions from data, so the model knows which is which — and they're the first line of defence against injected instructions inside the datacThey reduce token countdThey're required by the API

Q3Prompt anatomymedium

What is an 'escape hatch' in a prompt, and why does it matter?

Asked in

aA way to cancel the API requestbExplicit permission to say "I don't know" or to refuse — which prevents the model inventing an answer when the context doesn't contain onecA fallback to a smaller modeldA retry mechanism

Q4Prompt anatomymedium

Where should the most important instruction go in a long prompt?

Asked in

aBuried in the middle, so it feels naturalbNear the beginning and, for critical rules, restated near the end — models attend less reliably to the middle of very long contextscIt doesn't matter at alldOnly at the very end

Q5Prompt anatomymedium

Which instruction style generally works better?

Asked in

a"Don't be vague, don't be too long, don't use jargon"b"Answer in 3 bullet points, max 15 words each, in plain English"cThey perform identicallydNegative instructions are always better

Q6Prompt anatomyhard

You must handle a case where the input is missing a required field. Best approach?

Asked in

aHope the model handles it sensiblybSpecify the behaviour explicitly in the constraints — e.g. 'if the date is missing, set date to null; never guess a date'cAdd more examples of complete inputsdIncrease temperature so it improvises

Hands-on tasks:

FAQ

Next lesson: the examples slot, in depth — how many, how to pick them, and when they hurt — Lesson 3: Zero-shot, One-shot & Few-shot →