Anatomy of a Great Prompt

Last lesson covered how much to show the model (zero-shot vs few-shot). This one covers how to structure what you write — the anatomy of a great prompt.

Here's the core truth of prompt engineering: the model is only as clear as your instructions. A vague prompt produces vague, generic output; a well-structured prompt produces reliable, on-target output — from the same model. And great prompts aren't magic incantations; they're built from a small set of components, assembled deliberately.

This lesson gives you that skeleton — the six building blocks every strong prompt draws from. Think of it as the map for the rest of this section: each block here gets its own deep-dive lesson next (roles, clear instructions, delimiters, examples).

You'll learn:

• Why vague in → vague out (and the fix)
• The six components of a great prompt and what each does
• A before/after that shows the difference
• When you don't need all six, and why order matters

Watch what an under-specified prompt produces:

Prompt:  "Write about dogs."
Output:  A generic, rambling paragraph — no clear audience, length,
         angle, or purpose. Technically 'correct,' practically useless.

The model didn't fail — you didn't tell it enough to succeed. It had to guess the audience, the length, the tone, the goal — and it guessed blandly, because the most plausible continuation of a vague prompt is a vague, average answer (recall: models optimize plausibility).

The fix isn't a magic phrase — it's structure. Give the model the same information you'd give a competent new freelancer, organized clearly, and the output transforms. That structure has a recognizable anatomy.

Almost every excellent prompt is assembled from these six components. You won't always use all of them — but knowing the full toolkit means you can diagnose what's missing whenever output disappoints:

1. Role — who should the model be? A persona/expertise lens ("a senior data analyst"). → deep-dive next lesson.
2. Task — what exactly should it do? A clear action verb + deliverable ("summarize," "classify," "draft"). → its own lesson on clear instructions.
3. Context — what's the situation? Background, audience, and the input data to work on.
4. Examples — show, don't just tell. One or a few demonstrations (few-shot, from last lesson). → its own lesson.
5. Format — how should the output look? Structure, length, tone, or a strict schema (e.g. JSON).
6. Constraints — what are the rules? What to avoid, boundaries, and how to handle uncertainty ("if unsure, say NEEDS_INFO" — your anti-hallucination guardrail).

Here's the skeleton at a glance:

Take a real task — triaging a support ticket — and watch the six blocks turn a guess into a contract:

Before (vague):

What's wrong with this ticket and how bad is it? <ticket text>

After (structured):

You are a senior support analyst.                         ← ROLE
Summarize the customer's issue and assign a priority.     ← TASK
The audience is an on-call engineer who needs to act fast. ← CONTEXT
<ticket>
{the ticket text}
</ticket>                                                 ← CONTEXT (input, delimited)
Return JSON: {"summary": string, "priority": "P0"|"P1"|"P2"} ← FORMAT
Base priority only on the ticket; if severity is unclear,
output "priority": "UNKNOWN" rather than guessing.         ← CONSTRAINTS

The second prompt leaves almost nothing to chance: the model knows who to be, what to produce, for whom, in what shape, and what to do when unsure. Same model, dramatically more reliable, machine-parseable output. (We dropped EXAMPLES here because the task is simple — which brings up an important point.)

The six blocks are a palette, not a checklist. Over-stuffing a simple prompt wastes tokens and can even confuse the model. Calibrate to the task:

• Quick / one-off (a casual question, a brainstorm): often just a clear Task — maybe a Format hint. Don't bother with a role and constraints.
• Production / repeated (anything an app calls thousands of times): use more — Role + Task + Context + Format + Constraints, and add Examples if the model keeps getting the format or edge cases wrong.
• High-stakes / structured output: definitely Format (a schema) and Constraints (uncertainty handling, validation rules).

The practical workflow: start minimal, then add the block that fixes whatever's wrong. Output too generic? Add a Role and Context. Wrong shape? Add Format. Inconsistent on tricky inputs? Add Examples. Each block is a tool for a specific failure.

How you arrange the blocks affects results — and it echoes the long-context lesson (models weight the start and end most):

• Lead with role and instructions so the model knows its job before it reads the data.
• Clearly separate the input data from your instructions — wrap it in delimiters or XML tags (<ticket>…</ticket>) so the model never confuses content to process with commands to follow. (Its own lesson soon — it's one of the highest-impact habits.)
• Put the format/output spec near the end, where recency makes the model more likely to honor it.

A messy wall of text where instructions, data, and examples blur together is a top cause of 'the model ignored my instructions.' Clean structure isn't cosmetic — it's how the model tells your commands apart from your content.

This lesson is the map; the rest of the section is the territory. The habits that move the needle most — each its own upcoming lesson — are:

• Assign a specific role (not just 'an expert' → 'a senior tax attorney'). (next lesson + the roles lesson)
• Write clear, explicit instructions — say exactly what you want, leave nothing implied. (its own lesson)
• Use delimiters / XML tags to structure the prompt and isolate data. (its own lesson)
• Show examples instead of writing ever-longer instructions. (few-shot lesson)
• Ask for reasoning/evidence before the final answer for complex tasks (we'll meet chain-of-thought prompting later).

Master the anatomy here, and those lessons become refinements of blocks you already understand — not new ideas.

Build it block by block. Take a vague prompt you've used ('write about our product') and add the six blocks one at a time: Role → Task → Context → Examples → Format → Constraints. After each, note the change. Which block improved the output the most? → For most tasks it's Format + Constraints (they remove the guesswork your code depends on). You rarely need all six — add the one that fixes the failure you see.

• "Great prompts are secret magic words." No — they're structured information. The skeleton (role, task, context, examples, format, constraints) is the whole 'secret.'
• "Longer prompts are better." No — clearer and better-structured is better. Add a block to fix a problem, not for its own sake.
• "The model understood; it just chose to ignore me." Usually it couldn't tell your instruction from your data — structure and delimiters fix that.
• "I always need all six components." No — it's a palette. Simple tasks need one or two; complex/production prompts need more.
• "Order doesn't matter." It does — lead with instructions, delimit the data, put format near the end.

• Prompt quality is mostly structure, not magic: vague in → vague out; structured in → reliable out.
• The anatomy has six building blocks: Role, Task, Context, Examples, Format, Constraints — each answering a clear question the model would otherwise have to guess.
• It's a palette, not a checklist — start minimal and add the block that fixes the failure you see.
• Order/structure matter: instructions first, delimit the input data, format near the end.
• The section's deep-dives (roles, clear instructions, delimiters/XML, few-shot) are just refinements of these blocks.

Next: we zoom into the first structural tool — the system, user, and assistant roles — and how using them correctly shapes the model's behavior and persona.