Prompt Hygiene Rules

A prompt is an interface, not a suggestion — treat ambiguity in it as a bug you introduced, not as the model's failure to read your mind.

Specific over vague

• Replace vague direction ("make it better," "clean this up," "be concise") with a specific, checkable instruction ("cut this to under 200 words," "remove all adjectives that don't change meaning") — vague instructions get vague, inconsistent results because the model has to guess the actual bar.
• State the goal and the constraint separately: what the output should achieve, and what it must not do — a single blended sentence often loses the constraint when the model optimizes for the goal.
• When a task has a known failure mode, name it explicitly ("don't invent numbers that aren't in the source data") rather than assuming the model will infer the risk from context.

Examples beat descriptions

• Provide one or two concrete input/output examples instead of describing the desired output in the abstract — a worked example resolves ambiguity that no amount of prose description eliminates, especially for format, tone, and level of detail.
• When the task has edge cases, include an example that demonstrates the edge case handling, not just the happy path — a single clean example lets the model generalize incorrectly at the boundaries.
• Keep examples representative of the real distribution of inputs, not the easiest case — an example that's easier than production input teaches the wrong difficulty calibration.

State constraints positively

• Phrase constraints as what to do, not just what to avoid ("write in active voice" rather than only "don't use passive voice") — a purely negative constraint leaves the space of acceptable outputs underspecified, and models handle "don't do X" less reliably than "do Y."
• Where a negative constraint is unavoidable (a hard prohibition), pair it with the positive alternative so the model has somewhere to go instead of just something to avoid.

Context ordering: stable first

• Put stable, long-lived context (system instructions, background facts, style guide) before variable, per-request context (the specific user question) — this ordering is more cache-friendly and keeps the model's attention on grounding information before the immediate ask.
• Put the most important instructions last, immediately before the request, when using a long context — models weight recent context more heavily, so critical constraints placed early can get diluted by everything that follows.
• Don't bury a critical instruction in the middle of a long block of reference material — pull it out and restate it near the actual request if it's essential.

Specify output format explicitly

• State the exact output format required (JSON with named fields, a numbered list, a specific word count, markdown with specific headings) rather than leaving format to inference — an unspecified format produces output that's technically correct but unusable by the downstream consumer.
• For structured output, provide the exact schema or a template to fill in, not just a description of the fields — this removes an entire class of parsing failures downstream.
• If output will be parsed programmatically, say so and specify the exact delimiter/format contract — a prompt written for a human reader and one written for a parser need different instructions.

Iterate rather than mega-prompt

• Start from a minimal prompt that covers the core case, test it against real inputs, and add constraints only in response to observed failures — a prompt written to preempt every hypothetical edge case up front is harder to debug when it fails, because you can't isolate which instruction caused the problem.
• When a prompt grows past a handful of instructions, look for instructions that conflict or overlap — accumulated patches over time often contradict earlier ones without either being removed.

Test prompts like code

• Keep a small fixed set of representative test inputs and re-run them whenever the prompt changes — a prompt edit that fixes one case can silently break another, and without a fixed test set that regression goes unnoticed.
• Version prompts and track which version produced which output when debugging a production issue — "the prompt" without a version is not a reproducible artifact.
• Treat a prompt change with the same scrutiny as a code change to the same system: review it, test it against known cases, and roll it out deliberately rather than editing the live prompt in place.