Few-Shot Prompting for Output Consistency and Quality

Few-shot prompting is the highest-leverage prompt-engineering technique a CCA-F candidate is expected to apply. Task statement 4.2 of the Claude Certified Architect — Foundations (CCA-F) exam — "Apply few-shot prompting to improve output consistency and quality" — sits inside Domain 4 (Prompt Engineering & Structured Output, 20 % weight) alongside explicit criteria design (4.1), structured output via tool use (4.3), and validation/retry loops (4.4). Few-shot prompting is the technique that most reliably lifts output quality without writing new code, touching the model, or adding infrastructure — and exactly because it is so powerful, the exam repeatedly probes whether you understand when, how, and how many examples to include.

This study note walks through the entire few-shot surface a CCA-F candidate must design at the architecture level: the formal definition of few-shot prompting as in-context learning, the zero-shot / one-shot / few-shot spectrum, the 2-to-5 example sweet spot and the diminishing returns beyond it, example selection criteria (diversity, boundary coverage, positive vs negative cases), format-matching discipline, the mechanism by which examples anchor style and format, the role of negative examples, placement decisions (system prompt vs user message), dynamic few-shot retrieval, classification-specific patterns, and the three structural limitations (context cost, example drift, staleness). A traps section and FAQ connect every concept to the four exam scenarios where few-shot prompting appears most heavily — structured-data-extraction, customer-support-resolution-agent, developer-productivity-with-claude, and multi-agent-research-system.

What Is Few-Shot Prompting? Providing Worked Examples in Prompt Context

Few-shot prompting is the practice of including two or more complete input-output examples inside the prompt so that Claude can infer the task's pattern directly from the examples rather than from instructions alone. The examples are the training signal; the task description becomes a short framing around them. Each example is a paired demonstration — here is the kind of input you will see, here is the exact output you should produce. Claude generalizes from the examples to the real input that follows.

Few-shot prompting is a form of in-context learning: the model acquires the pattern transiently for the duration of the current request, without any weight update. Nothing is trained, nothing is stored, and nothing is persisted between requests. Every new request that needs the same behaviour must re-include the same examples. This transience is the entire reason few-shot is not a substitute for fine-tuning but is instead a dramatically cheaper, faster, and more flexible alternative for the overwhelming majority of production patterns CCA-F tests.

Why CCA-F Puts Few-Shot in Domain 4

Domain 4 weighs 20 % of the exam and splits evenly across six task statements. Few-shot prompting (4.2) is the second-most-tested task in the domain after explicit criteria (4.1), because every downstream task — structured output (4.3), validation loops (4.4), batch processing (4.5), multi-pass review (4.6) — depends on Claude producing consistent output shapes. Few-shot is the cheapest and most universally applicable mechanism to enforce that consistency. Community pass reports repeatedly identify "under-using examples when instructions are not working" as a recurring distractor pattern: candidates pick "add more instructions" when the correct answer is "add two worked examples." The exam rewards candidates who reach for examples before they reach for additional prose.

Few-Shot Is Not Fine-Tuning

Fine-tuning updates the model's weights on a curated dataset and produces a new model checkpoint. Few-shot prompting injects examples into a single request's context and leaves the base model unchanged. On CCA-F, any answer that frames few-shot as "training Claude on your examples" or as a substitute for fine-tuning is wrong. The exam explicitly lists fine-tuning as out-of-scope, and few-shot questions will always have at least one distractor that conflates the two. The correct mental model: few-shot is fast, free to iterate, and ephemeral; fine-tuning is slow, expensive, and permanent.

Zero-Shot vs One-Shot vs Few-Shot — When Each Strategy Is Appropriate

The three prompting strategies form a spectrum of example density. Each has a correct use case, and picking the wrong point on the spectrum is a recurring CCA-F distractor.

Zero-Shot Prompting

Zero-shot prompting contains zero worked examples. The prompt consists of task instructions and possibly reference material, then the real input. Use zero-shot when:

• The task is well-defined by a short natural-language description (for example, "summarize this article in three sentences").
• Output format is either freeform prose or a widely-understood structure (a valid JSON object for a well-known schema).
• The cost of examples (context tokens, authoring time) is not justified by the quality lift.

