CCAR-P 2.3 — Zero-shot, few-shot and chain-of-thought

Which technique does this failure call for?

Zero-shot output falls short — how?

Wrong format, tone or labels
Add few-shot examples3–5, diverse, in <example> tags
Wrong multi-step reasoning
Let Claude thinkadaptive thinking, raise effort
Need to inspect each stage
Chain promptsdraft, review, refine as separate calls
Instructions were vague
Fix the zero-shot promptclearer task, context, criteria

Start from what is going wrong, not from a favourite technique. Several branches can apply at once — examples and thinking combine well.

Zero-shot: the baseline you always try first

A zero-shot prompt gives instructions and no worked examples. With current models it is the right starting point for most tasks, and it is only as good as its clarity. The best-practices guide’s golden rule is to show the prompt to a colleague with no context: if they would be confused, Claude will be too. State the task, the audience, the constraints and the output format; explain why rules matter; and number the steps when order is important.

The prompt engineering overview adds a precondition that architects should enforce: before tuning prompts, have success criteria, a way to test against them, and a first draft. Otherwise you cannot tell whether a technique helped. It also notes that some failures — latency and cost in particular — are better solved by choosing a different model than by prompting (covered in 2.1).

Few-shot: show, don’t just tell

The guide calls examples one of the most reliable ways to steer format, tone and structure, and recommends three to five of them. Make them relevant (close to real inputs), diverse (covering edge cases and varied enough that Claude does not latch onto an accidental pattern) and structured (each in <example> tags, grouped in <examples>, so they are not mistaken for instructions). Anthropic’s context-engineering post puts it as curating diverse, canonical examples rather than stuffing in a laundry list of every edge case.

Examples that teach versus examples that mislead

Look-alike examplestext

<examples>
<example>
Ticket: Charged twice.
Queue: billing
</example>
<example>
Ticket: Wrong invoice amount.
Queue: billing
</example>
<example>
Ticket: Refund not received.
Queue: billing
</example>
</examples>

Diverse, canonical examplestext

<examples>
<example>
Ticket: Charged twice for May.
Queue: billing
</example>
<example>
Ticket: VPN drops every hour
since the update; I can't
reach the file server.
Queue: network
</example>
<example>
Ticket: Laptop stolen, had
payroll files on it.
Queue: security (urgent)
</example>
</examples>

On the left, every example is a short complaint labelled “billing”, so Claude learns length and topic, not the rule. On the right, examples vary in length and topic and include the hard case.

Worked example · Routing tickets for an internal IT desk

A manufacturer’s IT team uses Claude to route 3,000 tickets a week into eight queues. The zero-shot prompt lists the queues with one-line definitions. Accuracy is decent but labels are inconsistent (“Network”, “network issue”, “NET”) and security incidents sometimes land in “hardware”.

Diagnose the failure type. Inconsistent labels are a format problem; the security misroutes are a boundary problem between two categories. Both are what examples fix.
Add structure first. The output becomes a fixed label from a list, which removes most of the spelling variation even before examples.
Add four diverse examples. They differ in length and tone, and one deliberately shows a lost laptop — which sounds like hardware — routed to security, with the reason.
Measure. On 200 labelled historical tickets, security recall rises and label variation disappears. A fifth example adds nothing, so the team stops at four to keep the prompt lean.

Takeaway: Few-shot earned its place by fixing a specific, measured failure; the hardest boundary case was the most valuable example.

Chain-of-thought: then and now

Chain-of-thought means getting the model to reason before it answers, so multi-step problems — calculations, policy application, diagnosis — are worked through rather than guessed. Classic prompt engineering did this in text: “think step by step”, or tags that separate <thinking> from <answer>. On current Claude models this capability is built in. Adaptive thinking (thinking: {"type": "adaptive"}) lets Claude decide per request whether to reason and how much, and the effort parameter is the main dial. The docs report that thinking is on by default on Opus 5 and Sonnet 5 when the parameter is omitted, and always on for Fable 5.1.

Two ways to get reasoning before an answer

Manual chain-of-thought (prompt text)

“Reason through this” plus <thinking> and <answer> tags
Reasoning is ordinary output you parse and strip
The fallback when thinking is off
Wording-sensitive; you pay for every visible token

Built-in thinking (API)

thinking: {type: "adaptive"} with effort
Reasoning arrives in separate thinking blocks
Claude skips it on easy requests
Billed as output even when display is omitted

