Prompt Design Patterns

Prompts are interfaces, and most bad ones fail the same few ways: they under-specify the output, bury the actual ask, or demand reasoning and formatting in the same breath. This skill applies a small catalog of load-bearing patterns to write and revise prompts systematically — and, more importantly, to test them against a saved set of cases instead of judging on the one example that happened to be on screen.

When to use this skill

• Writing a prompt that will run many times — in a pipeline, product, or template — rather than once
• A prompt "mostly works" but fails unpredictably on some inputs
• Converting a human process document into instructions a model can execute
• Reviewing someone else's prompt and needing a vocabulary for what is wrong with it

Instructions

1. Write the output contract first. Before any instructions, define exactly what comes back: format, fields, length bounds, and what to emit when the task is impossible — an explicit escape hatch such as {"status": "cannot_answer", "reason": ...}. Many hallucination bugs are really missing escape hatches.
2. State the role and the stakes in one sentence, and only when it changes behavior: "You review contracts for renewal risk; missing a risk is worse than flagging a false one." Skip decorative personas — they spend attention and buy nothing.
3. Choose patterns deliberately, not maximally:
   • Decomposition: split extract → transform → judge into separate calls when any step needs different context, examples, or review
   • Few-shot: 2-4 examples chosen to bracket the decision boundary — one boring case, one edge case, one rejection case; examples teach more than adjectives ever will
   • Rubric-then-judge: for evaluation tasks, have the model state criteria before scoring, so scores arrive with reasons attached
   • Draft-then-critique: for generation where quality beats latency — one pass to write, one to attack, one to repair
   • Delimited input: fence or tag user data so instructions and data cannot blur into each other
4. Put instructions before data, and restate the question after long data. The edges of a long context get read best; the critical constraint never belongs in the dead middle.
5. Ban vague quantifiers from your own instructions: "brief" becomes "under 80 words"; "if relevant" becomes the actual condition that makes it relevant.
6. Build the test set before revising: 5-15 real inputs, including the failures that motivated the work, each annotated with what "good" looks like. This is the prompt's unit test suite.
7. Change one thing per iteration and re-run the whole set. A revision that fixes two cases and silently breaks three is a regression with good publicity.
8. Version prompts like code: a label, a one-line changelog, and the test-set score at that version.

Output format

Deliver a prompt as a package, never a bare string:

### Prompt v<label>
<the prompt, with {placeholders} marked>

### Contract
Output: <format and bounds>. Escape hatch: <what to emit, and when>.

### Test set: <n>/<m> passing
Known weaknesses: <cases it still fails, stated honestly>

Quality bar

• The output contract is checkable by a program, not just by a person squinting
• Every instruction is testable or deleted — no "be accurate and helpful" filler
• Examples cover the decision boundary, not three variations of the same easy case
• The failure that motivated the work is in the test set and now passes
• Anyone can revise the prompt later without fear, because the test set defines "still works"

Anti-patterns

• The kitchen-sink persona ("world-class expert with decades of...") doing no measurable work
• Twelve instructions where three are load-bearing and nine are anxiety
• Format described in prose when one literal example of the output would be unambiguous
• Judging a revision on the example you wrote it against — that case is in-sample and proves nothing