Prompt patterns that actually work

Prompt engineering today is not what it was in 2023. Modern models are robust to most phrasing tweaks. What they’re not robust to is unclear structure and contradictory instructions. Anthropic publishes a priority-ordered list of techniques that actually move the needle — this lesson works through it.

The order matters. If your prompt isn’t working, fix the higher items first. Don’t jump to chain-of-thought before you’ve made the basic instructions clear.

Anthropic’s priority list (the checklist)

1. Be clear and direct — write like you’re briefing a smart new colleague who doesn’t know your codebase.
2. Use examples (multishot) — 3-5 diverse examples beats almost any clever instruction.
3. Let the model think (CoT) — for genuinely hard tasks, ask the model to think step-by-step before answering.
4. Use XML tags — <context>, <example>, <instructions>. Claude in particular has been trained to attend to XML structure.
5. Long documents go at the top — Claude pays more attention to recent content. Put the document up front, the instructions at the bottom.
6. Prefill the response — start the assistant turn with an opening character to constrain format. Claude-specific; other APIs don’t expose this.
7. System prompts for role and global constraints — keep them short and concrete.
8. Prompt caching for repeated context — ~90% cost reduction and ~85% latency improvement on cached prefixes.

The patterns below are the ones that survive on current models — Claude 4.x, GPT-5+, Gemini 2.x — and are still worth knowing.

The structure: role, task, format

Almost every good production prompt has three parts:

1. Role / system message — who the model is acting as and what its constraints are.
2. Task — the specific thing to do, with the inputs.
3. Format — the exact shape of the expected output.

# Anatomy of a production prompt — three blocks, each doing one job.
# In real code you pass these as separate message parts; here they are
# strings so you can see the shape.

system = """You are an extraction assistant for a legal-tech app.
You read contract clauses and return structured findings.
You only output what is literally present in the text — never infer."""

task = """From the clause below, extract the parties' names, the
effective date, and the governing-law jurisdiction.

Clause:
This Agreement, effective as of January 15, 2026, is entered into
between Acme Corp and Beta Industries Ltd, and shall be governed
by the laws of Delaware."""

format_block = """Return a JSON object with keys:
  parties (list of strings), effective_date (YYYY-MM-DD),
  governing_law (string). Unknown fields -> null. No prose."""

full_prompt = "\n\n".join([system, task, format_block])

Note how each block does one job. The system message scopes behavior; the task is concrete; the format leaves no room for “Here you go!” or markdown decoration.

Before / after: a real comparison

Bad prompt:

Please look at this contract and tell me who's involved and when it
starts and what state's law applies. Try not to make stuff up.

Good prompt:

Extract the following from the contract clause below:
1. parties (list of legal entity names)
2. effective_date (YYYY-MM-DD)
3. governing_law (US state name)

Use only information literally present in the text. If a field is
not present, return null. Output a single JSON object, no prose.

Clause: """<text>"""

The good one isn’t longer because of politeness or hype — it’s longer because every requirement is explicit and positively framed.

Use positive instructions, not negative

This is the single most important syntactic rule. “Don’t do X” forces the model to think about X, and the autoregressive loop sometimes slips. “Do only Y” is unambiguous.

What still works

These techniques continue to earn their keep — in roughly the order you should reach for them:

• Few-shot (multishot) examples. 3-5 diverse input/output pairs. Especially good for niche formats and weird domains. (Full lesson next.)
• Chain-of-thought, but only when warranted. For multi-step problems (math, reasoning, multi-document analysis), asking for reasoning before the answer improves accuracy. Don’t add CoT to simple lookups or classifications — you’ll just burn tokens for no quality gain. On Claude, the convention is <thinking>...</thinking> XML tags to separate scratchpad from final answer.
• XML tags around structure. <context>, <example>, <instructions>, <document>. Claude’s training in particular emphasizes XML structure; other models also benefit. Picks data out of instructions and helps prevent prompt injection.
• Document at the top, instructions at the bottom. Claude attends more to recent content. For long-context prompts, put the document first and the question/instructions last. Anthropic measured several points of accuracy difference from this swap alone on long inputs.
• Explicit output schemas. Even when you can’t use structured outputs, telling the model the exact format reduces variance.
• Role assignment with constraints. “You are an extraction assistant; you only output JSON” sets two boundaries.

