AnthropicClaude Certified Architect – Foundations2026-104.2 Apply few-shot prompting to improve output consistency and quality

Show findings a developer can act on

Completed by the knowledge check

Learning objective

Demonstrate the desired actionable report schema with examples of location, issue, severity, and suggested fix.

Core idea

Naming four fields does not show what a useful finding looks like. A location can be a repository name or an exact line. An issue can be a style preference or a supported failure. A suggested fix can say “improve handling” or identify the condition and operation that prevent the failure.

Use finished findings to demonstrate the expected level of specificity. Anthropic’s output-consistency guidance states that examples of the desired output are more effective than abstract instructions. Its prompting guidance also recommends examples for steering output format and structure and advises matching the prompt’s style to the desired output style. If the consumer expects JSON findings, show complete JSON findings rather than prose descriptions of them.

This objective concerns the quality and consistency of the report’s values. See 4.3 for schema enforcement. A correctly shaped object can still point at the wrong line, misstate impact, or propose a fix that does not address the issue. The examples need to teach those distinctions as well as the field names.

How it works

Define what each field must carry

Choose a report contract and keep it consistent across examples. In this lesson’s illustrative review service, location contains path and line, issue names a supported defect and consequence, severity uses a declared scale, and suggested_fix states the change that addresses the cause. These keys are application-defined output fields, not built-in Anthropic review fields.

The following criteria make each field actionable:

Field	What the example demonstrates	Weak value to avoid
`location`	A supplied file path and line where the relevant behavior occurs	A subsystem name with no anchor
`issue`	The triggering condition, violated behavior, and consequence	“This looks unsafe” without evidence
`severity`	One allowed label justified by the supplied impact	An invented label or escalation based only on tone
`suggested_fix`	A concrete change that preserves the intended behavior	“Refactor this” without a target or remedy

A file and line belong in the example input as well as the output. Otherwise the demonstration teaches invented precision. Anthropic’s hallucination guidance recommends grounding claims in provided evidence and verifying them against supporting quotes or sources. Apply that discipline to locations and consequences, not only to extracted facts.

Supply complete examples in the chosen shape

Assume the review input supplies billing/cart.ts, line 88, and states that empty carts are valid. At that line, the code divides a discount by itemCount without handling zero. The team’s severity rubric rates failures that prevent checkout for a supported input as high.

The example output demonstrates the full report shape:

{
  "findings": [
    {
      "location": { "path": "billing/cart.ts", "line": 88 },
      "issue": "An empty cart makes itemCount zero, so the per-item discount calculation cannot produce a valid checkout amount.",
      "severity": "high",
      "suggested_fix": "Handle itemCount === 0 before dividing; return the unchanged subtotal for an empty cart."
    }
  ]
}

The finding explains why the guard belongs before the division and what the empty-cart path should return. It does not propose changing the discount rules for populated carts. Those details make the fix assessable against the example’s supplied contract.

Add a second complete example with a different impact. The supplied input identifies ui/preview.ts, line 42: an optional preview renderer ignores the supplied width, while the final document and saved data remain correct. Under this application’s rubric, the target output is:

{
  "findings": [
    {
      "location": { "path": "ui/preview.ts", "line": 42 },
      "issue": "The preview call omits the supplied width, so the optional preview uses the default size instead of the requested size.",
      "severity": "low",
      "suggested_fix": "Pass the supplied width to the preview renderer at this call site."
    }
  ]
}

This teaches calibration rather than copying high into every report.

A third example supplies code that meets the declared contract and returns {"findings": []}. It demonstrates the no-finding shape without fabricating an issue to satisfy an apparent quota. See 4.2.2 for the acceptable-versus-defective judgment; here the additional lesson is how the accepted verdict is represented.

Align the examples and the instructions

Declare the severity rubric explicitly. For this service, high means a supported core workflow fails, medium means a material supported behavior is wrong without that core-workflow failure, and low means a limited optional behavior is wrong. These are chosen application meanings, not a universal Claude severity scale.

Every example must follow that rubric. If a cosmetic preview problem appears as high, the demonstration conflicts with the instructions. The model receives two different signals about the intended report even when the field names agree.

Show the exact output wrapper, key spelling, and representation of no findings. Keep explanations used to teach the examples separate from the report if the report contract has no explanation field. Anthropic recommends separating examples from instructions with <example> tags inside <examples>; those tags do not need to appear in the generated JSON.

When the live input lacks reliable line metadata, do not demonstrate that Claude should guess a number. Define how the application handles unresolved locations before accepting the report. The example set should use only locations its inputs actually support, and the prompt should allow uncertainty rather than invented anchors.

Key distinctions and trade-offs

Field presence versus useful content: A schema can describe structure. A worked example shows what qualifies as a precise issue or practical remedy. Both matter, but this lesson’s examples address the content quality rather than replacing schema enforcement.

Consistency versus identical values: Keep the same shape across findings, while changing severity and remedy according to evidence. A prompt that always emits the example’s impact label is consistent in appearance but wrong in judgment.

Concise findings versus missing causality: A useful finding can be short while still naming the condition and consequence. Removing that relationship to save words makes it harder for a developer to verify the diagnosis or evaluate the proposed fix.

Prompt examples versus production evidence: Example file paths establish the expected representation. They must not leak into findings about unrelated code. The live report needs anchors and consequences supported by the live input.

Architecture / decision scenario

A Claude Code CI review produces a paragraph one run and a list the next. Its instructions already name the four required fields, but developers receive vague fixes and mixed severity labels. The architect adds three demonstrations: the complete checkout finding, a complete low-impact preview finding, and an empty findings collection.

The prompt uses one declared rubric and one JSON wrapper throughout. The evaluation pull request contains a core-workflow defect in a different file, an optional rendering defect, and an acceptable guard. The expected report includes only the two supported defects, uses each supplied location, assigns severity from impact, and proposes changes that address their causes.

If the output copies billing/cart.ts into the unrelated finding, the examples have taught a value instead of its representation. If both findings become high, inspect the rubric and example calibration. If the output parses but says only “improve validation,” revise the example’s remedy specificity. Schema enforcement belongs to 4.3; factual and semantic validation belongs to 4.4.

Common exam traps

Repeating the field list when the stem already says detailed instructions produce inconsistent reports.
Showing a formatted finding whose fix is still “consider refactoring.”
Giving locations that the example input does not supply.
Treating every issue as high severity because all demonstrations use that label.
Assuming valid report structure establishes a correct diagnosis.

What to remember

Demonstrate complete findings with all four fields and consistent key spelling. Teach precision through supplied locations, consequences, impact-based severity, and changes that repair the cause. Include the no-finding representation and check the resulting reports on different inputs so example values do not become copied answers.