Zero-shot is the right baseline for exploratory prototyping and for tasks where Claude's pre-trained behaviour already matches the target closely.

One-Shot Prompting

One-shot prompting includes exactly one worked example. It is a useful halfway house when:

• The task has a very specific output format that a single demonstration fully describes (a single invoice line item, for example).
• Context budget is tight and only one example fits.
• You are testing whether examples help before committing to the full few-shot investment.

A single example anchors format strongly but provides almost no information about boundary cases. Claude will often reproduce the exact wording and structure of the one example a bit too literally — a phenomenon sometimes called "one-shot over-mimicry."

Few-Shot Prompting (2+ Examples)

Few-shot prompting includes two or more worked examples. This is the regime where in-context learning works best. Multiple examples:

• Show the range of inputs the task must handle (not just one instance).
• Communicate variation — which parts of the output change and which stay fixed.
• Establish a decision surface — how to classify or route inputs that fall between simple cases.
• Dramatically reduce one-shot over-mimicry because the common structure is clear from the diversity of the examples.

Decision Heuristic

If the task description is unambiguous and Claude's baseline behaviour already fits, start zero-shot. If one demonstration would fully pin down the format, try one-shot. If the task has any sort of decision surface, edge cases, or format subtlety — and almost every CCA-F scenario does — use few-shot with 2 to 5 examples.

Example Count Guidance — 2-to-5 Examples as the Practical Sweet Spot

Anthropic's multishot prompting guidance recommends 3 to 5 examples as the practical sweet spot for most production tasks. Community pass reports converge on a slightly wider 2-to-5 range depending on task complexity. Understanding why this range works — and why more is rarely better — is repeatedly tested on CCA-F.

Two Examples — Minimum Viable Few-Shot

Two examples are enough to demonstrate a shared structure. Claude sees what is constant across the two outputs (the format, the field order, the tone) and what varies with input. Two examples are the minimum to avoid one-shot over-mimicry.

Three to Five Examples — Production Sweet Spot

Three to five examples cover the common case, one or two edge cases, and usually at least one contrastive case. This is where in-context learning shows the strongest quality lift. The marginal benefit of a third example over a second is typically large; the marginal benefit of a sixth over a fifth is typically small.

Six or More Examples — Diminishing Returns

Beyond roughly five examples, additional examples usually do not meaningfully improve output quality. They do reliably add:

• Input token cost on every request.
• Input processing latency proportional to context length.
• Risk of anchoring bias if the extra examples skew toward a particular pattern.
• "Lost in the middle" pressure as the example block grows long enough that mid-block examples are attended to less.

Why Quality Beats Quantity

A single carefully-chosen example that covers an important edge case contributes more than three redundant examples that all demonstrate the same easy pattern. Community pass reports identify "adding more similar examples when the output is still wrong" as a common dead-end. The correct move when quality is insufficient is usually to add a different kind of example — a boundary case, a negative example, a contrastive pair — not a fifth repetition of the same easy case.

Example Selection Criteria — Diversity, Boundary Coverage, Positive and Negative Cases

Choosing which examples to include is often harder than choosing how many. Three criteria drive selection.

Diversity

The examples should span the input space the task will face in production. If your real inputs range across four document types, your few-shot block should not contain four examples of only one document type. Diversity protects against Claude over-fitting its in-context pattern to a narrow slice of the input distribution.

In practice, diversity means:

• Input length diversity — short, medium, and long inputs if production sees all three.
• Input structure diversity — different formats, different field orders, different boilerplate.
• Outcome diversity — if the task is classification, include examples of multiple classes, not three examples of the same class.
• Domain diversity — if the task spans multiple domains (medical, legal, retail), include at least one example per domain.

Boundary Coverage

Edge cases are the highest-value examples per unit of context spent. An example that demonstrates "what to do when the input is ambiguous," "what to do when the input is empty," or "what to do when the input contradicts itself" teaches Claude a decision rule that no number of easy examples can convey.

Boundary cases to consider:

