Claude Prompt Engineering: Eight Core Patterns With Reusable Templates

Prompting Claude well is less about magic phrases and more about a handful of structural patterns that consistently improve results. This guide walks through eight patterns we have seen hold up across real projects, gives a reusable template for each, and calls out the techniques that are specific to Claude. None of these depend on secret parameters — they are about how you organize the words you already write.

1. Role prompting

Give Claude a clearly defined role before the task. A role sets the implicit audience, vocabulary, and standards, which sharpens tone and reduces generic answers.

Template:

You are a senior security engineer reviewing a pull request for the first time.
Your job is to find real vulnerabilities, not to praise the code.
Review the diff below. Report only findings that would matter in production,
ordered by severity. If you find none, say so explicitly.

<diff>
{PASTE_DIFF}
</diff>

Why it works: "senior security engineer" pulls in a whole background of expectations. "Report only findings that would matter" forbids the polite filler that often dilutes reviews.

2. Few-shot prompting

Show two or three input/output examples before asking for a new one. This is the single most reliable way to lock in an output format or a tone.

Template:

Classify the support ticket into exactly one category.

Ticket: "I was charged twice for my August bill."
Category: billing

Ticket: "The app crashes when I tap my profile picture."
Category: bug

Ticket: "How do I invite a teammate to my workspace?"
Category: how-to

Ticket: "{NEW_TICKET}"
Category:

Why it works: examples pin down the label set and the expected phrasing far more tightly than a verbal description. Keep the examples representative and the label set closed.

3. Chain-of-thought

Ask Claude to reason step by step before answering. For anything with arithmetic, logic, or multi-constraint judgement, this measurably improves accuracy.

Template:

Solve the problem below. First, reason step by step inside <thinking> tags.
Then give your final answer on its own line as "Answer: X".

A subscription costs $12/month. An annual plan costs $120/year and gives
two months free compared to monthly billing. If a user is in month 3 of
a monthly plan, how much do they save by switching to annual for the
remaining 9 months of this year?

Claude-specific note: Claude works well with an explicit thinking step. Forcing the answer onto a predictable line (Answer: X) makes parsing reliable when you call the API.

4. ReAct (reason + act)

For tasks that need tools or external lookups, interleave reasoning and actions. The model reasons about what to do next, takes an action, observes the result, and repeats until done.

Template:

You can call tools to answer the user's request. Use this loop:

Thought: <what you need to figure out next>
Action: <tool name and arguments>
Observation: <the tool's result>
... (repeat Thought/Action/Observation as needed)
Final Answer: <your answer to the user, citing observations>

User request: "How many of our top-10 customers by ARR opened a
support ticket last month?"

Why it works: making the reasoning visible lets the model correct itself between steps instead of committing to a single plan up front. It also gives you, the developer, an audit trail of how it arrived at the answer.

5. Self-consistency

For high-stakes answers, ask the same question several times (varying phrasing or temperature) and take the majority answer. This trades extra calls for reliability.

Template (orchestration, not a single prompt):

Run this prompt N times and keep the final answer each time:
{BASE_PROMPT}

Then return the answer that appears most often. If there is a tie,
return the candidates and their counts.

Why it works: independent samples occasionally go wrong in different directions; the correct answer tends to recur. Best for tasks with a checkable answer (math, classification) and wasteful for open-ended generation.

6. Structured output with XML tags

Claude follows XML-tag structure reliably. Use tags to separate sections, data, and instructions so the model cannot blend them.

Template:

You will receive a document inside <document> tags and a question
inside <question> tags.

<document>
{DOCUMENT}
</document>

<question>
{QUESTION}
</question>

Return your response as:

<answer>
<one paragraph answer grounded in the document>
</answer>

<sources>
<list of short quotes from the document that support the answer>
</sources>

If the document does not contain the answer, put "Not found in the
document." inside <answer> and leave <sources> empty.

Why it works: tags create hard boundaries. The "Not found" fallback is important — without it, models tend to fabricate rather than admit a gap.

7. Layered system prompts

Keep your system prompt in layers: stable identity, then policy, then task context. This makes prompts easier to maintain and lets you swap the task layer without touching the rest.

Template:

# Layer 1 — Identity
You are Acme Assistant, the support agent for Acme's billing product.
You are calm, precise, and never invent features.

# Layer 2 — Policy
- Never share account numbers or token values.
- If a question is outside billing, route to the general support channel.
- Quote policy from <kb> tags only; do not paraphrase pricing.

# Layer 3 — Task context
Today's date is {DATE}.
The user is on the {PLAN} plan.
<kb>
{KNOWLEDGE_BASE_EXCERPT}
</kb>

Why it works: when something breaks, you know which layer to edit. It also keeps the model's priorities straight — identity is constant, policy constrains, task context varies.

8. Self-critique and constitutional patterns

Before returning an answer, have Claude critique its own draft against explicit criteria and revise. This is a cheap way to catch the mistakes a single pass makes.

Template:

Draft a release note for the changes below.

After drafting, critique your draft against this checklist:
- Does it mention every user-visible change?
- Does it avoid jargon a non-engineer would not understand?
- Is anything overstated or speculative?

Revise the draft based on the critique, then return only the final version.

<changes>
{CHANGELOG}
</changes>

Why it works: a separate critique step forces the model to evaluate the output as if it were someone else's, which surfaces issues the drafting pass glossed over. Keep the checklist concrete; "make it better" does nothing.

Putting them together

These patterns compose. A production prompt often layers a role (1), few-shot examples (2), XML structure (6), and a self-critique pass (8). The mistake to avoid is reaching for all eight at once on a trivial task — each adds latency and token cost. Reach for chain-of-thought when the task has real reasoning, for self-consistency when an answer is checkable and stakes are high, and for self-critique when a wrong answer is expensive to recover from.

The unifying habit underneath all of them: write the prompt you would hand to a competent but literal-minded new colleague. Tell them who they are, show them examples of good work, separate the inputs from the instructions, and ask them to double-check before handing it back. Claude rewards the same clarity.

This article is based on publicly available information as of July 2026; the relevant APIs may evolve.