Two simple ideas that change how well Claude understands you.

Positive examples: “do it like this”

A positive example is a sample of the output you want. It shows Claude the right length, tone, structure, and wording in a form it can copy the pattern of. If you want product descriptions that are short and playful, you paste one description that is short and playful. If you want customer replies that are calm and specific, you paste one reply that is calm and specific.

Negative examples: “not like this”

A negative example is a sample of what you do not want, usually shown together with a reason. It marks the edge of the target. Showing a reply that is cold and defensive, and saying “this is too defensive because it blames the customer”, tells Claude which habits to stay away from. Negative examples are most helpful when the mistake is subtle or common, and hard to describe in words alone.

A few words you will meet

Understanding the mechanism explains both the power of examples and their dangers.

Claude continues patterns

Claude is built on a large language model, which is trained to produce text that fits well with the text before it. When your prompt contains examples, those examples become part of the text Claude is continuing. Claude notices what they have in common: the length, the order of ideas, the vocabulary, the formatting. Then it writes a new answer that fits the same pattern. This ability to pick up a pattern from examples placed directly in the prompt is often called in-context learning.

flowchart TD
    A["Your instructions"] --> D["One prompt in the context window"]
    B["Positive examples: do it like this"] --> D
    C["Negative examples: not like this, and why"] --> D
    D --> E["Claude reads everything and notices the pattern"]
    E --> F["Claude writes a new answer that follows the pattern"]
    F --> G["You compare the answer with your examples"]

Read the diagram from top to bottom. Your instructions, your positive examples, and your negative examples are all combined into a single prompt. Claude reads the whole thing at once and works out the pattern. The new reply follows that pattern, and you check it against what you showed.

A short history of learning from examples

The idea of teaching a language model by placing examples in the prompt became widely known in 2020, when researchers at OpenAI described how their large model GPT-3 could perform new tasks after seeing only a few examples, without any extra training. The paper was even titled “Language Models are Few-Shot Learners”. Since then, every major family of language models, including Claude, has been used this way, and the technique has become one of the first tools that experienced prompt writers reach for.

Nothing is permanently changed

It is important to understand that examples in a prompt do not retrain Claude. The model’s internal numbers stay exactly the same. The examples work only because they sit in the conversation Claude is reading right now. This is why a new chat starts without them, and why you need to include them again, unless a feature such as saved project material or saved preferences keeps them for you, where such features are available.

Why showing often beats telling

Words are a lossy way to describe style. Try to describe “friendly but professional” and ten people will picture ten different emails. A single sample removes the ambiguity, because it carries the length, the rhythm, the level of formality, and a hundred small choices that you could never list. This is why even a short example can change a reply more than a long description.

The context window holds the examples

Everything Claude can see in a conversation sits in its context window, which has a size limit measured in tokens. Examples take up room there. A handful of short examples costs very little, but a dozen long ones can crowd out space for your real input. Include the fewest examples that do the job.

How many examples should you give? It depends on how hard the target is to describe.

Start with the simplest approach

A good habit is to begin with clear instructions and no examples. If the result is already good, you are done. If it misses in a way that is hard to explain, add one example. If it is still inconsistent, add a few more, and consider a negative example for the mistake that keeps recurring. Each added example costs tokens and effort, so add them only when they earn their place.

When examples help most

When examples may not be needed

For simple factual questions or standard tasks, Claude usually does well with clear instructions alone. Adding examples to a task that did not need them can even narrow the answer too much, pulling the reply toward the example when you wanted variety. Use examples as a tool, not as a ritual.

A good positive example is a small, accurate picture of the finished work.

What makes a positive example good

Show the input and the output together

When the task is transforming something, include both halves of the example: the input, and the output you wanted for it. For instance, if you want rough notes turned into polished updates, show one set of rough notes and the polished update that should come from it. This teaches Claude not just the style of the result but the relationship between the two.

Say what the example is

