prompt-design

name

prompt-design

description

MANDATORY prompt-design protocol. You MUST invoke this skill when writing or revising a prompt, system prompt, agent instruction, or LLM task specification meant to run repeatedly — "write a prompt that...", "improve this prompt", "the model keeps doing X, fix the instructions". Do NOT ship a prompt tested only on the happy path. Do NOT finalize before adversarial inputs are run against it. Invoke BEFORE handing over the prompt. Does NOT apply to a one-off question you are asking a model right now, or to ordinary application code.

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]

Confidence: HIGH — every named failure mode has an adversarial test that now passes. MEDIUM — main failure modes covered, some hard to test without live runs. LOW — failure modes named but untested, or a FAIL remains open; do not ship yet.

Do NOT finalize or hand over the prompt until: - The task spec states inputs, output shape, and a one-sentence success condition - At least 3 named failure modes are listed, specific to this prompt - At least 3 adversarial inputs were run, each with a predicted behavior and PASS/FAIL - Every FAIL was fed back into a named revision, or is flagged as a known open risk

Delivering a prompt tested only on the happy path is a protocol violation, even if it "looks like it works".

Red flags that this skill catches:

• "The prompt is clear, it'll be fine" — clear to you, ambiguous to the input you did not picture. Run the adversarial three.
• "Edge cases are rare" — at scale, rare is hourly. Name three and test them.
• "I'll add guardrails if it misbehaves" — you will not see it misbehave; it fails silently in someone else's output. Provoke the failure now.
• "Testing prompts is hand-wavy" — predicting behavior on a named malicious input is not hand-wavy; skipping it is.

Handoff

Once the prompt passes its adversarial set, ship it with the test inputs kept as regression examples. If it drives an agent or tool call, run security-reasoning on the trust boundary the prompt sits on.