Core concept: Examples teach what a rule cannot state. Use them when the target is fuzzy or unusual. Skip them when the task is already pinned down.

Why A and D are correct:

A: Fuzzy or subjective category boundaries are the case rules cannot cover. The ticket routing guide tells you to give Claude "some real customer examples of these kinds of requests, along with what the underlying intent is", and to add a "classification rationale for particularly nuanced ticket intents".
A: The same guide calls "providing examples ... the most effective way to improve performance", and says to handle expected edge cases with "explicit instructions or examples in the prompt".
D: "Examples are one of the most reliable ways to steer Claude's output format, tone, and structure." A format you invented has no name Claude already knows, so showing it is the only reliable way.

Why the others are wrong:

B: Simple extraction with objective criteria works zero-shot. Examples only add tokens and can bias Claude toward the few shapes you showed.
C: Tool use already pins the JSON. With strict tools the inputs "strictly follow your schema", so examples fix a problem that no longer exists.

Remember: Few-shot is for fuzzy judgement calls and formats you invented. Not for tasks one clear sentence already defines.

Question 176