• Missing fields — inputs where a required piece of information is absent.
• Conflicting signals — inputs that pull in two directions.
• Near-miss inputs — inputs that look like they match the task but actually should not.
• Degenerate inputs — empty strings, whitespace-only, repeated tokens.

A single boundary example often fixes more production bugs than three additional typical examples.

Positive and Negative Cases

Positive examples show the target behaviour. Negative examples show a not-to-do pattern, typically paired with a correction. Negative examples are powerful in classification, content moderation, and structured extraction — any task where the line between "include" and "exclude" matters.

A negative example is not simply a wrong answer; it is a labelled example that explicitly shows Claude the undesirable output so Claude can sharpen its sense of the line. Section 7 covers negative examples in more depth.

Example Format Consistency — Matching Examples to Desired Output Format Exactly

Claude will reproduce the exact format of your examples. This is the primary mechanism by which few-shot enforces output consistency — and it means that every surface detail of your examples matters.

What Exact Format Matching Means

If your examples use JSON with field order id, name, amount, Claude will strongly prefer that exact field order in its output. If your examples use snake_case keys, Claude will not switch to camelCase. If your examples wrap output in <result>...</result> XML tags, Claude will produce the same tags. If your examples use lowercase enum values, Claude will not emit uppercase.

Why This Is a Feature

The enforced match is exactly what makes few-shot useful for consistency. Writing prose instructions that say "please use snake_case keys and lowercase enum values and this exact field order" is verbose, fragile, and often incomplete. Showing two examples with the target format is compact, precise, and leaves no room for interpretation.

Why This Is Also a Trap

Inconsistency across your own examples leaks into Claude's output. If Example 1 uses customer_id and Example 2 uses customerId, Claude will inconsistently alternate between the two in production. If Example 1 has a trailing newline and Example 2 does not, production output will mix both. A single typo in one example becomes a pattern Claude may replicate.

Discipline Checklist

Before shipping a few-shot prompt, verify every example against:

• Identical field names — same casing, same spelling, same order.
• Identical whitespace conventions — same indentation, same trailing newline policy.
• Identical wrapper markup — same XML tags, same Markdown fences, same delimiters.
• Identical tone — formality, verbosity, presence of greetings should all be consistent.
• Identical null handling — the convention for missing data must be the same across examples.

Output Consistency Mechanism — How Examples Anchor Format and Style

The consistency lift from few-shot prompting is not magic; it is a direct consequence of how transformer models condition on preceding context. Understanding the mechanism clarifies which problems few-shot fixes and which it does not.

Pattern Completion at Scale

Transformer language models are trained to predict the next token given preceding context. When you provide a sequence of example input-output pairs followed by a new input, the most probable continuation is another output in the same shape — because that is what the pattern in the context predicts. Claude is effectively completing the pattern [input1 → output1, input2 → output2, ..., inputN → ?], and the ? is heavily biased by the structural regularities of the previous outputs.

What Examples Anchor Reliably

• Structural format — JSON vs XML vs prose, field names, field order, wrapper tags.
• Length distribution — short outputs stay short; long outputs stay long.
• Tone and register — formal, informal, clinical, friendly.
• Vocabulary preferences — terminology, abbreviations, brand voice.
• Null-handling conventions — empty strings, null literals, absent keys, placeholders.
• Classification boundaries — which input features map to which output label.

What Examples Do Not Fix Alone

• Factual errors in domain knowledge — if Claude does not know a fact, examples will not add that fact.
• Hard schema validation — few-shot biases output strongly toward a schema but does not guarantee it. Combine with strict tool use (task 4.3) for guaranteed schema conformance.
• Long-document comprehension — if the input is too long for accurate processing, adding output examples does not fix the input-side problem.
• Reasoning errors on unseen input distributions — examples only guide Claude on the distribution they represent.

Implication for CCA-F

When a scenario describes an output format problem (inconsistent JSON shape, inconsistent tone, drifting field order), few-shot is usually the correct answer. When a scenario describes an output correctness problem (wrong facts, invalid schema that must be guaranteed, hallucinated content), few-shot is a partial solution and must be combined with explicit criteria (4.1), strict tool use (4.3), or validation loops (4.4).

