The Four Parts of a Prompt

Context, requirements, constraints, and acceptance criteria. Miss one, and it goes off the rails on that one.

The previous article said "say what needs to be said clearly." This one turns that into a checklist you can go through line by line: context, requirements, constraints, acceptance criteria. Most of prompt engineering is getting these four kinds of information arranged properly. prompt-eng-wiki

Symptoms you'll recognize:

• The prompt is long but results are still unstable, and you don't know what to change.
• It answers well, but the format differs every time, so your code can't consume the output.
• It takes liberties where you said nothing, and even invents a few numbers.

The four parts

Context — who is this for, and in what situation. The user, the product, where the output appears, what came before. This part gets skipped most often because the writer has all of it in their head and assumes it's common sense. But the model is a new colleague who knows nothing about you. Without context, you get content so generic it works anywhere and is useless everywhere.

Requirements — what you want it to produce. Be specific with verbs. "Analyze this" is vague; "list three possible causes, each with a one-line basis" is concrete. If the task has steps, write the steps. Without them, it picks the interpretation it thinks you want — usually the most common one, which may not be yours.

Constraints — what's off-limits, where the boundary is. This is the highest value-to-effort part and the most skipped. "Don't fabricate data; say you don't know when you have no basis." "Don't name competitors." "No exclamation marks." "Use only the provided material."

Why do negative instructions work so well? The model narrows possibilities, and eliminating an entire class of writing narrows faster than describing what you want. One "don't write like marketing copy" beats three pleas to "be professional and restrained." Without constraints, it improvises — and where evidence is missing, it fills in the most plausible-sounding content, in the same confident tone as the truth.

Acceptance criteria — what counts as done. How many items, how long each, what format, numbering or not, JSON or not. This determines whether your program can reliably consume the output. Without it, the format wanders and your code grows compatibility hacks. There are dedicated techniques for format control, but they all presuppose that you said what you want in the prompt.

A real example

Watch the same task written two ways.

Before: "Help me summarize these user feedback messages." You get a serviceable summary. It might be fine — but the structure changes each time, and you have no idea which dimensions it grouped by.

After:

Context — these are 200 tickets our B2B SaaS product received last week, mostly from admin staff at small and mid-sized companies. Requirements — group by issue type, list the five most frequent types, each with a count and one representative quote. Constraints — use only content that appears in the material; don't speculate about causes; counts must be real statistics, not estimates. Acceptance — output as a Markdown table with three columns: type, count, representative quote.

The second version is longer, but every sentence narrows the range, and none is filler. It's also reusable — next week's tickets just need fresh material. OpenAI's official guidance says exactly this: the more explicit the request, the more stable the output. openai-prompt-eng

Notice the "don't speculate about causes" line. Without it, the model will happily analyze root causes for you — it sounds insightful, and it's made up. That's the constraints part doing its job.

Diagnose by symptom

The real value of these four parts is fast diagnosis: when results are off, you locate the gap instead of rewriting the whole thing.

A word on ordering. The four parts usually sit as: context first, requirements in the middle, constraints and acceptance at the end. The reason is practical: the beginning and end of a prompt are what the model sees most clearly, and constraints and acceptance are the two parts you can least afford to have ignored.

Once you've located the missing part, fix that one and re-run your test cases — which is exactly the iteration method covered next.