Prefill — a Claude-specific format lock

Anthropic’s Messages API lets you start the assistant turn with text you’ve already written. The model continues from there. This is the cheapest way to force a format:

# Force JSON-only output by prefilling an opening brace
messages = [
    {"role": "user", "content": "Extract name, age, city from the text..."},
    {"role": "assistant", "content": "{"},   # prefill — model continues from here
]

The model won’t open with a “Here you go!” preamble — its first token is already {. Other common prefills:

• <analysis> to force a thought block.
• Step 1: to force a numbered breakdown.
• [ to force a JSON array.

Prefill is Claude-specific in this form — OpenAI and Gemini don’t natively support assistant-side prefill. For those, structured outputs or stop sequences are the equivalent levers.

Prompt caching — the cost lever everyone underuses

Anthropic’s prompt caching lets you mark long static prefixes (system prompts, large RAG context, long documents) so the API server caches the internal computation. Cache hits are charged at roughly 10% of the normal input price, and they cut latency dramatically.

response = client.messages.create(
    model="claude-opus-4.7",
    system=[
        {"type": "text",
         "text": "You are a contract-analysis assistant. ...long static prompt..."},
        {"type": "text",
         "text": full_contract_text,
         "cache_control": {"type": "ephemeral"}},  # cache this block
    ],
    messages=[{"role": "user", "content": question}],
)

Typical wins:

• ~90% cost reduction on the cached portion of subsequent calls.
• ~85% latency improvement on time-to-first-token when the prefix is large (long system prompts, RAG context, document Q&A).
• Cache lifetime is ~5 minutes (ephemeral), refreshed on each hit.

Use it any time you have a stable prefix and a varying suffix — multi-turn chats, document Q&A, RAG, contextual retrieval. It’s the single highest-ROI knob in the SDK.

What no longer earns its keep

These were big in 2023 and you’ll still see them in old tutorials. Mostly they don’t move the needle on current models:

• “You are the world’s best expert in…” — Models don’t try harder because you flatter them. Don’t waste tokens.
• Politeness (“please”, “if you would be so kind”) — Has no measurable effect on quality. Use it for human-facing writing, not for prompts.
• Threats (“you will be fired if…”) — Sometimes shifts behavior in unpredictable ways. Avoid.
• “Take a deep breath…” — Was a fun 2023 finding; modern RLHF’d models have absorbed it. Doesn’t help anymore.
• Long persona backstories — Multi-paragraph character descriptions for simple tasks just dilute the instruction.

A useful exercise

Take any prompt you’ve written. Ask: what does this prompt assume? Then make those assumptions explicit. Most prompts that “don’t work” fail because the model interpreted a word differently than you did.

When the prompt is the wrong fix

Sometimes the real problem isn’t the prompt — it’s:

• The model. A smaller/cheaper model that needs ten prompt tweaks may be solved by switching to a stronger model.
• The data. Bad context in → bad answer out. No prompt fixes a truncated document.
• The task. Some things LLMs can’t reliably do (exact math, fresh facts). Give them a tool instead.

A good rule: if your third prompt iteration still has the same kind of error, the problem isn’t the prompt.

In one breath

• Modern models are robust to phrasing but not to unclear structure — fix the higher items on the checklist first.
• Build prompts in three blocks: role/system, task, format — each doing one job.
• Prefer positive instructions (“use only facts in the text”) over negation (“don’t make things up”).
• Show, don’t tell: 3-5 examples beat a paragraph of description; add chain-of-thought only for genuinely hard tasks.
• Prefill the assistant turn to lock format on Claude; prompt caching cuts ~90% of cost and ~85% of latency on a stable prefix.
• Skip the cargo cult — flattery, politeness, threats, and “take a deep breath” don’t move modern models.

Quick check

Next

The next lesson goes deeper on two of the patterns that still earn their keep: few-shot prompting and chain-of-thought.