Negative Examples — Showing Undesired Output to Sharpen Contrast

A negative example is a labelled demonstration of what Claude should NOT do. It is not an unlabeled wrong answer; it is an explicitly marked anti-pattern paired with a correction or with a clear "not this" framing. Negative examples are one of the highest-leverage techniques in few-shot prompting for tasks where the boundary between acceptable and unacceptable matters.

When Negative Examples Pay Off

• Content moderation — distinguishing subtle policy violations from benign content.
• Classification with fuzzy labels — separating "spam" from "promotional but wanted," or "urgent" from "high-priority."
• Structured extraction with ambiguity — teaching Claude not to extract a value when the input does not support it (the "do not hallucinate" boundary).
• Tone control — marking overly-formal or overly-casual outputs as unwanted when the target is a specific register.
• Format discipline — flagging "almost-right" outputs that fail on a subtle rule (a stray trailing comma, a key in the wrong case).

Structural Patterns for Negative Examples

Two common formats:

1. Contrastive pairs — each example contains both a wrong output and a correct output, explicitly labelled:

<example>
<input>Customer: "I want to speak to a human."</input>
<wrong_output>Have a nice day!</wrong_output>
<correct_output>I understand — connecting you to a human agent now.</correct_output>
</example>

2. Dedicated negative blocks — a handful of positive examples followed by a small block of clearly-flagged negatives:

<negative_examples>
<example>
<input>...</input>
<output>This output is wrong because it misses the escalation signal.</output>
</example>
</negative_examples>

Proportion Guidance

Negative examples should be the minority of the few-shot block — one negative per two to three positives is a reasonable ratio. Too many negatives can bias Claude toward over-rejecting inputs. The goal is to sharpen a contrast, not to reframe the task as "avoid bad outputs."

Example Placement — System Prompt vs User Message for Few-Shot Examples

Where you physically place the examples inside the request shapes how Claude treats them. CCA-F tests this distinction repeatedly, usually as a choice between system-prompt placement and user-message placement.

Examples in the System Prompt

Place examples in the system prompt when:

• The examples define a persistent persona or style the agent should use across every turn of a conversation.
• The examples describe tool-calling patterns that apply throughout a session.
• You want the example cost to be paid once per session (with prompt caching) and reused across many user turns.
• The examples are part of a reusable template that should be independent of any particular user input.

Examples in a User Message

Place examples in a user message when:

• The examples are task-specific and attached to a specific request.
• The examples are dynamically selected based on the current input (see Section 9).
• You are using the Messages API for a single-turn call where there is no conversational state to amortize over.
• The examples include the framing "here are worked examples of the task, now do this real one" — a classic single-turn few-shot pattern.

XML Tagging for Both Placements

Anthropic's prompt engineering guidance recommends wrapping example blocks in explicit XML tags (<examples>, <example>, <input>, <output>) regardless of placement. The XML tags make the example boundary unambiguous to Claude and make it easier for Claude to distinguish examples from instructions and from the actual input. Omitting XML tags is a common source of "Claude started generating more examples instead of answering" bugs.

Anchoring Bias in Example Ordering

The order of examples matters. Claude weights the most recent examples (closest to the real input) more heavily than earlier examples. Practical implications:

• Put the most representative example last, not first.
• Avoid clustering examples of the same class at the end — that biases the classifier.
• For classification, interleave classes rather than grouping them.
• For extraction, end with an example whose structure most closely matches the expected real-input structure.

Dynamic Few-Shot — Selecting Examples Programmatically Based on Input Similarity

A static few-shot block uses the same 3 to 5 examples for every request. Dynamic few-shot picks different examples for each request based on similarity to the current input. Dynamic few-shot is how the highest-quality production systems squeeze more out of few-shot without paying for a 20-example block on every call.

The Dynamic Few-Shot Pattern

1. Maintain a curated example library — a set of 50 to 500 worked input-output pairs covering the full production input distribution.
2. At request time, compute a similarity score between the current input and every example in the library (vector similarity, BM25 keyword scoring, metadata-based routing).
3. Select the top K (typically 3 to 5) most similar examples.
4. Inject those examples into the prompt as usual.
5. Submit the request.

