Zero-Shot, Few-Shot, and Chain-of-Thought

Most people know only one way to prompt: type a request and hope. They treat every interaction the same way, regardless of whether they need Claude to follow a specific format, reason through a complex problem, or generate something creative with minimal guidance. This is like having three gears on a bicycle and only ever using first. You'll get somewhere, but you're working harder than you need to and arriving later than you should.

The three strategies in this chapter — zero-shot, few-shot, and chain-of-thought — are not academic categories. They are practical modes you switch between depending on what you need from Claude in the next thirty seconds. Understanding when to use each one is the single biggest upgrade most prompt authors can make, because it moves you from "I wrote a prompt and it kind of worked" to "I chose the right strategy for this task and it worked on the first try."

Zero-Shot: Clear Instructions, No Examples

Zero-shot prompting means you give Claude an instruction with enough clarity and context that it can produce the right output without seeing any examples of what that output should look like. You're relying entirely on the precision of your language.

This is the default mode for most prompting, and it works well when the task is unambiguous. "Summarize this article in three bullet points" is zero-shot. "Translate this paragraph into French" is zero-shot. "Write a subject line for an email announcing a product launch" is zero-shot. The common thread: Claude doesn't need to see a sample output to know what you mean, because the instruction itself is clear enough.

Where zero-shot prompting gets powerful is when you combine a clear instruction with specific constraints:

Prompt (zero-shot, well-constrained):

"Write a 100-word product description for a titanium travel
mug. Target audience: backpackers who care about weight
and durability. Tone: direct, no marketing fluff. Mention
the 450ml capacity, double-wall insulation, and the fact
that it weighs 180 grams. End with one sentence about
the lifetime warranty."

That prompt will produce a usable product description on the first attempt because every decision has been made in the prompt. Claude doesn't need to guess the audience, the length, the tone, or which features to highlight. Zero-shot works when you can articulate what you want clearly enough that an example would be redundant.

Where zero-shot fails is when the format you want is specific enough that describing it is harder than showing it. If I need Claude to output a table with very particular column headers, or I need a summary that follows a non-obvious structure (say, starting with the conclusion and working backward to the evidence), I'm going to spend more words describing the format than it would take to just show it. That's when few-shot becomes the better tool.

Few-Shot: Show, Don't Tell

Few-shot prompting means you include one or more examples of the input-output pattern you want Claude to follow. Instead of describing the format, you demonstrate it. Claude pattern-matches against your examples and produces output that mirrors their structure, tone, and level of detail.

This is the technique most people underuse, and it's the one that produces the most dramatic improvement in output consistency. The reason is simple: showing is more precise than telling. When you write "format it like a bullet list with a bold keyword followed by a colon and a short explanation," there are fifty ways to interpret that. When you show this —

Prompt (few-shot):

"Categorize each customer review as Positive, Negative,
or Neutral, and write a one-sentence summary.

Example:
Review: 'The shipping was fast but the packaging was
damaged. Product itself was fine.'
Category: Neutral
Summary: Shipping speed was good but packaging quality
was poor; product was undamaged.

Now categorize these reviews:
[paste reviews here]"

— there is exactly one way to interpret it. Claude sees the pattern and replicates it. The category label comes first, then a one-sentence summary that captures the nuance. No ambiguity about format, depth, or tone.

The number of examples matters, but not the way most people think. One example is usually enough for format. Two examples help when you need Claude to distinguish between categories (show one positive and one negative classification, and Claude will generalize the pattern). Three or more examples are for edge cases — when the task has unusual rules that only become clear through demonstration.

I've seen people paste ten examples into a prompt, thinking more is better. It's not. Beyond three examples, you're burning context window for diminishing returns. And worse, if your examples are inconsistent with each other — different lengths, different levels of detail, slightly different formats — Claude will try to reconcile the differences, and the output becomes a confused average of all your examples rather than a clean replication of any one of them.

Here's a real-world pattern I use constantly — formatting meeting notes:

Prompt (few-shot, meeting notes):

"Convert raw meeting notes into structured action items
using this format:

Example input: 'Sarah mentioned we need to update the
pricing page before the launch. John said he'd handle
the Stripe integration by Friday.'

Example output:
- [ ] Update pricing page before launch — Owner: Sarah
      — Due: Before launch date
- [ ] Complete Stripe integration — Owner: John
      — Due: Friday

Now convert these notes:
[paste raw notes]"

The output will be clean, consistent, and ready to paste into a project management tool. Without the example, Claude would produce something — but the format, the owner attribution, and the due-date extraction would all be Claude's best guess rather than your explicit template.

