Write a structured description
What you'll learn
A good prompt names four things: who you want the model to be, what to do, what rules to follow, and exactly what shape the output should take. Add a worked example.
- Structured description = role + task + constraints + format. All four, named explicitly.
- One worked example beats three sentences of constraints.
- Diagnostic: a junior with the prompt and no context should know exactly what to produce.
A 'description' in the 4D framework is the prompt itself. A *structured* description names four things explicitly: role (who the model is acting as), task (what to do), constraints (what to honour or avoid), and format (the exact output shape). Skipping any of the four shifts work onto the model's guessing — sometimes it guesses right, often it doesn't, and the inconsistency is what's expensive in production.
Role gives the model a frame for tone, depth, and audience. 'You are a senior compiler engineer' produces different defaults than 'You are explaining to a high-school student.' Task names the verb and the object: 'Summarise this transcript into 5 bullet action items, attributed to speaker.' Constraints encode what would otherwise be implicit: 'Do not invent action items; if a section has none, write "none."' Format is the contract with whatever consumes the output: prose, JSON shape, table columns, length cap.
Examples are an underrated component of structured description. One worked example does more than three constraint sentences. Show the model the input → output transformation once and it pattern-matches. This is the entire point of few-shot prompting — examples are description, not decoration.
The diagnostic question for any prompt: if a new junior teammate read this prompt with no context, would they know exactly what to produce? If no, the description is incomplete. The model isn't psychic; under-specification is silently filled in with priors that may or may not match what you wanted.
Key points
- Structured description = role + task + constraints + format. All four, named explicitly.
- One worked example beats three sentences of constraints.
- Diagnostic: a junior with the prompt and no context should know exactly what to produce.
- Under-specification is silently filled by the model's priors — not a feature.
Examples
Role: unset (default conversational). Task: 'summarise.' Constraints: none. Format: open. Output: highly variable across runs.
Role: 'You are a meeting note-taker for an engineering team.' Task: 'Summarise the transcript into action items.' Constraints: 'Each action item must be attributed to a speaker. Do not invent action items; sections without any explicit commitment should be omitted.' Format: 'Markdown bullet list, one bullet per item, format: `- [Speaker]: action`.' Then one worked example.
Pitfalls
- Naming role and task but skipping format — the consumer of the output gets inconsistent shape.
- Stuffing constraints in but never giving an example. Examples > more constraints.
- Writing the constraint as 'be helpful' or 'be careful' — not actionable. Constraints must be checkable.
Source notes: 00-academy-basics/notes/02-ai-fluency.md
Ask Claude
Build a prompt with this lesson + your question, copy it, and open the Claude Project in a new tab.