Most prompt advice is about persuasion: tell the model it is an expert, be polite, promise a tip. None of that survives a real task. What changes output is constraint — telling the model what not to produce.
The four parts
Every prompt in our library has the same skeleton.
**1. The role, stated as a boundary.** Not "you are a world-class engineer" but "you are reviewing a diff, not writing code". The second one tells the model what it may not do.
**2. The rules, phrased as prohibitions.** "Do not comment on formatting unless it changes behavior." A positive instruction ("focus on correctness") leaves room to wander; a prohibition does not.
**3. The output shape.** Sections, order, word limits. Without a shape, you get a wall of text and have to hunt for the answer.
**4. The escape hatch.** "If you find nothing, say so and stop. Do not pad." This is the part people leave out, and it is the most important one.
Why the escape hatch matters
A model asked to find problems will find problems, whether or not they exist. Without permission to say "nothing found", you get invented findings that cost you a review cycle to disprove.
The same logic applies to research prompts: "if the sources are insufficient, say that instead of filling the gap" turns a confident fabrication into an honest short answer.
Constraint is cheaper than retries
A common pattern: write a prompt, get a mediocre answer, rephrase, get another mediocre answer. Three rounds of that costs more than writing the constraints up front.
The test is simple. Read your prompt and ask: **if the model followed this literally, could it produce something useless?** If yes, the prompt is under-constrained.
Practical starting point
Take a prompt you use weekly. Add three things: one prohibition about what not to include, one sentence about output format, and one permission to say nothing found. Run it on the same input as before. The difference is usually larger than switching models.
Next: what an MCP server is — the layer underneath all of this.