few-shot-examples

name	few-shot-examples
description	Best practices for designing few-shot (input→output) examples in prompts for AI and agentic applications. Use when writing or reviewing prompts that need consistent formatting, structured/JSON output, classification, extraction, edge-case handling, or hallucination reduction; or when the user mentions few-shot, multishot, in-context examples, or "show the model an example".

Few-Shot Examples

Few-shot examples are concrete input→output pairs embedded in a prompt to guide the model by demonstration instead of description. They are the most reliable lever for output format and edge-case behavior, and the primary defense against hallucinated values.

When to use them

Reach for few-shot examples when the task needs any of:

1. Consistent formatting — lock output to one structure across every call.
2. Ambiguous / edge-case handling — show how to handle the cases prose underspecifies (nulls, empties, conflicting inputs).
3. Generalization — demonstrate the pattern so the model applies it to novel inputs.

Prefer examples over longer prose instructions for these. Examples show; criteria tell. Use both together.

Core rules

• Wrap each example in XML tags. Use <example> with nested <input> / <output>. This makes boundaries unambiguous and matches Claude's prompt-structuring conventions.
• Vary the inputs, fix the output shape. To teach normalization, map different input formats to the same canonical output (e.g. several date formats → one ISO-8601 string).
• Always include a missing-data example. Demonstrate that null/empty in → null/partial_record out is correct. This removes the model's incentive to fabricate. (See REFERENCE.md for the canonical null-handling example.)
• 2–5 examples is usually enough. Cover the common case plus the edge cases that matter; more examples cost tokens and context for diminishing returns.
• Make examples representative, not adversarial. They define the pattern, so every example should be one you'd be happy to see the model imitate.

Quick start

<example><input>Date: March 15th, 2024</input><output>2024-03-15</output></example>
<example><input>Date: 15/03/2024</input><output>2024-03-15</output></example>

Two inputs, one output shape: the model learns to normalize, not just to copy.

How few-shot fits with other techniques

• Few-shot complements JSON schemas / tool_use, never replaces them. A schema eliminates syntax errors (valid JSON, right fields). It does NOT eliminate semantic errors (right field, wrong value). Few-shot examples teach which value belongs where — the layer the schema can't enforce.
• Pair with nullable-but-required schema fields ("type": ["string", "null"]) so the model must explicitly acknowledge missing data instead of omitting or inventing it.
• Use temperature 0 for the extraction/classification/structured tasks where few-shot matters most, so the demonstrated pattern is followed deterministically.
• Validate empirically. Run the prompt against a labeled dataset and grade outputs (code-based for format, model-based for content). Add/trim examples based on results; don't assume they help.

Hard limitation

Few-shot examples teach pattern and format — they cannot manufacture information absent from the input. The same boundary applies as retry-with-error-feedback: examples fix format errors, never missing information. If the source lacks the data, the correct demonstrated behavior is to emit null / partial_record, not to fill the gap.

Deeper material

See REFERENCE.md for copy-paste patterns: null/hallucination handling, classification with extensible enums, schema redundancy for validation, and confidence/reasoning fields.