Zero-shot and few-shot prompting with Claude

1.Zero-shot: getting results from instructions alone

A zero-shot prompt gives Claude a task and instructions but no worked examples of the answer. The Anthropic documentation never uses the word 'zero-shot'. It describes the same thing as a plain instruction prompt, and it treats examples as something you add when instructions alone are not enough. So the zero-shot prompt is your starting point, and how well it works depends mostly on how explicit it is.

The prompting best practices start with that principle: be specific about the output format and the constraints. Compare 'Create an analytics dashboard' with a version that adds 'Include as many relevant features and interactions as possible. Go beyond the basics to create a fully-featured implementation.' Neither version has an example. The second one simply says what a good result looks like. Being explicit matters more on current models. The Claude Sonnet 5 prompting guide says the model reads prompts literally: it does not carry an instruction over from one item to the next, and it does not guess at requests you left out. If you want something from a zero-shot prompt, you have to ask for it.

The second lever is motivation. 'NEVER use ellipses' is a bare rule. 'Your response will be read aloud by a text-to-speech engine, so never use ellipses since the text-to-speech engine will not know how to pronounce them' gives the reason. The docs say Claude can generalize from the explanation, so a stated reason also covers cases the rule never mentioned. Anthropic's prompt-engineering blog adds two habits for zero-shot prompts. First, say what to do rather than what not to do: 'Your response should be composed of smoothly flowing prose paragraphs' instead of 'Do not use markdown'. Second, give Claude explicit permission to say the data is insufficient instead of guessing.

Sources123

2.When instructions aren't enough: one-shot, then few-shot

Some requirements are hard to put into words. A summary style, a house tone or an unusual output layout can take a paragraph to describe and still come out slightly wrong. The prompting best practices call examples one of the most reliable ways to steer Claude's output format, tone and structure. The text-to-SQL cookbook describes few-shot learning as giving 'concrete examples of input-output pairs' so the model understands the task better. In that notebook, adding three example question-and-SQL pairs to a schema-plus-question prompt produced a correct query for a new question.

The blog lists when examples are worth adding: the format is easier to show than describe, you need a specific tone or style, the task follows subtle patterns or conventions, or plain instructions haven't given consistent results. It also stresses that examples aren't always needed, which is why the advice is to add them in steps: one example first, then more only if the output still misses. The summarization example below is one-shot. It shows a single article-and-summary pair, then asks for the same style on a new article.

Here's an example of the summary style I want:

Article: [link to article about AI regulation]
Summary: EU passes comprehensive AI Act targeting high-risk systems. Key provisions include transparency requirements and human oversight mandates. Takes effect 2026.

Now summarize this article in the same style: [link to your new article]

The same technique works with images, though less reliably. In the vision cookbook, Claude read a speedometer as 140 km/h until example images were added, after which it correctly read 140 miles per hour. The notebook adds that few-shot prompting with images doesn't always work but is worth trying on your use case.

Sources145

3.Crafting examples Claude learns the right lesson from

Claude copies whatever an example contains, including the parts you didn't mean to teach. The blog warns that current models pay very close attention to details in examples. If every example happens to be three sentences long, or happens to start the same way, those habits can become part of the output. The prompting best practices give three properties that guard against this:

- Relevant: the examples mirror your actual use case closely. - Diverse: they cover edge cases and vary enough that Claude doesn't pick up unintended patterns. - Structured: each one is wrapped in <example> tags, and a set of them in <examples> tags, so Claude can tell examples apart from instructions.

The third property matters because an unmarked example looks just like an instruction or like the input to process. Tags separate the parts of the prompt. That is also why the text-to-SQL cookbook puts its sample question-and-SQL pairs inside an <examples> block, apart from the schema and the real question.

An example doesn't have to be a full worked answer. The consistency guide shows a lighter version: a format template. A market-intelligence prompt gives one skeleton with placeholder content, then asks Claude to analyse two real competitors. Both outputs follow the skeleton tag for tag, with a 50-word overview, four SWOT lists and a short strategy line. The skeleton fixes the structure without suggesting any particular content.

<competitor>
  <name>Rival Inc</name>
  <overview>A 50-word summary.</overview>
  <swot>
    <strengths>- Bullet points</strengths>
    <weaknesses>- Bullet points</weaknesses>
    <opportunities>- Bullet points</opportunities>
    <threats>- Bullet points</threats>
  </swot>
  <strategy>A 30-word strategic response.</strategy>
</competitor>

Sources16

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.More examples are always better, so a prompt that needs examples should start with many of them.Why is that wrong?

   Anthropic's blog recommends starting with one example and moving to several only if the output still doesn't match what you need.

   Covered in When instructions aren't enough: one-shot, then few-shot

2. 2.Claude only takes the intended lesson from an example and ignores incidental details such as length or opening phrasing.Why is that wrong?

   Current Claude models pay very close attention to details in examples, so accidental shared patterns get copied. Examples need to vary enough to avoid this.

   Covered in Crafting examples Claude learns the right lesson from

3. 3.A zero-shot prompt can stay brief because the model will infer the scope and extras you obviously want.Why is that wrong?

   Current models read prompts literally. They don't carry an instruction over to other items or infer requests you didn't make, so scope and requirements must be stated.

   Covered in Zero-shot: getting results from instructions alone