Why Dynamic Few-Shot Beats Static

• Higher relevance — the examples Claude sees are the ones most like the current input, not a fixed sample of the input distribution.
• Better edge-case coverage — the library can cover 500 edge cases and surface only the one that matches the current input.
• Smaller active context — you can maintain a huge library and still pay for only 3 to 5 examples per request.
• Easier maintenance — adding a new example means appending to the library, not re-tuning the static block.

When Dynamic Few-Shot Is Worth the Engineering Cost

Dynamic few-shot requires an example store, a similarity engine, and a retrieval step on every request — real engineering investment. It pays off for:

• High-volume production workloads where a quality bump on each request compounds.
• Tasks with highly-variable input distributions where no 5-example static block is representative.
• Long-lived products where the example library can grow with user feedback.

For prototypes, short-lived tooling, or low-volume batch work, static few-shot is the correct trade-off.

Out-of-Scope Note

CCA-F lists embedding model internals and vector database implementation details as out-of-scope. The exam will test whether you recognize the dynamic few-shot pattern and when it is appropriate, not whether you can implement a vector search engine. Answers that require deep retrieval-engineering knowledge are distractors; answers that identify "select examples based on input similarity" as the correct architectural pattern are usually right.

Few-Shot for Classification — Examples as Implicit Decision Boundary Definition

Classification is the task where few-shot prompting shines brightest. The examples are literally the decision boundary: Claude infers the label mapping from the examples alone, without explicit rules.

The Classification Few-Shot Pattern

For a classifier with K labels, include approximately 1 to 2 examples per label (so 3 to 8 examples total for a small classifier). Each example is an (input, label) pair. Optional extras:

• A brief rationale field showing the reasoning behind the label — helpful for nuanced classes.
• A confidence hint if the label has a natural ordinal (low/medium/high).
• Negative examples for near-miss cases between adjacent labels.

Why Examples Beat Rules for Classification

Classification rules are hard to write exhaustively. "A ticket is urgent if it mentions outage OR if the customer is Enterprise OR if the message tone is angry" is a rule that can be encoded. But "a ticket is urgent if ..." for a real production taxonomy usually has dozens of fuzzy conditions no one wants to enumerate. A handful of representative examples captures the decision surface that a page of rules cannot.

Interleaving Classes to Avoid Order Bias

Always interleave the classes in your example block:

• Good: urgent, normal, urgent, low, normal, low.
• Bad: urgent, urgent, urgent, normal, normal, low.

Grouping classes at the end biases Claude toward the last class. Interleaving balances the ordering effect across all labels.

Combining With Structured Output

For classification, pair few-shot with a tool-use schema (task 4.3) so Claude must return a label from the allowed set. Few-shot teaches Claude the mapping; strict tool use enforces that the answer is one of the valid labels. This combination is the CCA-F exam's canonical answer for "make classification both accurate and schema-guaranteed."

Limitations of Few-Shot — Context Window Cost, Example Drift, Stale Examples

Few-shot prompting is not free, and it is not a cure-all. CCA-F expects candidates to recognize three structural limitations.

Context Window Cost

Every example pays input tokens on every request. A 5-example block at 300 tokens per example is 1 500 input tokens spent before the real input arrives. For low-latency high-volume workloads, this cost is real. Mitigations:

• Prompt caching — Anthropic's prompt caching feature amortizes the example-block cost across repeated requests. For a static few-shot block in a system prompt, the examples are paid once per cache hit, not once per call.
• Dynamic few-shot — retrieve fewer, more relevant examples instead of sending all examples every time.
• Example compression — trim each example to the minimum that conveys the pattern (remove boilerplate, shorten prose).

Example Drift

Example drift happens when the task subtly changes over time and the original examples no longer match the current target. Symptoms:

• Production outputs start to look slightly stale — old field name, old tone, old format convention.
• Claude occasionally produces outputs that exactly match the old examples but violate the new spec.
• The examples say one thing; the documentation says another.