When Few-Shot Goes Wrong

The most common failure mode is inconsistent examples. If your first example uses bullet points and your second uses numbered lists, Claude sees two conflicting templates and splits the difference — or worse, alternates between them unpredictably. If your first example summary is two sentences long and your second is five sentences long, Claude averages somewhere around three, which may not be what you wanted either.

The second failure mode is over-specification. I've seen people paste eight or ten examples, each with slightly different edge cases, thinking they're being thorough. What they're actually doing is consuming a large portion of the context window with examples that don't add new information after the third one. And because real examples inevitably have slight inconsistencies — a missing comma here, a slightly different phrasing there — ten examples don't produce ten times the precision. They produce confusion.

The rule I follow: one example for format, two for categories, three maximum for complex edge-case patterns. If you need more than three examples to communicate the pattern, the pattern is probably too complex for few-shot alone and you should add written instructions alongside the examples.

Chain-of-Thought: Make Claude Show Its Work

Chain-of-thought prompting tells Claude to reason through a problem step by step rather than jumping to the conclusion. It's the difference between a calculator that shows "42" and a mathematician who shows every line of work. Both arrive at the same answer, but only one lets you verify the logic, catch errors, and understand why the answer is what it is.

The technique is dead simple: add "think step by step" or "explain your reasoning" to your prompt. That's it. The impact on reasoning quality, especially for math, logic, and multi-factor analysis, is disproportionately large.

Consider a classic logic puzzle:

Basic prompt:
"You're in a room with three light switches. Each controls
a bulb in the next room. You can only enter the next room
once. How do you figure out which switch controls which bulb?"

Chain-of-thought prompt:
"You're in a room with three light switches. Each controls
a bulb in the next room. You can only enter the next room
once. How do you figure out which switch controls which bulb?
Think step by step and explain your reasoning at each stage."

The basic prompt gets you the answer — turn one switch on for a while, turn it off, turn another on, enter the room and check for heat. But it often skips why this works: the key insight that you need three distinguishable states (on, off-but-warm, off-and-cold) because two states (on/off) can only differentiate two switches.

The chain-of-thought prompt walks through the constraint analysis first. Claude identifies that the one-visit restriction limits observation to a single moment. It recognizes that binary on/off gives only two data points for three unknowns. It then introduces heat as a third observable dimension. The reasoning is transparent, verifiable, and — critically — correct more often than the jump-to-answer version.

This isn't just useful for puzzles. Chain-of-thought is the right strategy for:

• Math problems where you need to verify the calculation, not just the result
• Business decisions where you want Claude to weigh multiple factors explicitly
• Debugging where you need Claude to trace through code logic rather than guess at the fix
• Argument evaluation where you need Claude to separate claims from evidence from conclusions
• Risk assessment where every assumption should be visible

The technique scales beyond puzzles and math. In business contexts, chain-of-thought transforms Claude from an answer-generator into an analyst. Consider asking Claude to evaluate whether your company should build a feature in-house or buy a third-party solution. Without chain-of-thought, you get a pros-and-cons list — surface-level and generic. With chain-of-thought, Claude walks through the cost comparison step by step, identifies the hidden costs (integration time, maintenance burden, vendor lock-in risk), and arrives at a recommendation that shows its assumptions. You can disagree with the conclusion, but at least you can see where you disagree and why, which is far more useful than a flat recommendation with no visible reasoning.

The failure mode of chain-of-thought is using it when you don't need it. If I ask Claude to translate a sentence into Spanish, step-by-step reasoning is wasted computation. If I ask Claude to generate a list of product names, chain-of-thought will slow down the response without improving quality. The strategy is for tasks that involve reasoning, analysis, or multi-step logic. For generation, formatting, and retrieval tasks, zero-shot or few-shot are the right tools.

Choosing the Right Strategy

The decision tree is straightforward:

Is the task clear and the format standard? Use zero-shot. Add constraints for precision.

Does the output need to follow a specific format that's easier to show than describe? Use few-shot. One to three examples. Make sure they're clean.

Does the task require reasoning, analysis, or multi-step logic? Use chain-of-thought. Ask Claude to think step by step.

Does the task require both a specific format and complex reasoning? Combine few-shot and chain-of-thought. Show the format you want and ask Claude to reason through its answer.

The most common mistake is defaulting to zero-shot for everything. The second most common mistake is over-engineering — using chain-of-thought for a task that just needs a clean example. Match the strategy to the task, not to your comfort level.

What to Do Monday Morning