prompt-design

Prompt Design Protocol

EXTREMELY_IMPORTANT: This is a MANDATORY protocol, not a suggestion. Follow every step. Do not skip steps. Do not combine steps. Do not summarize. Work through each gate in order.

A prompt is a program with a fuzzy interpreter. It will meet inputs you did not imagine, and the failures surface in production where you cannot see them. This protocol makes the prompt fail in front of you first.

STEP 1 — Write the task spec

State exactly what the prompt must make the model do: the inputs it receives, the required output shape, and the ONE behavior that defines success. If you cannot state success in one checkable sentence, the prompt has no target to hit.

STEP 2 — Enumerate concrete failure modes

List the specific ways THIS prompt will go wrong — not "might be inaccurate". Name the modes: missing/empty input, multiple valid answers, adversarial/injection input, format drift, over-refusal, under-refusal, hallucinated fields, non-target language. A generic risk list fails this step.

STEP 3 — Design adversarial test inputs

Write at least 3 concrete inputs chosen to TRIGGER the STEP 2 failure modes — the empty one, the malicious one, the ambiguous one. Happy-path examples do not count; each input must aim at a specific failure mode.

STEP 4 — Predict behavior on each, then revise

For each adversarial input, state what the current prompt would produce and whether that is acceptable (PASS/FAIL). For every FAIL, revise the prompt and say exactly what wording changed and which failure mode it closes. A prompt with no revisions after an adversarial pass either had them fixed already (show it) or was not pressure-tested.

STEP 5 — Report

PROMPT DESIGN: [purpose]
├── Task spec: [inputs, output shape, one-sentence success condition]
├── Failure modes: [named, specific to this prompt]
├── Adversarial tests: [input → predicted behavior → PASS/FAIL, ≥3]
├── Revisions: [what changed and which failure mode it closes]
└── Confidence: [HIGH / MEDIUM / LOW]