Introduce every example with a plain sentence such as “Here is an example of the kind of reply I want.” Without this, Claude may wonder whether the sample is part of the material to be processed. A one-line introduction removes the doubt.

Say which parts to copy

An example contains many features: topic, length, tone, structure, word choices. You usually want only some of them. Say so directly: “Match the length and the friendly tone, but write about the new topic below.” This one sentence prevents the most common problem with examples, which is copying details that were never meant to be copied.

A quick recipe for writing one

A positive example in practice

Suppose you want short product descriptions for an online shop. Your prompt might say: “Here is an example of the style I want: ‘Our canvas tote: sturdy enough for your groceries, pretty enough for your lunch date.’ Write descriptions in the same style, one sentence each, for a leather wallet and a ceramic mug. Match the playful tone and the length, but do not reuse the words from the example.” Claude now has a target that no adjective list could have supplied.

Used with care, a negative example marks the fence around the target. Used carelessly, it can pull the reply toward the mistake.

When a negative example helps

Negative examples are most useful when a particular mistake keeps happening and is hard to explain in words. Typical cases include a tone that sounds slightly wrong, a habit of adding unwanted filler, an overly formal style, vague answers where precision is needed, or a format that keeps drifting. Showing the exact bad version makes the problem concrete.

Always attach a reason

A negative example without an explanation can be confusing. Claude may not know which feature of the bad sample you dislike: the length, the tone, the opening, the vocabulary. So always add a short “because” clause. For instance: “Avoid replies like this one, because it blames the customer and offers no solution.”

Better still: pair the bad with a good

The most effective negative example is shown next to a corrected version. The pair teaches both what to avoid and what to do instead, which closes the loop. “Instead of this… write this” is one of the most useful patterns in all of prompting.

The priming risk

There is a known side effect with negative examples. Showing a model a bad pattern places that pattern in front of it, and the model may sometimes echo it. It is a bit like saying “Whatever you do, do not think of a pink elephant”, which makes the elephant harder to ignore. The fixes are simple: label the bad example clearly as something to avoid, give the reason, show the improved version, and rephrase the rule positively too, for example “Acknowledge the problem and offer a next step.”

Keep negative examples few and focused

One or two well-chosen negative examples are usually enough. Each one should illustrate a single clear mistake. A long list of different bad samples blurs the lesson and fills the prompt with the very text you want to avoid.

Placing a positive and negative example of the same task next to each other lets the contrast do the teaching.

Why contrast works

A single good example shows what to do, but it does not show which of its features matter. A bad example of the same task, with the differences highlighted, reveals those features. When Claude sees a calm reply beside a defensive one, the difference between them becomes the lesson: acknowledgment, specificity, and a next step.

flowchart TD
    A["Task: reply to an upset customer"] --> B["Positive example: calm, specific, offers a fix"]
    A --> C["Negative example: defensive, vague, blames the customer"]
    B --> D["Claude sees what to copy"]
    C --> E["Claude sees what to avoid"]
    D --> F["Rule Claude infers: acknowledge, be specific, offer a next step"]
    E --> F
    F --> G["New reply in the right style"]

The diagram shows two branches for the same task. One branch is the positive example and the other is the negative one. Each teaches a different half of the lesson, and Claude combines them into a working rule, which it then applies to a fresh customer message.

How to build a good contrast pair

• Keep the task and the input the same. Both examples should respond to the same message, so the only difference is the quality of the response.
• Change one thing at a time when you can. If the bad version differs in five ways, the lesson is muddy. A bad version that differs mainly in tone isolates the tone.
• Label both clearly. Use names like “Good reply” and “Reply to avoid”, so they are never mixed up.
• Say why. Add one sentence after the pair that names the difference that matters.

A complete contrast pair

The examples you pick matter as much as the instructions around them.

Cover the range, not just the middle

If all your examples look alike, Claude concludes that every answer should look like that. If your task has variations, such as short and long inputs, formal and casual messages, or typical and unusual cases, include examples that show them. This tells Claude which features are fixed and which should vary.

