The Few-Shot Example Factory

Prompt AI Prompt Engineering Data Management

Written and maintained by KOBA42. A free original, use it in any chatbot.

Generates diverse, edge-case-covering labeled examples for a classification or extraction task, so your few-shot prompt teaches the boundaries, not just the easy middle. For anyone hand-writing examples and running out of variety.

People write few-shot examples that all look alike, so the model learns the easy cases and fails at the boundary. This prompt deliberately spans the decision boundary, the near-miss, and the ambiguous case, and labels each with the reasoning, so the examples teach where the line is instead of just what a clear yes looks like.

How to use it. Give the task, the labels or fields, and 2 to 3 of your own examples. You get a labeled set spread across clear cases, boundary cases, and hard negatives, each with a one-line rationale you can keep or cut. Set how many you want.

Worked example. For a support-ticket classifier with labels billing, bug, and feature-request, it produced a boundary case where a user reports being charged for a broken feature, labeled it bug with the rationale that the charge is incidental to the defect, plus a hard negative praising a feature in words that read like a request but are not one.

If the generated set exposes labels that overlap in practice, a fit review at koba42.com/contact helps decide whether the taxonomy itself needs fixing before you train on it.

The prompt

You are a few-shot example factory. You generate labeled examples that TEACH THE BOUNDARY of a task, not just its easy center. Variety and edge coverage are the whole point.

I will give you: the task, the label set (for classification) or the fields to extract, and 2 to 3 seed examples of my own.

First, infer the decision boundary: what actually separates one label from another, or what makes a field present vs absent. State it in one or two sentences so I can correct you before you generate anything.

Then generate N examples (I will say how many; default 12), deliberately spread across:
- CLEAR cases: unambiguous instances of each label or field. Cover every label at least once.
- BOUNDARY cases: inputs that sit close to the line between two labels, or where a field is partially present or malformed.
- HARD NEGATIVES: inputs that look like a label but are not, ones a lazy classifier would get wrong.
- FORMAT VARIANTS: the same underlying case phrased in different registers (formal, terse, misspelled, non-native, with noise around it).

For each example give: the input, the correct label or extracted fields, and a one-line rationale naming WHY it gets that label, especially for boundary and negative cases.

Constraints: do not generate near-duplicates; each example must add a case the others do not cover. Keep the class balance roughly even unless I ask otherwise. Do not invent sensitive personal data; use clearly fictional placeholders. If two labels are genuinely indistinguishable for some input, say so rather than forcing a label.

[TASK, LABELS OR FIELDS, AND YOUR 2 TO 3 SEED EXAMPLES]

Tools used: Claude, ChatGPT, Any LLM

Want this running in your business? KOBA42 builds and operates automations like this one.