Few-shot examples are sample inputs and answers placed inside a prompt to show the model what you want. Because they steer behavior directly, check each one for origin, hidden instructions, sensitive content and license before it ships, and keep them under the same review as the rest of the template.
What few-shot examples are
Instead of just describing a task, you include two to five worked cases. The model imitates the pattern. They are powerful because the model treats them as a model of correct behavior.
That also makes them an input to supply chain review. Examples are often pasted from a ticket system, a customer email, a public forum or a colleague's chat. Each source has its own risk.
Four things that can go wrong
- Hidden instructions. An example copied from outside may contain text that reads as an instruction to the model. It would sit inside your prompt with the same authority as your own words.
- Sensitive data. Real customer messages can carry names, account numbers or internal details. Once in a prompt template they are copied into every call, logs and any prompt library.
- Bad demonstrations. An example that shows the model doing something you do not want, such as revealing a system prompt or skipping a check, teaches that behavior.
- Unclear rights. Text taken from a book, article or paid dataset may not be yours to reuse. This post is not legal advice, so ask counsel if the source is not your own.
Provenance checklist
| Question | Why |
|---|---|
| Who wrote this example? | Own staff text is lowest risk |
| Where was it copied from? | Outside text may contain hidden content |
| Does it contain personal or confidential data? | Prompts get logged and shared |
| Is anything in it phrased as a command to the model? | Could act as an injected instruction |
| Does it show just the behavior we want? | The model will copy it |
| Do we have the right to use it? | Avoid reuse of protected text |
| Who can edit it now? | Examples are part of the template |
How to fix a weak example
- Rewrite it by hand rather than pasting, which removes hidden characters and outside phrasing.
- Replace real names and numbers with invented ones.
- Remove any line that addresses the model directly unless it is your own instruction.
- Keep each example short, so a reviewer can read all of it.
Check pasted text for invisible characters too. Text copied from web pages can carry formatting or hidden elements that do not show on screen. Opening the file in a plain text editor that shows special characters, or diffing against a retyped version, will reveal differences.
Keep examples in the repository
Store examples with the template, not in a separate spreadsheet. Then a change to an example is a reviewed change to the prompt. Note the source of each in a comment line. If you adapted a vendor's sample, say so.
Test the effect
After changing examples, run your regression inputs. Few-shot changes can alter format and tone as much as rewording instructions does. See prompt regression tests as a CI gate. For classification examples in particular, see few-shot examples for security finding classification.
Quick check
Are synthetic examples safer than real ones?
They avoid exposing personal data, but they still need review for quality and for what behavior they demonstrate.
How many examples should I use?
Few enough that every one can be reviewed. More examples mean more to verify and more text sent on each call.
Last reviewed: 19 October 2026.
