Writing Prompts That Hold Up Under Pressure

Prompt quality is the difference between a demo and a system. The reliable pattern is not clever wording — it is separating concerns.

The four components

• Task. One sentence stating exactly what to produce. Put it first; models weight early instructions more heavily.
• Context. Only the information needed. Long preambles dilute attention and increase cost.
• Constraints. Length, tone, what to avoid, what to do when information is missing. Explicitly telling the model to say "not found" instead of guessing removes a large class of errors.
• Output shape. Show the exact format. For structured output, provide a small schema and one filled-in example.

Give an escape hatch

Instructions that force an answer produce confident fabrication. Add a clause permitting a refusal: if the source material does not contain the answer, say so. This single change improves factual reliability more than most rewording.

Test with hostile inputs

Run the prompt against empty input, an extremely long input, an input in another language and an input that asks for something adjacent to the task. Prompts that survive those come close to production-ready.

Version your prompts

Store prompts in files with dates, not in a developer's memory. When output quality changes, you need to know what changed and when.