Drift is a maintenance problem. The fix is to treat the example block as a first-class artifact: version-control it, review it on every product change that affects output shape, and include it in evaluation runs so regressions are caught.

Stale Examples

A stale example is one whose content no longer matches reality — a pricing example that references an old tier, a location example with an outdated address, a product example for a discontinued SKU. Stale examples are not just a maintenance issue; Claude will reproduce the stale content.

• Prefer abstract over concrete — where possible, structure examples so they do not depend on volatile facts. "Customer X in tier Y" beats "Acme Corp on the 2024 Gold plan."
• Audit on every release — stale detection belongs in the release checklist for any system prompt or skill that contains examples.

Few-Shot Is Not Fine-Tuning (Again)

Every limitation of few-shot ultimately traces back to the same root: examples live in context, not in weights. They are paid per request, must be re-shipped on every call, and have no persistence. When the per-request cost of examples is fundamentally too high for a given workload, the correct escalation path in the broader Claude ecosystem is not usually fine-tuning (explicitly out of scope for CCA-F) but is instead a combination of prompt caching, dynamic few-shot, and tighter examples. CCA-F answers that recommend fine-tuning as the fix to few-shot cost are wrong by definition.

Plain-English Explanation

Abstract few-shot mechanics become intuitive when anchored to physical systems candidates already know. Three different analogies cover the full sweep of the technique.

Analogy 1: The Apprentice in the Kitchen — Learning by Watching Worked Plates

Picture a new line cook on their first day. The head chef does not hand them a 20-page rulebook; the chef makes two or three plates in front of them and says "plate it like this." The apprentice watches the first plate (example one), watches the second plate (example two), and then starts plating tickets themselves. Each plate the chef makes is a worked example — same garnish placement, same sauce swoosh, same exact portion. By the third plate, the apprentice's plating is indistinguishable from the chef's. If the chef had said "plate it nicely" and left the apprentice to improvise, every plate would look different. The worked plates are the few-shot examples; the apprentice is Claude; the consistent plating is the output consistency few-shot delivers. Notice that one plate is not enough — the apprentice over-mimics. Twenty plates is wasteful — the apprentice learned after three. And if the chef's two plates disagree on where the sauce goes, the apprentice will alternate between both styles forever. That is exactly what format drift across examples does to Claude.

Analogy 2: The Library Cataloguer — Classification by Shown Examples

Imagine training a new cataloguer at a library. The task is to assign each incoming book to one of five Dewey ranges. Instead of explaining the full Dewey decimal system, the senior librarian hands the new hire five books already catalogued — one per Dewey range — and says "sort incoming books the way these have been sorted." The new hire does not memorize the Dewey rules; they generalize from the five examples. When a book comes in that sits between two ranges, they compare it to the examples and pick the closer one. The library already has 500 catalogued books in a back room, and for a hard case the senior librarian pulls three books similar to the current one for the new hire to consult. That is dynamic few-shot. Five interleaved examples beat five examples all from the same range. A bad example — a book filed in the wrong range long ago — trains the new hire to make the same mistake. Few-shot classification is the library cataloguer trained by shown examples, not by memorized rules.

Analogy 3: The Recipe Card — Format Consistency Without Instructions

A family recipe card is a specification disguised as an example. It says "cream butter and sugar, add eggs one at a time, fold in flour." A new cook reading that card will produce a cake that looks like every other cake made from that card — same texture, same shape, same crumb. The card does not need to say "use a 9-inch round pan." The example output, sitting on the shelf next to the card, silently enforces the pan size. If the card said only "bake a cake," outputs would vary wildly. The recipe card is a one-shot example plus instructions; a cookbook with three variations of the same cake (plain, lemon, chocolate) is a few-shot block. The cookbook teaches which parts of the recipe are fixed (the method) and which parts vary (the flavouring). When a cook comes out of that cookbook knowing how to improvise a fourth variation, few-shot has worked. When a cook using a single recipe card can only ever make the one cake on the card, one-shot over-mimicry has happened. CCA-F scenarios that complain about "output shape varies wildly across calls" are describing a missing cookbook — not a missing rulebook.