The best-practices guide gives four pieces of advice for reasoning on current models. Prefer general instructions over prescriptive steps: “think thoroughly” often beats a hand-written plan, because the model’s reasoning frequently exceeds what a human would prescribe. Examples and thinking combine: put <thinking> sections inside your few-shot examples to show the reasoning pattern you want. Use manual chain-of-thought as a fallback when thinking is off — though on Opus 5 the guide prefers keeping thinking on at lower effort. And asking Claude to verify against test criteria catches errors, except on Opus 5, which already verifies well and can over-verify.

Few-shot plus built-in thinking for a claims policy (illustrative)python

EXAMPLES = """<examples>
<example>
<claim>Order 5 days late; customer paid for express.</claim>
<thinking>Express was paid, so the late-delivery policy
applies. Over 3 days late is tier 2, not tier 1.</thinking>
<answer>Eligible: tier 2 credit</answer>
</example>
<example>
<claim>Parcel arrived damaged; no photo supplied.</claim>
<thinking>Damage claims need a photo under the policy, so
the decision waits on evidence.</thinking>
<answer>Needs review: photo missing</answer>
</example>
</examples>"""

response = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=8000,                     # room for thinking + answer
    thinking={"type": "adaptive"},
    output_config={"effort": "high"},
    system="You assess delivery claims.
" + POLICY + EXAMPLES,
    messages=[{"role": "user", "content": f"<claim>{claim}</claim>"}],
)

Thinking is steerable. The steering-thinking page says to set effort first and add prompt guidance only if triggering still does not match your needs. A system-prompt line such as “use extended thinking only when it will meaningfully improve quality” reduces it; “this task involves multistep reasoning, think carefully” encourages it; and a phrase appended to a single user message steers just that turn. Measure any steering on real traffic, because it trades quality for latency.

Technique	Best for	Cost	Watch out for
Zero-shot	Clear tasks with obvious output	Lowest	Vague instructions masquerading as a model problem
Few-shot	Format, tone, labels, boundary cases	Extra input tokens on every call (cacheable)	Look-alike examples that teach the wrong pattern
Built-in thinking	Multi-step reasoning, planning, tool-heavy agents	Output tokens and latency	`max_tokens` too small once thinking starts
Manual CoT in text	Models or settings with thinking off	Visible output tokens	Parsing the answer out of the reasoning
Prompt chaining	Auditable pipelines, self-correction	More calls	Chaining what one call with thinking could do

Self-correction as a prompt chain

Draftgenerate the first answer
Reviewcheck against stated criteria
Refinefix what the review found
Gatelog, evaluate or route to a human

The guide still recommends explicit chaining when you need to inspect or log intermediate outputs. Each arrow is a separate API call you can evaluate.

Worked example · Covenant checks at a commercial bank

A bank’s credit team asks Claude to check whether borrowers breach loan covenants from quarterly accounts. The zero-shot prompt gets simple ratios right but misses breaches that need two steps — adjusting EBITDA for one-off items, then computing leverage.

Name the failure. The answers are well formatted but the arithmetic chain is wrong. That is a reasoning failure, not a format one, so more examples of the output would not help.
Turn on reasoning, not a script. The team enables adaptive thinking at high effort instead of writing a ten-step procedure, and gives the covenant definitions as context.
Show the pattern once. Two examples include short <thinking> sections that adjust EBITDA before dividing, including one where the adjustment flips the result.
Ground and audit. The prompt asks Claude to quote the line items it used, which the hallucination guide recommends and which lets reviewers check the working.
Keep a human gate. Any predicted breach goes to an analyst; the chain’s logged review step shows why it was flagged.

Takeaway: Reasoning fixed the reasoning failure, a couple of examples showed the tricky pattern, and quotes made it auditable.

Traps the wrong answers are built from

Tempting but wrong	Do this instead
Adding “think step by step” to every prompt	Use thinking where multi-step reasoning is needed and keep simple, latency-critical calls direct.
Few-shot examples that share one length, topic or phrasing	Use 3–5 relevant, diverse examples, including the hardest boundary case.
Hand-writing a rigid reasoning procedure for a model that thinks	Give goals and context; prefer general instructions like “think thoroughly”.
Fixing a reasoning failure with more output examples	Diagnose the failure type; enable or raise thinking for reasoning errors.
Tuning prompts with no success criteria or test set	Define criteria and an eval first, then compare techniques on it.

You should now be able to

Write clear zero-shot prompts and recognise when a failure is really an unclear instruction.
Design few-shot examples that are relevant, diverse and tagged.
Apply chain-of-thought through adaptive thinking and effort, or manual tags when thinking is off.
Combine examples with reasoning by showing thinking inside examples.
Choose prompt chaining when intermediate outputs must be inspected or logged.
Match each technique to its cost in tokens and latency.

Zero-shot, few-shot and chain-of-thought