Giving a model a role and constraints
How naming the audience, the format and the exclusions turns unpredictable answers into repeatable ones.
A role is not decoration. "Act as a senior engineer" changes the answer because it changes the standard the model measures against - what counts as worth mentioning, what can be assumed, what register to write in.
Roles that do work
A useful role names a standard, not a job title. "A senior engineer on this codebase" implies familiarity and raises the bar for what is worth reporting. "A copy editor with a light touch" says how much to change. "A teacher explaining to a beginner" fixes the assumed knowledge.
"You are a world-class expert" does none of this. It names no standard, so it changes nothing except the confidence of the tone, which is the one thing you did not want raised.
Constraints are exclusions
The clause that improves an answer most is usually the one saying what to leave out. "Skip style opinions." "No installation instructions." "Do not explain language basics."
This works because the default answer is the average of everything written about the topic, and most of that average is material you already know. Cutting it is what makes the rest readable.
Name the output shape
Length, structure, and what each section contains. "Three sections: decisions, actions, open questions" is a shape. "A summary" is not.
Where the shape is unusual, show it instead of describing it - one worked example, as covered under few-shot-prompting, removes more ambiguity than a paragraph of description.
Always leave an escape hatch
Every constraint list needs one line saying what to do when the constraints cannot be met: "if the diff is fine, say so in one line", "if a field is missing, set it to null", "if the schema does not cover this, ask instead of writing a query".
Without it the model satisfies the shape you demanded by inventing content to fill it. This single line is the difference between a prompt you can run unattended and one you have to check every time.
Try it
Take the code review prompt and read it as four decisions: the role sets the bar, the filter defines a finding, the format makes it actionable, the escape hatch permits silence. Every prompt in the library is built the same way.
Tagged