Prompt patterns
Most prompt-engineering content is folklore. A handful of patterns actually compound.
Stop reading prompt threads written by people who've never deployed a prompt. They are bad for your brain.
What works is patterns: structures you reach for repeatedly across different jobs because they keep producing useful output. Here are the five we use most.
1. Role · Context · Task
Open with role, ground in context, end with task. Not because the model needs the ceremony — because you do. It forces you to write what the model actually has to know.
2. Structured input
If you're going to send the model freeform text, wrap it in tags or fences. <TICKET>...</TICKET>. Treat the input as a payload, not as conversation. The model reasons better when it can see the boundaries.
3. Few-shot, late
Examples go after the instructions, not before. Examples before the rules feel like the rules came from the examples. The model will follow the pattern of the examples and ignore the rules.
4. Self-critique with a contract
Ask the model to score its own output against an explicit rubric you give it. Not "is this good" — "rate yourself 0–10 on each of these three criteria." Generic self-critique drifts; rubric self-critique sharpens.
5. Contract output
End with a JSON schema or a fixed template. "Reply only in this shape." Combined with self-validation downstream, this is where 80% of automation reliability comes from.
When patterns break
When you change models, when input distribution shifts, when you cross a context-window threshold. None of these patterns are immune to those changes. The right move when one stops working is to re-run a few canonical examples and find the smallest change that brings it back — not to rewrite the whole prompt from memory.
Prompts are not poems. Don't fall in love with the wording.
Treat them like config files, version them, A/B them, and move on.