Skip to main content

Prompt pattern catalogue

The teachable layer that makes prompt skill transferable. Individual prompts live in the prompt library and are promoted on harness evidence; this page names the reusable patterns underneath them, so a new joiner learns six moves instead of memorising sixty prompts. When you review a squad's prompts, you're checking they use these patterns — not that they match a house style.

Spec-first​

Make the agent restate the specification — inputs, outputs, rules, edge behaviour — and surface ambiguities as questions before it produces anything. Catches misunderstanding at the cheapest possible point, and turns vague task briefs into visible gaps rather than silent guesses.

Before writing any code: restate the spec for this MTA premium-adjustment
endpoint in your own words — inputs, outputs, rounding rules, and what happens
when the adjustment date falls outside the policy period. List anything the
task brief leaves ambiguous as numbered questions. Do not start until I confirm.

Test-first​

Ask for the tests before the implementation. The failing tests become the definition of done, and reviewing tests is faster and more honest than reviewing code — a wrong test is obvious; wrong code hides. Pairs directly with the acceptance-criteria standard: positive, negative and boundary examples per criterion.

From these acceptance criteria for mid-term cancellation refunds, write the
tests first: one positive, one negative and one boundary case per criterion
(pro-rata to the day; cooling-off period means full refund; no refund once a
claim has been paid). Show me the failing tests before any implementation.

Critique-and-revise​

Two calls, not one: generate, then critique the output against a named checklist and revise. Naming the checklist matters — "make it better" produces polish; "critique against the standard" produces findings. Works on the agent's own output or a colleague's draft.

Here is the draft FNOL screen spec. Critique it against the acceptance-criteria
standard and the insurance UX heuristics: list every weakness with a severity,
then produce a revised version. Do not defend the draft — attack it.

SME framing​

Give the model a domain persona and the glossary, and require it to flag uncertain domain terms rather than guess. Insurance language is full of near-synonyms that aren't ("excess" vs "deductible", "MTA" vs "endorsement") — this pattern makes the model behave like a careful newcomer instead of a confident tourist.

Act as a UK commercial-lines underwriter reviewing this quote journey. Use the
attached domain glossary; where a term is ambiguous or used loosely (e.g.
"excess" vs "deductible"), flag it rather than guessing. Mark every assumption
a working underwriter would challenge.

Structured-output contracts​

Specify the exact output shape — a JSON schema, a table, a named template — so downstream steps (scripts, gates, other agents) can consume the result without a human reformatting it. Always state what to do with missing data; "never invent a value" is the load-bearing line.

Extract the policy details from the attached schedule and return ONLY valid
JSON in this shape:
{ "policyNumber": string, "insured": string, "inceptionDate": "YYYY-MM-DD",
  "sumsInsured": [ { "section": string, "amount": number, "currency": "GBP" } ] }
If a field is not present in the source, use null — never invent a value.

Red-team-your-own-output​

After the agent produces something, make it attack it: how does this fail, leak, overpay, mislead? Models are notably better at finding faults when asked to than at avoiding them unprompted. For anything touching money or personal data this pattern is not optional — it's the cheap rehearsal for the security and gate checks that follow.

You have just generated the claims-payment authorisation flow. Now attack it:
list the ways it could pay the wrong amount, pay twice, pay the wrong party,
or leak personal data (UK GDPR). Rank by likelihood × impact, and say which of
your own acceptance-criteria examples would have caught each one. Fix the top three.

Using the catalogue​

  • Compose them — a strong library prompt is usually two or three patterns stacked: spec-first, then structured output, then red-team.
  • Name the pattern in review — "this needs a structured-output contract" is faster and kinder feedback than a rewrite.
  • Promotion still needs evidence — a prompt built from good patterns is still draft until the harness says otherwise; see the contribution workflow.

Standards referenced: OWASP Top 10 for LLM Applications.