Include an edge case

Edge cases are the unusual inputs that cause the most trouble. A sentiment task that only shows clearly happy and clearly unhappy reviews will stumble on a flat, neutral one. Add one example for the awkward case: “It works.” with the label neutral. Handling edge cases is where examples earn their keep.

Keep examples consistent with each other

If one example uses bullet points and another uses paragraphs, Claude will not know which to follow. If one labels a borderline review positive and another labels a similar one negative, the labels become confusing. Before you send a prompt, read your examples side by side and check that they follow the same rules.

Watch for accidental patterns

Claude notices patterns you did not intend. If every positive example happens to start with “Great news!” or to mention a discount, Claude may start doing it too. If all your “negative” labels happen to sit on longer texts, the model may link length with the label. Vary the incidental details so only the intended lesson is consistent.

How many examples?

There is no magic number. A style task often needs only one or two. A classification task with several labels usually needs at least one for each label. Complex tasks with many variations may benefit from five or more. Start small, test the results, and add an example only when you can name the specific gap it fills.

Order can matter

Claude pays attention to the whole prompt, but examples near the end can have extra influence. If you have a most important example, put it last, and avoid ending with a negative example that might linger. A neat pattern is to show a contrast pair and finish with the good version.

When a prompt has instructions, examples, and real input all mixed together, clear boundaries keep Claude from getting confused.

Why labels matter

Imagine a pile of papers on a desk with no folders. A person has to guess which pages are instructions, which are samples, and which are the work to be done. Claude faces the same situation when everything in a prompt runs together. Clear labels tell it exactly what each part is.

Ways to mark sections

The simplest method is plain-language headings such as “Examples to copy:” and “Examples to avoid:”. Another popular approach, which Anthropic’s guidance recommends for Claude, is wrapping sections in descriptive tags, for example a tag named example around each sample, and a differently named tag for samples to avoid. Both work. What matters is that the labels are consistent and descriptive, and that the real input is clearly separated from the examples.

flowchart TD
    A["Role and goal"] --> B["Context and rules"]
    B --> C["Positive examples in labeled sections"]
    C --> D["Negative examples in labeled sections, each with a reason"]
    D --> E["The real input to work on"]
    E --> F["Reminder of the output format"]

The layout in the diagram moves from the general to the specific. It begins with the role and goal, then the background and rules, then the examples to copy, then the examples to avoid with their reasons, then the real material to work on, and finally a short reminder of the format. Keeping the real input after the examples helps make clear what is a sample and what is the actual task.

Labeling tips

• Use names that say what the section is. “Good reply” and “Reply to avoid” are clearer than “Example 1” and “Example 2”.
• Keep the same label style throughout. Switching between tags, headings, and dashes makes the prompt harder to read.
• Separate the real input. Mark where the material to process begins and ends, so Claude does not treat it as another example.
• Refer to sections by name. Say “Follow the style of the good replies above” so the instruction and the labels connect.

An example shows a result. A reason shows the thinking that led to it.

From copying to understanding

Without a reason, Claude can only imitate surface features. With a reason, it can apply the underlying principle to new situations. “This reply is good” tells it little. “This reply is good because it names the problem, takes responsibility, and gives a date” gives it three rules it can use on any customer message, even one that looks nothing like the example.

Useful reason phrases

State the rule in words as well

Even the best examples can be read in more than one way. After showing them, add one sentence that states the rule you want Claude to take away. This guards against the model drawing the wrong conclusion. The examples show the pattern, and the sentence names it.

Generalize or copy?

Be clear about whether you want Claude to imitate closely or to take inspiration. For a rigid format, such as a fixed report layout, close imitation is right, and you can say “follow this format exactly”. For writing style, you usually want the feel and not the words, and you can say “capture the spirit, but write it in fresh words”. Claude can do either, if you say which.

See how positive and negative examples change the outcome in six common situations.

Format is where examples shine brightest, because Claude copies layout very faithfully.