Which Analogy Fits Which Exam Question

• Questions about why examples beat instructions — apprentice kitchen analogy.
• Questions about classification via few-shot — library cataloguer analogy.
• Questions about format consistency lift from examples — recipe card analogy.

Common Exam Traps

CCA-F Domain 4 consistently exploits six recurring trap patterns around few-shot prompting. All six appear in community pass reports as plausible but incorrect distractors.

Trap 1: Conflating Few-Shot With Fine-Tuning

Few-shot prompting is in-context learning — examples in the prompt, no weight update, no persistence. Fine-tuning updates the model's weights on a curated dataset and produces a new checkpoint. The CCA-F exam explicitly lists fine-tuning as out-of-scope. Any answer that frames few-shot as "training Claude on your data" or "teaching Claude new behaviour permanently" is wrong. Few-shot is fast, free to iterate, and ephemeral; fine-tuning is slow, expensive, and permanent.

Trap 2: More Examples Always Beat Fewer

Anthropic's guidance identifies 3 to 5 examples as the practical sweet spot. Beyond roughly 5 examples, marginal quality gains are small while context cost, latency, and lost-in-the-middle risk grow. Answers that recommend "as many examples as possible" or "at least 10 examples" are wrong. Quality of examples beats quantity — a single boundary-case example can fix more bugs than three redundant positive examples.

Trap 3: Ignoring Example Format Consistency

Claude reproduces the exact surface format of the examples. If your examples disagree on field casing, field order, null handling, or wrapper markup, production output will alternate between the conflicting conventions. When an exam scenario describes "output format is inconsistent across runs," the correct answer often is "audit and fix inconsistency across the few-shot examples" — not "add more instructions."

Trap 4: Missing XML Tags Around the Example Block

Anthropic's prompt engineering guidance recommends wrapping examples in explicit <examples> and <example> tags. Without XML tagging, Claude can confuse instructions, examples, and input, sometimes continuing to generate more examples instead of answering. Answers that describe example injection without structural tagging are incomplete. XML tagging is a cross-cutting Domain 4 expectation tested on both tasks 4.1 and 4.2.

Trap 5: Skipping Negative Examples for Hallucination-Prone Tasks

For structured-data-extraction scenarios where Claude sometimes invents field values not present in the input, a single labelled negative example ("when the field is not in the input, return null; do not guess") is usually the correct fix. Candidates who keep adding positive examples while the hallucination persists miss this. Negative examples are the high-leverage tool for sharpening the boundary between "extract" and "do not extract."

Trap 6: Static Few-Shot When Dynamic Is Clearly Needed

When a scenario describes a wide input distribution that no 5-example static block can represent — for example, a classifier across 30 categories or an extractor across 20 document types — the correct answer is dynamic few-shot (retrieve examples per request by similarity), not "add more static examples." Answers that insist on a single static block for a highly-variable input space are wrong.

Practice Anchors

Few-shot prompting appears in all four scenarios that touch Domain 4, but two scenarios exercise it most heavily.

Structured-Data-Extraction Scenario

This is the flagship CCA-F scenario for task 4.2. The agent extracts structured fields from unstructured input — invoices, contracts, support tickets, medical notes. Expect questions that test: (a) choosing 3 to 5 diverse examples over a single example or a 20-example block, (b) adding a negative example when Claude hallucinates missing fields, (c) enforcing strict JSON field order through example format consistency, (d) pairing few-shot with strict tool use (task 4.3) for guaranteed schema conformance, (e) diagnosing format drift when examples disagree on casing or null handling, and (f) choosing system-prompt placement for a persistent extraction persona vs user-message placement for dynamic per-request examples. This scenario is the single highest-density use of few-shot on the exam.

Customer-Support-Resolution-Agent Scenario

In this scenario, a support agent classifies inbound tickets, drafts responses, and routes escalations. Few-shot shows up on: (a) classification prompts with 1 to 2 examples per label interleaved across classes, (b) drafting templates where a few worked examples establish tone and brand voice, (c) negative examples that teach the agent not to resolve out-of-scope queries, (d) dynamic few-shot where similar past tickets are retrieved as examples for the current ticket, and (e) the multi-agent-research-system and developer-productivity-with-claude scenarios, which also exercise few-shot but shift primary weight to the orchestration and code-generation patterns respectively.

