Prompt Engineering· Lesson 1 of 7
- 1Anatomy of a Prompt — What It's Made Of6 min
- 2Few-Shot — Teach by Example7 min
- 3Structured Output — Make It Return JSON7 min
- 4Chain of Thought — Let It Reason Step by Step8 min
- 5Prompt Iteration — Improving It in Passes6 min
- 6Role & Persona — Tell It Who to Be7 min
- 7Prompt Injection Basics — When Input Turns Against You8 min
Anatomy of a Prompt — What It's Made Of
In one line · A good prompt is built from clear parts: the task, the context, the constraints, and the shape you want the answer in.
If your prompt is one lumped-together line, you can't change one thing without breaking another. Separating the parts lets you tune each one on its own.
Like handing work to a colleague: you say what you need, give the info required, set the do-nots, and say how to hand it back. The model is exactly the same.
Think of it as a work ticket: title, description, acceptance criteria. The model performs better when the ticket is well-organized.
'Summarize this text (task) for non-technical customers (context) in at most 3 points (constraint) as bullet points (format)' — each part stands clear on its own.
The model reads the whole prompt as one continuous text, so jumbled parts get weighted wrong. When you separate task, context, constraints, and format with headings or clear delimiters (like --- or XML tags), every sentence has an obvious job — and you can tweak one part while debugging without touching the rest. Practical rule: instructions first, the data the model works on last, inside delimiters.
🧪 Try it yourself: take a long prompt from your own work (or the linked exercise) and label its four parts: task, context, constraints, format. A missing part is usually why replies come back messy — fill it in, run both versions, and compare.
- Mixing the data the model should work on into the instruction text with no delimiters, so 'data' and 'commands' blur together.
- Assuming constraints without writing them ('obviously I want it short') — what isn't in the prompt doesn't exist.
- Describing the format vaguely ('make it neat') instead of showing a concrete example of the shape you want.
Any prompt that goes into code or gets reused, and any prompt past 3-4 lines — the structure saves you debugging hours later.
A quick one-off chat question — formal structure there is overhead with no payoff. Just ask.