Few-Shot Prompting Examples 2026: When Examples Beat Rules

Few shot prompting means you show the model a handful of input and output pairs before the real task so it copies the pattern instead of guessing from abstract rules alone. In 2026 that still wins when labels are custom, formats are rigid, or brand voice must match live tickets. Abstract instructions like "be professional" and "extract key fields" leave gaps; two or three concrete demos close them. This page is a paste library by job: classification, extraction, rewrite, and support tone. For the theory of when to prefer zero-shot versus few-shot, see few-shot-vs-zero-shot-prompting-2026. Soft drafting for your own stacks: https://promptmake.net/text.

When examples beat rules

Rules describe intent. Examples show the boundary. If your taxonomy uses "urgent-billing" versus "urgent-outage," a paragraph of definitions still lets the model invent a third label. One demo per label pins the frontier. If JSON field order and null handling matter, a filled object teaches faster than a schema essay. If support tone must sound like your brand, three rewritten replies beat "empathetic but concise."

Examples also lose when the task is already common in pretraining (generic sentiment, simple translate) or when you are on a reasoning flagship and the demos include long scratch work the model will ape. Keep demos short. Prefer final shape over CoT inside the examples unless you measured a need on a flash model.

Aim for two to four shots for most production jobs. Cover one edge case. Put a strong representative example last. Freeze the stack in version control and bump a prompt version when labels change. Stale demos silently retrain the model on last quarter's policy.

Rules that still belong next to examples

Keep a short instruction block: allowed labels, hard refusals, and output format. Examples illustrate; they do not replace a deny list. If PII must never appear in rewrites, say so in rules and show one redacted demo. If the model may answer "unknown," show that label once so it stays legal.

How many shots by job type

Binary or three-class tickets: one example per class (2–3 total). Extraction schemas with five to eight fields: two full objects, one of them sparse. Rewrite and tone: two before/after pairs plus one "leave unchanged" case if over-editing is a failure mode. More than five static shots usually means you need retrieval of dynamic examples or a fine-tune, not a longer prompt.

Paste-ready few shot prompting stacks by job

Copy a stack, replace bracketed slots, and keep the delimiter style consistent. The model pattern-matches your separators. Mixing "Example:" prose with XML tags inside one prompt invites format drift. Pick one style per template family and stick with it across revisions so diffs stay readable in code review.

These stacks assume a chat or API message layout where the system or developer message holds the rules and the user message holds examples plus the live input. You can also pack examples into the system block if your host caches prefixes (see prompt-caching-stable-prefixes). Either way, keep the live input last so the model treats demos as precedent and the final block as the job to finish.

Test on ten held-out items before you ship. If accuracy rises but latency doubles, trim the longest demo first. If one class keeps failing, swap that class's example for a harder boundary case instead of adding a fifth easy demo. Log format-validity separately from label accuracy so you know whether the model failed the taxonomy or the JSON shape.

On GPT-5.6 Sol, Claude Opus 5, Claude Fable 5, and Gemini 3.1 Pro, keep demos outcome-only unless an eval forces a short Checks line. On Gemini 3.5 Flash and Instant chat, a tiny Checks line inside one demo can rescue multi-condition tickets. Do not copy the flash variant onto the reasoning route by habit.

Draft messy first versions of these stacks at https://promptmake.net/text, then hand-edit the labels to match your taxonomy. The tool writes prompt text; it does not host your example CMS.

Classification stack (custom ticket labels)

Rules: Choose exactly one label from [billing, outage, how-to, spam]. Reply with JSON {"label":"...","confidence":"high|medium|low"}. If two labels fit, prefer outage over billing.

Example 1: Input: "Card was charged twice for August." Output: {"label":"billing","confidence":"high"}

Example 2: Input: "API returns 502 since 09:00 UTC, all regions." Output: {"label":"outage","confidence":"high"}

Example 3: Input: "How do I export CSV from the reports page?" Output: {"label":"how-to","confidence":"high"}

Live: Input: "{{ticket_text}}" Output:

Extraction stack (invoice-like fields)

Rules: Extract fields. Use null when missing. Dates as YYYY-MM-DD. Money as {"amount": number, "currency": "USD"}. No commentary.

Example 1: Input: "Invoice 1842 dated March 3, 2026. Total $1,240.00 USD due to Acme Supplies." Output: {"invoice_id":"1842","date":"2026-03-03","vendor":"Acme Supplies","total":{"amount":1240.00,"currency":"USD"}}

Example 2: Input: "Reminder: balance for PO-99 is twelve hundred euros. Date unknown." Output: {"invoice_id":null,"date":null,"vendor":null,"total":{"amount":1200.00,"currency":"EUR"}}

Live: Input: "{{document_text}}" Output:

Rewrite stack (clearer without new facts)

Rules: Rewrite for clarity at an 8th-grade reading level. Do not add facts. Keep numbers and names. If the source is already clear, return it unchanged.

Example 1: Input: "We are currently in the process of leveraging synergies to optimize the roadmap." Output: "We are combining related work to simplify the roadmap."

Example 2: Input: "Ship date: 18 Sep 2026. Owner: Mina." Output: "Ship date: 18 Sep 2026. Owner: Mina."