FAQ — Few-Shot Prompting Top 6 Questions

What exactly is few-shot prompting and how does it differ from zero-shot?

Few-shot prompting is the practice of including two or more worked input-output examples inside the prompt so Claude can infer the task pattern from the demonstrations rather than from instructions alone. Zero-shot prompting contains no examples; the prompt consists of instructions plus input. Few-shot dramatically improves output consistency on tasks with specific format requirements, edge cases, or fuzzy decision boundaries. It is a form of in-context learning — the pattern is acquired transiently for the duration of a single request, with no weight update and no persistence between requests.

How many examples should I include in a few-shot prompt?

Anthropic's multishot prompting guidance identifies 3 to 5 diverse, relevant examples as the practical sweet spot for most tasks. Two examples are the minimum viable few-shot; beyond roughly 5 examples the marginal quality lift becomes small while you pay input tokens, latency, and lost-in-the-middle risk for the extra examples. Quality beats quantity — a single carefully-chosen boundary-case example contributes more than three redundant examples of the same easy pattern. Answers that recommend "as many as possible" or "at least 10" are wrong on CCA-F.

Is few-shot prompting the same as fine-tuning?

No. Few-shot prompting is in-context learning — examples live in the prompt and are paid per request. Fine-tuning updates the model's weights on a curated dataset and produces a new model checkpoint. Few-shot is fast, free to iterate, and ephemeral; fine-tuning is slow, expensive, and permanent. The CCA-F exam explicitly lists fine-tuning as out-of-scope, and questions routinely include a distractor that conflates the two. When quality is insufficient with zero-shot, the correct next step on CCA-F is almost always to add worked examples, not to fine-tune.

Should I put few-shot examples in the system prompt or a user message?

Place examples in the system prompt when they define a persistent persona, style, or tool-calling pattern that applies across every turn of a session — this also lets prompt caching amortize the cost across many user turns. Place examples in a user message when they are task-specific or dynamically selected per request based on input similarity. Regardless of placement, wrap the example block in explicit XML tags (<examples><example><input>...</input><output>...</output></example></examples>) to disambiguate examples from instructions and from the actual input.

When should I include negative examples?

Include negative examples for tasks where the boundary between acceptable and unacceptable outputs matters — content moderation, classification with fuzzy labels, structured extraction where hallucination of missing fields is a problem, and tone control. A single labelled negative example often fixes more production bugs than three more positive examples. Keep negatives in the minority (roughly one negative per two to three positives). Structural patterns include contrastive pairs (wrong output plus correct output in the same block) and dedicated <negative_examples> blocks. Over-using negatives biases Claude toward over-rejection.

How do I handle a task with hundreds of edge cases — do I need hundreds of examples in every prompt?

No — that is the correct use case for dynamic few-shot. Maintain a curated example library of 50 to 500 worked pairs covering the production input distribution. At request time, retrieve the top 3 to 5 examples most similar to the current input (vector similarity, keyword scoring, or metadata routing) and inject only those into the prompt. This keeps per-request context cost bounded at 3 to 5 examples while giving you coverage over hundreds of cases in the library. Dynamic few-shot is the CCA-F-correct answer whenever a scenario describes a wide input distribution that no static 5-example block could represent.

Further Reading

• Use examples (multishot prompting) to guide Claude's behavior: https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/multishot-prompting
• Prompt engineering overview: https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview
• Use XML tags to structure your prompts: https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/use-xml-tags
• Increase output consistency — structured outputs: https://docs.anthropic.com/en/docs/test-and-evaluate/strengthen-guardrails/increase-consistency
• Claude 4 prompting best practices: https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/claude-4-best-practices

Related ExamHub topics: Explicit Criteria Prompt Design, Structured Output with Tool Use and JSON Schemas, Validation, Retry, and Feedback Loops for Extraction, Multi-Instance and Multi-Pass Review Architectures.