Show the layout

If you need output in a particular shape, show a sample in exactly that shape. A table with named columns, a list with a title and a one-line description for each item, an email with a subject line and sign-off, a report with fixed headings. Claude will reproduce the layout reliably, which is far easier than describing every detail in words.

Format examples for people and for programs

When people will read the output, examples keep results neat and consistent. When another program will read the output, examples are even more valuable, because small differences in layout can break the next step. In that case, show the exact field names in the exact order, and say “reply with only this structure and nothing else”.

Combine an example with a number

An example shows length by feel, and a number makes it exact. Say both: “Write replies about this long (under 60 words), like the example.” Claude then has both a picture and a measurement, and the two reinforce each other.

A negative example for format

Negative examples are useful for format too. If Claude keeps adding an introduction such as “Sure, here is your summary”, you can show that opening and say “Do not start with an opening line like this. Begin directly with the first bullet point.” Showing the unwanted habit and the preferred start is often the fastest cure.

Examples are powerful, and anything powerful can be misused. These are the problems to watch for.

Copying too closely

Claude can reproduce the wording, topic, or structure of an example when you wanted only its spirit. If every reply starts to sound like your sample, the examples are too dominant. Add variety, say which features to copy, and ask for fresh wording.

Over-fitting to the examples

If your examples cover only a narrow slice of the real inputs, Claude may handle that slice perfectly and stumble on everything else. This is called over-fitting. The remedy is to widen the examples to cover the range of real cases, including at least one unusual one.

Priming a bad pattern

As Chapter 5 showed, a negative example can sometimes pull the model toward the mistake. Guard against it by labeling the bad sample clearly, giving the reason, and showing the corrected version next to it.

flowchart TD
    A["Reply looks wrong"] --> B{"What kind of problem?"}
    B -->|"Copies example wording"| C["Add variety and say what to copy"]
    B -->|"Repeats a bad pattern"| D["Rephrase the negative example as a positive rule"]
    B -->|"Ignores the format"| E["Make every example match the format exactly"]
    B -->|"Wrong on unusual input"| F["Add an edge-case example"]
    B -->|"Too long or costly"| G["Trim to the fewest examples that work"]
    C --> H["Run again and compare"]
    D --> H
    E --> H
    F --> H
    G --> H

Every disappointing reply is raw material for a better example.

The correction loop

Correcting inside a conversation

You do not have to rewrite the original prompt each time. In a chat, you can say “That reply was too formal. Here is a version I would prefer, which is warmer and shorter. Please write the rest in that style.” This gives Claude a fresh contrast pair at the exact moment it is most useful.

Ask Claude to help build examples

Claude can also write candidate examples for you. You can ask it to draft three sample replies in different styles, then pick the one you like and use it as your positive example. You can even ask for a deliberately poor version, labeled as such, to use as a negative example. Always review what it produces, because examples you approve become the standard for everything that follows.

Keep a personal example library

When you find examples that work, save them. A small collection, organized by task, such as “polite decline”, “weekly update”, and “product blurb”, saves time and keeps your results consistent. Where your account offers saved project material or saved preferences, a standing example can be stored there, so you do not need to paste it every time.

Teams that build tools on Claude treat examples as a managed resource, not a one-off paste.

The example bank

A company that uses Claude to draft support replies, label documents, or write product text often keeps a collection of approved examples, both positive and negative, called an example bank. Each entry has an input, a good output, and sometimes a bad output with a reason. The bank is reviewed by people who know the business, so quality is controlled in one place.

Choosing the right examples at the right time

A large bank holds far more examples than can fit in one prompt. So a product often picks the few most relevant ones for each request, choosing those whose inputs are closest to the new input. A request about a late delivery gets examples about late deliveries, and a request about a refund gets refund examples. This keeps prompts short and the examples on target.

