The Six-Part Prompt Order That Stops AI From Guessing

You wrote a huge prompt and the model still missed the point. Before you add more words, check the order you put them in. A prompt with all the right information in the wrong sequence reads to the model almost like a prompt with information missing — because the parts that matter most are buried, or arrive before the model even knows what it's being asked to do.

The problem: length isn't the lever

The instinct when a prompt fails is to add more detail. More background, more caveats, more "please make sure to." But a large language model reads a prompt roughly the way you'd skim a long email — it forms an impression from what comes first and what comes last, and treats the middle as supporting detail. If the actual task is buried three paragraphs into a wall of context, the model has already started forming a guess about what you want before it gets there. Reordering the exact same words often fixes what more words could not.

The five-part structure

The order that consistently works, and that's explicitly recommended in modern prompting guidance, is:

1. Task — state what you want done, up front, in one or two sentences.
2. Context — the background the model needs: who this is for, what already exists, what constraints apply.
3. Instructions — the step-by-step "how": format, tone, things to avoid, edge cases to handle.
4. Example(s) — one or two concrete input/output pairs showing the shape of a good answer.
5. Reminder — a closing line that repeats the single most important rule.

Putting the task first isn't a formality — it gives the model a frame to interpret everything that follows. Reading "review this pull request for security issues" before the diff changes how the model reads the diff, compared to reading the diff first and the ask last.

Why labeling the sections matters

Once you've got the five parts, label them so the model can find its way back to any one of them. The simplest way is XML-style tags — <task>, <context>, <instructions>, <example> — wrapped around each section. This isn't cosmetic. A labeled prompt lets the model explicitly reference "per the instructions" or "per the example" partway through its answer, and it gives you a place to point when you're iterating: "expand the <context> section," not "add more stuff near the top."

You don't need real XML — consistent Markdown headers (## Task, ## Context) work almost as well, as long as every prompt in a given workflow uses the same labels every time.

The part models remember best: the ending

The order that opens a prompt gets the model oriented; the line that closes it gets weighted heavily in what the model does next. That's why the fifth part — the reminder — isn't decorative. A single closing sentence that restates the one rule you most need honored ("above all, do not invent API endpoints that aren't in the provided docs") measurably reduces the odds that rule gets dropped, especially in longer prompts where an instruction stated only once near the top can get diluted by everything that comes after it.

How to run it

Before sending a prompt, check it against the order, not just the content:

• Does the task appear in the first sentence or two?
• Is the context — the stuff that won't change between similar requests — clearly separated from the one-off instructions?
• Is there at least one example, even a short one, for anything where format or tone matters?
• Does the last line repeat the single rule you most need followed?

If info is stable across many requests — your team's coding conventions, your brand voice, a recurring dataset schema — that's a signal it belongs at the top of the context section (or even in a system prompt / project instructions file), not re-typed into every individual task.

Power tricks

• Test with the order alone. If a prompt keeps failing, try reordering it before rewriting the content — you'll often find the words were fine.
• One reminder, not five. Repeating everything at the end just recreates the wall of text you were trying to avoid — pick the single most important rule.
• Stable info goes in the system prompt. Anything unchanging across requests belongs up top, not retyped into every task.

Where this pays off

The same five-part order works whether you're grading a batch of essays, reviewing a submitted form, or asking for code from a spec. The content of each section changes; the order that gets read correctly does not.