Few-Shot Prompting

What is Few-Shot Prompting, and how does it differ from purely describing the output you want in words?

Few-shot prompting means including a few concrete example pairs in a prompt — input content matched with the expected output — letting Claude infer the style, format, and level of detail you want directly from those examples, rather than relying on an abstract written description to convey it. For instance, if you want Claude's help writing commit messages, instead of writing "describe the change in a concise, professional tone," you could directly give two or three real cases of "here's what kind of code change this is" paired with "here's the commit message that should result."

The key difference from a purely written description is precision of communication. Written description is prone to gray areas — words like "concise" and "professional" don't mean exactly the same thing to everyone. An example instead lays out the precise picture in your head directly for Claude to see, skipping the lossy translation step of trying to describe a style in words.

Why is Few-Shot Prompting needed, and what problem does it solve?

Describing output requirements purely in words runs into a specific limitation: language itself has limited ability to express things like style, tone, and fine-grained formatting rules. You can write "use a friendly but professional tone," but what "friendly but professional" actually looks like when it hits the page can vary quite a bit from person to person in their mental image — this gap isn't because the instruction wasn't written carefully enough; words themselves inherently have limits in conveying this kind of subtle nuance.

Few-shot prompting solves exactly this "limited expressive power of language" problem: rather than continuing to stack up adjectives trying to approximate the style you want, giving an example directly is a more direct form of communication — much like teaching a new colleague how to write a report. Instead of verbally describing "something roughly like this," showing them two or three past reports that were done well lets them grasp what that "feel" actually is on their own. The information density an example conveys is often higher than a written description of the same length.

How does Few-Shot Prompting actually work, and how many examples should you give, and how do you pick effective ones?

The underlying mechanism: Claude infers a common pattern (format structure, tone, judgment logic) from the examples provided, then applies that pattern to new input. There's no absolute rule on the number of examples — in practice, two or three usually produces a noticeable effect. What matters isn't the count but whether the examples themselves cover the key variation you care about. For instance, if the content you want Claude to produce spans two common scenarios (say, a feature-addition commit versus a bug-fix commit), it's better to include at least one example of each rather than only examples from one scenario — otherwise, Claude may not have enough reference to draw an analogy when it encounters the other scenario.

When selecting examples, quality matters more than quantity — rather than stuffing in five ordinary examples, curating two or three that clearly demonstrate the difference between "good" and "not quite good enough" works better. If the task has clear output formatting rules (a fixed field order, for instance), pairing examples with an explicit format template lets Claude grasp both the rule itself and what the rule looks like actually applied — combining both is usually more stable than giving only one or the other.

What does Few-Shot Prompting actually mean for me — when should I use examples, and when is a written description enough?

The test to come back to: "can this output requirement be fully stated in clear words?" If what you want is a clear-cut logical rule (a yes/no judgment like "check whether there's an owner field"), a written description is usually precise enough on its own, and no extra example is needed. But if what you want is something like a "style," "tone," or fine-grained formatting nuance that's hard to fully capture in a few sentences, an example usually gets Claude to the point faster than stacking up adjectives.

A useful habit in practice: when you notice you've written several sentences' worth of adjectives trying to describe a requirement and still feel "this still isn't precise enough," that's the signal to consider switching to an example. Also, few-shot prompting doesn't mean inventing an example from scratch every time — if you already have a real, good piece of past work on hand (a report you wrote well before, a good commit message you wrote earlier), using that actual piece as the example is usually closer to the standard you genuinely want than making up a hypothetical one yourself.