Live: Input: "{{paragraph}}" Output:

Support tone stack (brand voice replies)

Rules: Write a reply under 90 words. Warm, specific, no blame. Offer one next step. Never promise a refund unless the input says refund is approved.

Example 1: Input: Customer angry about late delivery; refund not approved; offer tracking + $10 credit policy allowed. Output: "Sorry this arrived late. Here is your tracking link: {{link}}. I added a $10 account credit for the delay. Reply if the package status still looks wrong after the next scan."

Example 2: Input: Customer asks how to reset MFA; calm tone. Output: "You can reset MFA under Settings → Security → Reset authenticator. You will need your backup codes. If those are missing, say so and I will start an identity check."

Live: Input: "{{agent_notes}}" Output:

Step-by-step: build your own few-shot stack

Start from failures, not from a desire to "add examples." Pull five wrong outputs from logs. Name the rule the model broke. Write the smallest demo that shows the correct boundary. Insert it. Re-score. Stop when the curve flattens. This failure-first loop beats inventing five textbook tickets that never appear in production.

Keep demos realistic. Synthetic happy-path text teaches less than a messy real ticket with typos. Scrub PII. If you cannot share real text, anonymize structure but keep length and noise. Preserve odd punctuation and partial sentences when those patterns show up in live traffic.

Store each stack next to its eval slice in the repo: prompts/support-classify/v3.md plus evals/support-classify/v3.jsonl. When product renames a label, change the demo and the eval in one pull request. Orphaned demos are how silent accuracy drops start.

On reasoning models (GPT-5.6 Sol, Claude Opus 5, Claude Fable 5, Gemini 3.1 Pro), prefer examples that show final labels or JSON only. Long reasoning inside demos can distract. On Gemini 3.5 Flash and Instant chat, a tiny Checks line inside one demo can help when logic fails; measure before you standardize it.

Steps 1–3: mine, draft, delimit

1. Mine 5–10 failure cases from production or a staging eval.
2. Draft one example per failure mode you still see after clearer rules.
3. Pick one delimiter style (markdown headings, XML tags, or "Input:/Output:") and apply it everywhere.

Steps 4–6: place, measure, freeze

1. Place rules first, examples second, live input last. If you use prompt caching, freeze rules and examples as a stable prefix.
2. Measure accuracy, format validity, and median tokens against zero-shot.
3. Freeze the winning stack behind a prompt version. Schedule a quarterly review so labels and tone still match the product.

Common mistakes with few shot prompting examples

Mistake 1: Five easy demos and zero boundary cases.

Mistake 2: Contradictory labels across examples.

Mistake 3: Examples that invent fields the schema forbids.

Mistake 4: Putting the live user text above the demos so the model treats demos as afterthoughts.

Mistake 5: Shipping tone examples that promise refunds your policy forbids.

Mistake 6: Treating few-shot-vs-zero-shot-prompting-2026 as a substitute for a paste library. That post decides when; this post shows what to paste.

Mistake 7: Expecting PromptMake to store and version your example CMS. Use https://promptmake.net/text to draft, then keep demos in git or your logging tool.

Soft next steps

Pick one classifier or rewrite job that still leans on vague adjectives. Replace the adjectives with two demos from this page. Run ten offline cases. If format validity jumps, expand to the other job types. Soft help drafting the instruction wrapper: https://promptmake.net/text. Keep the sibling comparison post bookmarked when someone asks whether you needed examples at all; keep this page open when they ask what to paste.

FAQ

What is few shot prompting in plain terms?

Few shot prompting is teaching by demonstration inside the prompt. You paste a few input and output pairs, then ask for the same pattern on new input. It shines when categories, schemas, or tone are specific to your product. It is optional when zero-shot already hits your quality bar.

How many examples should I use in 2026?

Most teams land on two to four. One per class for small taxonomies. Two full objects for extraction. Two before/after pairs for tone. Add more only while eval scores rise. Past that, retrieve dynamic examples or fine-tune.

Do examples beat detailed rules?

They beat vague rules. Strong short rules plus tight examples beat either alone. Use rules for allowlists and refusals. Use examples for boundaries the model keeps missing. If you write a page of rules and still see drift, swap paragraphs for demos.

Should I put chain of thought inside few-shot examples?

Usually no on reasoning flagships. Sometimes yes on flash models for multi-condition logic, if an A/B proves it. Keep any Checks section short. This library focuses on final-shape demos so you can paste without dragging CoT into every stack.

How is this different from few-shot-vs-zero-shot-prompting-2026?

That article compares techniques and tells you when to escalate from zero-shot. This article gives paste-ready few shot prompting stacks for classification, extraction, rewrite, and support tone. Use the comparison post to decide; use this post to implement.

Can I generate example stacks with PromptMake?

Yes as a drafting aid. Describe the labels and paste a rough sample at https://promptmake.net/text, then edit until every demo matches production policy. Guests get about three /text generations per day; free accounts about five. PromptMake does not run your classifier or store a prompt CMS.

What if my classes change every month?

Version the example block with the taxonomy. When a label dies, delete its demo in the same commit. Consider dynamic few-shot: retrieve the nearest past tickets at request time instead of a giant static list. Static stacks work until diversity explodes.