Few-Shot Prompting

The single highest-leverage prompt-engineering technique. Examples beat description for tone, format, and edge cases.

How many examples?

• 2 is the minimum that helps.
• 3–5 is the sweet spot.
• >10 has diminishing returns and costs context.

Where to put them

In system prompt for stable behavior; in user turn for per-request variation.

Wrap in XML tags so Claude doesn't confuse them with the actual task:

<examples>
  <example>
    <input>...</input>
    <output>...</output>
  </example>
  <example>
    <input>...</input>
    <output>...</output>
  </example>
</examples>

<task>
  <input>{actual_input}</input>
</task>

Choosing examples

• Cover the edges. Pick examples that demonstrate handling of: typical, ambiguous, and refusal/escalation cases.
• Match the input distribution. Examples should look like real inputs.
• Diversity over similarity. Three similar examples teach less than three covering different shapes.
• Show the exact output format. Down to whitespace, casing, punctuation.

Anti-patterns

• One example only ("zero-shot+one"). Claude often overfits to it.
• Examples in a different format than the task. Causes drift.
• Examples that contradict each other. Worse than none.
• Long, verbose examples when short would do.

Few-shot for classification

When you have a fixed label set:

<examples>
  <example><input>I want to cancel my account</input><label>cancellation</label></example>
  <example><input>My charge looks wrong</input><label>billing</label></example>
  <example><input>How do I export data?</input><label>how_to</label></example>
</examples>

For high-volume classification, run Haiku with these few-shot examples + cached system prompt. Cheap and fast.

See also

• prompt-engineering-basics
• structured-output
• system-prompts