What you'll learn
- The parts a good prompt is built from: task, context, constraints, format
- Why vague prompts reliably produce generic output, and how to fix that
- Why positive instructions work better than negative ones
- When supplying a persona genuinely helps and when it is decoration
- How to choose examples that demonstrate what you want
- Decomposition: why one big request usually works worse than several smaller ones
- Treating the first reply as a draft, and iterating deliberately rather than randomly
Key terms and definitions
| Term | Meaning |
|---|---|
| Task | The thing you want done, stated as an instruction |
| Context | The background and source material the model needs in order to do it |
| Constraint | A limit on the output: length, register, what to include or avoid |
| Format specification | Saying what shape the answer should take — a table, bullet points, a paragraph |
| Persona | Telling the model to answer as a particular kind of person or role |
| Few-shot prompting | Supplying a small number of worked examples of the output you want |
| Zero-shot prompting | Asking without examples |
| Decomposition | Splitting a large request into smaller steps handled one at a time |
| Iteration | Improving output by refining the prompt, rather than accepting the first reply |
Core concepts
Why vague prompts give generic answers
"Write me an essay about climate change" produces something bland. This is not laziness on the model's part — it is the predictable result of an underspecified request.
The model produces a likely continuation of what you gave it. If your prompt is the kind of thing that could precede a thousand different acceptable answers, you get the average of them: broad, safe, uncommitted. Narrow the prompt and you narrow the range of likely continuations.
Compare:
Write me an essay about climate change.
Write three paragraphs for a GCSE Geography answer explaining how rising sea levels affect small island states. Use the terms thermal expansion and storm surge. Do not discuss causes of warming — the question is only about effects.
The second has a task, an audience, a scope, required terminology and an exclusion. There are far fewer plausible continuations, and they are all closer to what was wanted.
The four parts of a workable prompt
Most weak prompts are missing one of these:
Task — what to do, as a verb. Explain. Summarise. Compare. Draft. Check. "Tell me about X" is not a task; it is a topic.
Context — what the model needs to know, including the source material. If the answer depends on a document, supply the document rather than hoping for recall.
Constraints — length, register, audience, what to leave out. "Two paragraphs for a non-specialist reader, no jargon" rules out a great deal.
Format — the shape of the output. A table with named columns, five bullet points, a paragraph of continuous prose. Say which.
You do not need all four every time. You do need to notice which one is missing when the output disappoints.
Positive instructions beat negative ones
"Don't be verbose" works less reliably than "answer in two sentences". "Avoid being too formal" works less reliably than "write as you would to a friend".
The reason follows from the mechanism. A negative instruction describes a large space of things not to do without indicating what to do instead, and it also puts the unwanted idea into the context — where it affects what follows. A positive instruction names a target directly.
So where you can, convert:
| Instead of | Write |
|---|---|
| Don't use long words | Use everyday vocabulary a 12-year-old would know |
| Don't make it too long | Write at most 150 words |
| Don't just list things | Write continuous prose with no bullet points |
| Don't be vague | Give a specific example for each claim |
Personas: useful sometimes, decoration often
"You are an expert physicist" is extremely common advice. It sometimes helps, for a narrow reason: it shifts the likely continuation towards text of the kind experts write — more technical vocabulary, more caution, more structure.
What it does not do is give the model knowledge it lacks or make it more accurate. A persona cannot add information that was never in the training data, and a confident expert voice on a thin topic is worse than a hesitant one, because it strips away the only clue you had.
A persona earns its place when the register matters: "explain this as a primary school teacher would" genuinely changes the output usefully. It is decoration when used as a reliability charm.
Examples do more than descriptions
If the output has a particular shape, showing two or three examples usually beats describing it. The reason is direct: the model continues the pattern in its context, and examples are that pattern, stated unambiguously.
Choosing examples well matters:
- Make them cover the variety you expect, not three near-identical cases
- Include a hard case if there is one, so the pattern covers it
- Keep the formatting identical across examples, since that formatting is part of what is being demonstrated
- Two or three is usually enough; a dozen fills the context without adding much
Decomposition: smaller requests, better results
A single prompt asking for research, analysis, structure and polished prose asks for a long chain of dependent steps — and errors early in a chain contaminate everything after.
Breaking it up gives you checkpoints:
- "List the main arguments on each side of this question."
- (check the list; correct it)
- "Using this list, draft an outline with one paragraph per argument."
- (check the outline)
- "Expand the third section into a paragraph."
Each stage is inspectable, and a mistake is caught before it is built upon. The finished work is also more yours, because you made the structural decisions.
Useful moves beyond the basics
- Ask for several options. "Give three different opening sentences" is often more useful than one, because choosing between candidates is easier than judging a single offering.
- Ask it to ask you. "What do you need to know before drafting this?" surfaces the ambiguities in your own request.
- Say what to do when it does not know. "If you are not confident about a figure, say so rather than estimating" will not make it reliable, but it makes an unsupported answer slightly likelier to be flagged.
- Put the task near the start. A request buried in the middle of a long paste is easier to lose than one stated up front.
- Ask for the reasoning when you intend to check it, and read the early steps first.
Iterate deliberately
The first reply is a draft. Rather than regenerating and hoping, identify what is wrong and change that:
- Output too general → add constraints and a specific audience
- Wrong shape → specify the format, or show an example
- Missing something → name what was missing and ask for a revision
- Right content, wrong register → specify the reader
- Confident but unsupported → supply the source material instead of relying on recall
One thing to avoid: do not reveal the answer you are hoping for while you iterate. "Make it support my argument that X" will get you text supporting X whether or not X is defensible.
Worked examples
Example 1: Improving a prompt (4 marks)
A student writes: "Tell me about the French Revolution." The answer is long and generic. Rewrite the prompt and explain each change.
- Give a task verb and a scope: "Explain the three main causes of the French Revolution" (1 mark)
- Add an audience or level: "for a GCSE History answer" (1 mark)
- Add constraints: a word limit, and required terminology (1 mark)
- Specify the format: "one paragraph per cause" — all of which narrows the range of likely continuations (1 mark)
Example 2: Diagnosing a persona (3 marks)
A user adds "You are a world-leading cardiologist" before a medical question and treats the answer as more reliable. Explain the error.
- The persona shifts the style of the output towards the way specialists write (1 mark)
- It cannot add knowledge the model does not have, so accuracy is unchanged (1 mark)
- It is actively unhelpful here, because a more confident tone removes the hesitancy that might have warned the user (1 mark)
Example 3: Choosing decomposition (4 marks)
Explain why asking for an outline first, then expanding each section, is usually better than asking for the finished essay in one prompt.
- A single request chains research, structure and prose, so an early error affects everything after it (1 mark)
- Stopping after the outline creates a checkpoint where that error can be caught cheaply (1 mark)
- The structural decisions remain the user's rather than the model's (1 mark)
- Each smaller output is also easier to check than one long piece (1 mark)
Common mistakes and how to avoid them
- Giving a topic instead of a task. Start with a verb.
- Expecting recall instead of supplying the source. If it matters, paste it in.
- Writing instructions as prohibitions. Name the target, not the thing to avoid.
- Using a persona as a reliability charm. It changes register, not knowledge.
- Asking for everything in one prompt. Decompose and check between stages.
- Regenerating instead of diagnosing. Identify what was wrong and change that.
- Revealing the answer you want. You will be shown it, deserved or not.
- Describing a format you could demonstrate. Two examples beat a paragraph of description.
Using this in practice
A reliable routine for anything that matters:
- State the task as a verb, and put it first.
- Supply the source material rather than relying on recall.
- Add constraints: length, audience, register, exclusions.
- Specify or demonstrate the format.
- Ask for one stage at a time, checking between stages.
- Diagnose, then iterate — change the thing that was wrong.
- Keep your preferred conclusion out of it until you have an honest answer.
Quick revision summary
- Vague prompts give generic answers because a vague prompt has many plausible continuations — narrowing the prompt narrows the output
- Build from task, context, constraints, format, and notice which is missing when output disappoints
- Positive instructions outperform negative ones: name the target rather than the thing to avoid
- A persona changes register, not knowledge, and a confident voice on a thin topic hides your only warning sign
- Examples demonstrate a format more reliably than a description; two or three that cover the variety
- Decompose large requests so errors are caught at checkpoints instead of compounding
- Treat the first reply as a draft and iterate by diagnosis, never by revealing the conclusion you want