Apply few-shot prompting to improve output consistency and quality

Few-shot prompting means pairing your instructions with a small set of worked examples, each an input alongside the exact output you want. Zero-shot is instructions only; few-shot adds a handful of demonstrations. The blueprint's core claim is precise: few-shot examples are the most effective technique for achieving consistently formatted, actionable output when detailed instructions alone produce inconsistent results. Prose leaves too many degrees of freedom open, and a single example collapses them all at once.

It helps to place few-shot next to the other Domain 4 levers so you pick the right one on the exam. Explicit criteria (task 4.1) tell the model which categories to decide. A tool_use JSON schema (task 4.3) guarantees the syntactic shape. Few-shot is unique in that it demonstrates the decision and the shape together, and it is the only one of the three that reliably teaches judgment on ambiguous cases.

So the trigger to reach for few-shot is specific: your instructions are already reasonably detailed, yet the output still varies in format or in how borderline cases are judged. That is the signal that the model needs to be shown, not told. Moving from zero-shot to few-shot is usually the lowest-effort, highest-leverage improvement at that point.

Keep the set small: 2 to 4 targeted examples. More is rarely better. Extra examples inflate token cost on every call, and worse, they can push the model to overfit to the specific cases you listed instead of generalizing. Pick examples that sit on the hard edges of the task, the ambiguous cases where a reasonable model could plausibly go either way.

For ambiguous scenarios the example must show the reasoning for why one action was chosen over plausible alternatives, not just input then output. If you show only "input X produced output Y," the model can copy the surface form and still misjudge the next borderline case, because it never saw the decision boundary. Spelling out the why (why escalate here but resolve there, why this line is a bug but that near-identical one is fine) is exactly what transfers the judgment.

Examples can live in the system prompt, usually wrapped in delimiters so they are visibly separate from the instructions, or be supplied as prior user and assistant message turns. Both are valid; what matters is that examples are clearly distinct from the live input.

<example>
input: <a borderline case>
reasoning: chose to FLAG because the claimed behavior contradicts the code,
           not merely because the comment is old
output: { location, issue, severity, suggested_fix }
</example>

When downstream code parses every response, format drift is expensive. Few-shot examples that show the exact desired shape make every response come out the same way. For a code review, the canonical fields to demonstrate are location, issue, severity, and suggested fix. One or two fully worked examples do more for format consistency than several paragraphs describing the format, because the example is a template the model fills in rather than a spec it must interpret.

This is the fastest cure for the classic symptom of "detailed feedback for some items, one-liners for others, occasional freeform prose." Show the shape once or twice and the model conforms.

Mind the boundary with structured output (task 4.3). If you need machine-parseable JSON with zero syntax errors, tool_use with a strict JSON schema is the stronger guarantee, because it enforces the shape rather than suggesting it. Few-shot format examples are the right tool when you want a specific human-readable structure, or when you want to complement a schema by showing how to populate its fields well.

A defining property of good few-shot examples is that they let the model generalize judgment to novel patterns rather than matching only the exact cases you listed. This is why you include contrasting examples: at least one genuine issue and at least one acceptable pattern that superficially resembles a problem but is actually fine. Showing both draws the decision boundary, so the model can classify code it has never seen.

This is the direct fix for a reviewer that keeps flagging a legitimate local pattern. Add an example showing that pattern explicitly accepted, with the reasoning, right next to an example of the genuinely problematic version. The model learns to separate the two and stops flagging the benign one, without you enumerating every acceptable variant by hand.

Contrast this with the failed approach from task 4.1: telling the model to "be conservative" or "only report high-confidence findings" does not move precision, because those are vague confidence knobs, not decision boundaries. Concrete contrasting examples move precision; general confidence instructions do not.

Extraction from unstructured documents is where few-shot pays off against hallucination. Real documents vary in structure: inline citations versus a bibliography section, methodology in a dedicated section versus embedded in prose, informal measurements versus clean tables. Examples that show correct extraction from each structural variant teach the model to find the same information regardless of layout, so it generalizes across the document shapes you actually receive.

The second and bigger win is the empty or null problem. When a required field is simply absent from a source document, a model pressured to produce a value will often fabricate one. Include an example where the field genuinely is missing and the correct output is null (or an explicit "not present"). Demonstrating that returning null is the desired behavior suppresses fabricated values far more reliably than an instruction alone.

A compact, high-value few-shot set for extraction is therefore one example per structurally distinct document type you expect, plus one "field absent, return null" example. Pair these examples with nullable schema fields from task 4.3 so the schema permits the null the examples demonstrate.

Few-shot is powerful but not universal, and the exam checks whether you pick the proportionate fix rather than reflexively adding examples.

First trap: tool misrouting caused by minimal tool descriptions. If two similar tools have thin descriptions and the model picks the wrong one, the root-cause fix is to expand the tool descriptions (task 2.1), because descriptions are the primary mechanism the model uses to select tools. Adding few-shot routing examples piles token overhead onto every call without fixing the underlying ambiguity; it is a weaker, more expensive patch. Few-shot for tool selection is appropriate for genuinely ambiguous requests, not as a substitute for a clear description.

Second trap: guaranteed structure. If you must have syntactically valid JSON every time, use tool_use with a JSON schema (task 4.3), not few-shot format examples, which reduce but do not eliminate syntax drift.

Where few-shot IS the right first move: calibrating judgment on ambiguous or borderline cases (escalation decisions, severity classification, branch-level coverage-gap detection), locking an output format, and reducing false positives through contrasting examples. A recurring correct-answer pattern on the exam is "add explicit escalation criteria plus 2-4 few-shot examples" as the proportionate first response, ahead of building a separate classifier, a self-reported confidence threshold, or a sentiment model.