How to write an AI prompt that works

What is the basic structure of a good prompt?

A working prompt has six parts. You do not need all six every time, but you should know which one you are leaving out and why.

1. Role — the expertise the model should apply. Useful when it implies a standard: "a line editor who cuts redundancy", not "a brilliant writer".
2. Context — the background the model has no way of knowing. Source material, your situation, what has already been tried.
3. Task — what to produce, stated as precisely as you can manage.
4. Constraints — the rules the output must follow, including what to avoid.
5. Output format — the shape: markdown, JSON, a table, a word count, a tone.
6. Success criteria — how you will judge it, so the model can check its own work.

Examples sit alongside these rather than inside them, and they are worth more than any of the six individually. If you can show one correct answer, do that before you write another sentence of description.

Does the order of a prompt matter?

Yes, and more than most people expect. Two ordering rules carry most of the benefit, and both work by exploiting how models read a context window rather than by changing what the prompt says.

Put long reference material before the instructions. When a model reads a 2,000-word document and then reads "summarise the above in five bullets", it processes the material already knowing nothing about what is wanted, then receives a clear instruction with the material fresh. Reversing that order — instruction first, then the wall of text — buries the instruction and dilutes it.

Restate the task at the end. Models weight the end of the context heavily, an effect known as recency bias. In a long prompt, an instruction given at the top can be quietly overridden by a casual remark at the bottom. Ending with a single line that restates what to do costs almost nothing and reliably helps.

These two rules are why the same six pieces of information, reordered, produce measurably different output from the same model. The words did not change; what the model attended to did.

How specific does a prompt need to be?

Specific enough that a competent stranger could do the task without asking you a question. That is the practical bar, and it is a useful one because it is checkable.

The most common failure is not vagueness about the topic — people are usually clear about that — but vagueness about the qualities the output should have. Words like "good", "engaging", "professional", "comprehensive" and "detailed" feel like requirements and constrain nothing. A model cannot verify whether it has been engaging. It can verify whether it opened with a concrete detail, stayed under 900 words, and named only UK-available products.

What should you do when you do not know what you want?

Often the honest answer is that the brief is unclear because the thinking is unfinished. Writing a detailed prompt is not possible yet, and pretending otherwise produces a confident answer to the wrong question.

The fix is to add a stop condition — an explicit instruction telling the model to ask before assuming:

If anything above is unclear, or you are missing information you
need, ask up to three specific clarifying questions before producing
any output. Do not invent facts, names, numbers or sources to fill a
gap — if you do not know something, say so.

This single addition changes the failure mode from "confidently wrong output you have to detect" to "a question you can answer". It is the most useful thing you can add to a thin prompt, and it is why this site's compiler adds it automatically when a brief scores as underspecified.

How do you write a prompt you can reuse?

A prompt you will run more than twice should be a template: the structure fixed and tested once, with placeholders for the parts that change.

<role>
You are a support engineer writing replies that resolve the issue
in one message.
</role>

<context>
Product: {{product}}
Customer tier: {{tier}}
Previous contact: {{history}}
</context>

<task>
Reply to the message below.
</task>

<constraints>
- Address every question asked, in the order asked
- Never promise a delivery date that is not in the context
- If you cannot resolve it, say what happens next and when
</constraints>

Name variables for what they mean rather than where they sit, and test that an unreplaced {{placeholder}} never reaches the model — it is a common and trivially detectable bug. More in the prompt templates guide.

What does a complete prompt look like?

Putting all of it together, for a task with real constraints:

<role>
You are a technical writer who explains infrastructure to developers
who have never run production systems.
</role>

<context>
Our team of four is moving from a single server to containers. Nobody
has used Kubernetes. We deploy twice a week and have had two outages
this quarter, both from manual deploy mistakes.
</context>

<task>
Write a 1,200-word explanation of what container orchestration solves
and whether a team our size needs it.
</task>

<constraints>
- Define every term the first time it appears
- Give one concrete example before each general rule
- Say plainly if the honest answer is that we do not need it
- No vendor recommendations
</constraints>

<output_format>
Markdown with descriptive headings. Paragraphs of three sentences or
fewer. Plain British English.
</output_format>

<success_criteria>
- A developer who has never deployed to production could explain the
  trade-off back in their own words
- Every claim is either common knowledge or stated as uncertain
</success_criteria>

Now write the explanation.

Note what is absent: no flattery, no urgency, no "this is very important to my career". Every line either supplies information the model lacked or bounds what it may produce.