flowchart TD
    A["Example bank: positive and negative examples"] --> B["Example selector picks the closest matches"]
    C["Fixed instructions and rules"] --> D["Prompt builder"]
    B --> D
    E["New user input"] --> D
    D --> F["Input checks"]
    F --> G["Claude"]
    G --> H["Output checks: format and safety"]
    H --> I["Reply to user"]
    H --> J["Logs and quality metrics"]
    J --> K["Failures added to the example bank"]
    K --> A

The diagram shows a loop. A selector pulls the best examples from the bank, and a prompt builder combines them with the fixed instructions and the new input. After input checks, Claude writes the reply, and output checks confirm the format and safety. Logs record how things went, and failures are reviewed and turned into new examples that go back into the bank. The system gets better with use.

Design patterns worth knowing

Real-world scenarios

Examples are real text, and real text can carry private details or hidden instructions.

Use anonymized or invented examples

The best examples come from real work, but real work often includes names, phone numbers, account details, or confidential facts. Before an example goes into a prompt, replace those with placeholders or invented values. “Customer A” and “order number 12345” teach the same lesson as the real details, with none of the risk.

Examples can leak into outputs

Because Claude often copies from examples, details in them can reappear in replies, sometimes in front of the wrong audience. If a sample contains a real customer’s complaint, a later reply may echo it. Another reason to use invented details, and to tell Claude “do not reuse specifics from the examples”.

Untrusted examples and hidden instructions

If examples or material in your prompt come from outside sources, such as a web page, an email, or a shared document, they might contain hidden instructions aimed at the model, like “ignore your earlier rules”. This is called prompt injection. Claude is trained to resist it, and no defense is perfect. Keep your own instructions separate from outside material, label the material as content to work on, and review results before acting on them, particularly where money or private data is involved.

Examples do not guarantee safe behavior

A strong set of examples improves consistency, but it is not a security control. For sensitive work, combine good examples with permission limits, input and output checks, and human review for important actions.

How do you know your examples are doing their job? You test them.

Build a small test set

Collect twenty to fifty realistic inputs, including some unusual ones and the cases that failed before. Each time you change the examples or the instructions, run the whole set and compare the results with the previous run. This shows whether a change helped overall or only fixed one case while breaking others.

Version everything

Give each version of your prompt and example set a number. Note what changed and why, and keep the old versions so you can go back if a change makes things worse. In a product, log the version, the model used, the time taken, and a quality score for each reply, taking care that logs do not keep sensitive text longer than needed.

Retest when things change

When the model version changes, when your inputs change, or when you edit the examples, run the test set again. A prompt that behaved perfectly before can behave a little differently after an update, and a quick retest catches the change before your users do.

Turn complaints into permanent tests

Every time a real user or reviewer flags a bad output, add that input to the test set, and consider turning the output into a negative example. Over time the set grows into a complete safety net of past mistakes that cannot quietly return.

A short field guide you can keep next to your keyboard.

Best practices

Common mistakes

• Pasting examples with no introduction, so Claude is unsure whether they are samples or the task.
• Using a flawed example and expecting Claude to somehow ignore the flaws.
• Giving only negative examples, so the target is never shown.
• Letting examples contradict each other in format or labels.
• Leaving out edge cases, then being surprised when unusual inputs fail.
• Including real personal data in examples that will be shared or reused.
• Never testing the examples on more than one input.

Checklist before you press Send

Quick answers to questions people ask about examples in Claude.

The whole idea in one place.

Positive examples show Claude what you want, and negative examples show it what to avoid. Because Claude continues patterns, a few well-chosen examples placed in the prompt can shape length, tone, structure, and labels far more precisely than a long description. The best results come from combining instructions with examples, leading with the positive, attaching a short reason to every example, and pairing each negative example with a corrected version. Labels and clear separators keep the prompt tidy, edge cases and variety prevent narrow results, and invented details keep private data safe. When replies go wrong, treat the failure as raw material: turn it into a labeled contrast pair, retest on several inputs, and keep a growing library of what works. In real products, teams manage examples in a bank, select the most relevant ones, and measure results over time.