Few-Shot Prompt Templates: Copy-Paste Examples That Work (2026)

A few-shot prompt has three parts: a short instruction, a set of examples, and the new input. Each example shows the model a complete input and the exact output you'd accept. By the time the model reaches the real input, it has a concrete template to match rather than an abstract description to interpret.

The terms map to example counts: zero-shot is no examples, one-shot is a single example, and few-shot is roughly two to five. Above five examples you usually hit diminishing returns — the pattern is already clear and extra examples mostly add tokens. The core idea traces to Brown et al. 2020 (arXiv:2005.14165).

The reason few-shot beats a prose description for format-sensitive tasks is simple: it's far easier for a model to copy a shape it can see than to reconstruct one from words. "Return JSON with keys label and confidence" is ambiguous; two examples showing exactly that JSON are not.

Classification is the textbook few-shot win, especially when your categories have non-obvious boundaries. Show one example per label so the model learns where the lines are:

``` Classify each message as BUG, FEATURE_REQUEST, or QUESTION. Reply with only the label. Message: "The export button does nothing when I click it on mobile." Label: BUG Message: "It would be great if you could add dark mode." Label: FEATURE_REQUEST Message: "How do I reset my password?" Label: QUESTION Message: "The dashboard total doesn't match the CSV I exported." Label: ```

**Why it works:** one clean example per label teaches the boundaries better than a paragraph defining each category. Keep the example messages close in length and tone to the real inputs you'll feed it.

When you need to pull fields out of unstructured text into a fixed schema, few-shot examples lock the schema down. Show the exact JSON shape, including how to handle a missing field:

``` Extract the order details as JSON with keys: customer, item, quantity, ship_date. Use null for anything not stated. Input: "Hi, this is Dana — please send 3 of the blue mugs, need them by next Friday." Output: {"customer": "Dana", "item": "blue mugs", "quantity": 3, "ship_date": "next Friday"} Input: "Can you ship two desk lamps to the Austin office?" Output: {"customer": null, "item": "desk lamps", "quantity": 2, "ship_date": null} Input: "Reorder the same as last month, 10 units, deliver by the 30th." Output: ```

**Why it works:** the second example explicitly shows how nulls appear, so the model doesn't invent values or drop keys. Always include at least one example with a missing field — that's where extraction usually breaks.

Few-shot is the cleanest way to enforce an output format the model keeps drifting away from. Here, converting messy notes into a consistent standup update:

``` Rewrite each raw note as a one-line standup update in the format: [AREA] did X; next: Y. Note: "finished the login bug, going to start on the settings page tomorrow" Update: [Auth] Fixed the login bug; next: start the settings page. Note: "spent today reviewing PRs and unblocking the data team, no code from me" Update: [Reviews] Reviewed PRs and unblocked the data team; next: resume feature work. Note: "shipped the export fix, still chasing the flaky test in CI" Update: ```

**Why it works:** the bracketed area tag and the "did X; next: Y" shape are obvious from two examples and nearly impossible to describe precisely in prose. The model copies the punctuation and capitalization, too.

Modern frontier models follow instructions well, so you don't need examples for everything. The deciding factor is how format- or boundary-sensitive the task is.

**Reach for few-shot when:** the output must match a precise schema or format; the categories in a classification have fuzzy boundaries; you're replicating a specific style or voice; or the task is an unusual transformation the model hasn't seen much. In these cases 2-3 examples typically deliver most of the lift.

**Stay zero-shot when:** the task is well-specified in plain language (summarize this, draft an email about that), it's open-ended or creative (examples can constrain it to the example space), or you're on a tight token budget and instructions alone produce acceptable output. The practical default is to start zero-shot, and add 2-3 examples only if the output drifts on format or labels.

Use few-shot when: the task is format-sensitive (exact JSON/markdown shape), classification categories have non-obvious boundaries, you're matching a specific style, or it's an unusual transformation. 2-3 examples usually capture most of the benefit.
Use zero-shot when: the task is well-specified in plain language, it's open-ended or creative (examples can over-constrain it), or token budget is tight and instructions alone produce acceptable results. Start here and add examples only if output drifts.

Example quality beats example quantity — three well-chosen examples beat seven sloppy ones. A few rules that hold up in practice:

**Span the variety, don't cluster.** If your inputs vary, your examples should too. Five examples all from the easiest case teach the model to handle only that case.

**Include an edge case.** The example that shows a missing field, an ambiguous label, or an unusual input teaches more than another comfortable-middle example.

**Match real input format.** Examples should look like the messy, real inputs you'll actually send — same length and cleanliness — not idealized versions.

**Make the output exactly what you'd accept.** The model treats example outputs as "the kind of thing I produce," quirks included. If an example output has a stray space or wrong capitalization, expect to see it reproduced.