A Five-Part Prompt Structure That Travels Across Models

Prompt techniques that depend on a particular model's quirks stop working when that model is updated. What does not expire is supplying information the model has no way to infer. Five parts, in this order, cover almost everything.

1. Role and context

Say who is asking and what the situation is. Not as theatre — the point is to narrow an enormous space of plausible answers. "You are reviewing a pull request in a Laravel codebase maintained by two people" rules out far more bad responses than "you are an expert programmer" ever will.

2. The task, stated once

One sentence, one verb, unambiguous. If your task sentence contains "and also", split it into two prompts. Chained requests in a single instruction are the most common cause of an answer that addresses half of what you asked.

3. The material

Put the actual content — the document, the code, the transcript — in a clearly delimited block, and label it. Models handle long inputs far better when the boundary between instruction and material is obvious. This is also the part people most often omit, then wonder why the answer is generic.

4. Constraints

Length, format, audience, tone, what to leave out, what to do when the material does not contain the answer. That last one matters more than the rest combined: an explicit "if the document does not say, reply that it does not say" is the cheapest available guard against invention.

5. The output shape

Describe the shape you want and, where you can, show one small example of it. A model given a concrete target format hits it reliably; a model asked for "a summary" returns whatever a summary meant in its training data that day.

Why the order matters

Context first sets the frame the rest is read through. The task before the material means the model knows what it is looking for while it reads. Constraints and format last are what it has seen most recently when it starts writing.

Three habits worth more than any template

• Change one thing at a time. Rewriting a whole prompt when the output is wrong teaches you nothing about which part was wrong.
• Keep a small test set. Five or six inputs with known-good outputs turn prompt work from taste into measurement.
• Save the prompts that work. A short library of your own proven prompts beats every collection of someone else's.

What to drop

Threats, bribes, urgency and elaborate personas were always weak effects and are weaker now. Politeness costs nothing and makes prompts easier for colleagues to read, which is a better reason to keep it than any claimed effect on quality.