Claude Certification Guide CCAR-P

Curriculum › Claude Models, Prompting & Context Engineering · 13% of the exam

Prompting techniques: zero-shot, few-shot, chain-of-thought

What you’ll be able to do

  • Start from a clear zero-shot prompt with explicit criteria and diagnose what it gets wrong
  • Design few-shot examples that teach ambiguous-case judgment and format without overfitting
  • Apply chain-of-thought or extended thinking where multi-step reasoning fails, and contain its cost
  • Choose and combine techniques from evaluation evidence rather than habit

What you need to know

Techniques are answers to failure modes

Zero-shot, few-shot and chain-of-thought aren't levels of sophistication to climb. Each fixes a different kind of failure, and each has a cost in tokens, latency and maintenance. The Professional skill is reading the failure from evaluation results and applying the cheapest technique that addresses it:

  • Vague or inconsistent judgment ("flag risky clauses" flags everything, or nothing) usually means the criteria are implicit. Fix the zero-shot prompt first.
  • Inconsistent format or tone, or wrong calls on known edge cases, after the criteria are explicit: add a few targeted examples.
  • Errors in multi-step logic (calculations, eligibility rules with several conditions, reconciling conflicting sources): give the model room to reason before it answers.

Zero-shot done properly

Most "the model doesn't get it" complaints are prompts that never said what "it" was. A strong zero-shot prompt states the task, the audience, the decision criteria in concrete terms, what to do with uncertain or missing information, and the output format. "Flag clauses that are unusual" is a mood. "Flag a clause if it caps our liability below the contract value, grants the counterparty unilateral termination, or assigns IP we create; ignore standard boilerplate on notices and governing law" is a criterion. Explicit criteria also reduce false positives, which is often what destroys user trust in a reviewer system first.

Zero-shot is the right final answer more often than teams expect: it's the shortest prompt, the cheapest to cache and the easiest to maintain.

Few-shot: teach the judgment, not the surface

Examples are the most reliable way to pin down output format and to show how ambiguous cases should be handled. A few well-chosen examples usually beat many similar ones. Design them deliberately:

  • Target the boundary. Pick the cases the model gets wrong or that reasonable people disagree on, not easy ones it already handles.
  • Show the reasoning. A short note on why this case is "escalate" rather than "resolve" lets the model generalize to new cases instead of copying the example.
  • Vary the surface. If every positive example is a long email from an enterprise customer, the model can learn "long enterprise email → escalate". Vary length, wording and source so the only shared feature is the one you mean.
  • Separate examples from live input. Wrap them in their own tags so they're unmistakably illustrations.

At scale, examples are also an asset to manage. They cost tokens on every call (place them in the cached stable prefix), they go stale when policy changes, and a wrong example teaches the wrong rule very effectively. Version them with the prompt and review them when the policy they illustrate changes.

Chain-of-thought and extended thinking

Asking the model to work through a problem before answering improves accuracy on tasks that genuinely need several reasoning steps. There are two ways to do it:

  • Prompted reasoning. Ask for reasoning in a tagged section (for example <analysis>) followed by the answer in a separate tagged or structured section. Your code reads only the answer section, so you never parse a conclusion out of prose.
  • Extended thinking. On models that support it, the API can give Claude a separate thinking budget before the response. It's configured per request, so you can enable it on the hard step and leave it off elsewhere.

Either way you pay in output tokens and latency, so use it where evaluation shows multi-step errors, not as a blanket setting. Classification, extraction from clean structure and short rewrites rarely benefit. Two cautions matter at Professional level. First, written reasoning is useful for debugging but isn't guaranteed to be a faithful account of how the model reached its answer, so don't treat it as the compliance audit trail; record inputs, retrieved sources, tool calls and outputs. Second, decide deliberately whether end users see the reasoning at all; it can expose internal policy text or confuse people.

Combining techniques and proving them

Real prompts combine techniques: explicit criteria, two or three boundary examples that include short reasoning, and a reasoning section before a structured answer on the one step that needs it. Prompt chaining, splitting a task into sequential calls (extract, then assess, then draft), is often better than one enormous prompt, because each step can be evaluated and tuned on its own, and can run on a different model tier.

Every change is judged against the same evaluation set, with per-category results, because a technique that fixes one class of error can quietly break another. Three hand-picked successes in a notebook are not evidence.

Key concept

Diagnose the failure first: implicit criteria call for a sharper zero-shot prompt, inconsistency on known edge cases calls for a few targeted examples, and multi-step reasoning errors call for reasoning room, each confirmed on an evaluation set.

Questions describe a symptom and offer several techniques. Match technique to symptom, and be wary of options that add cost everywhere (reasoning on every call, dozens of examples) when the failure is narrow.

Practice scenario

ScenarioA procurement team uses Claude to categorize purchase requests into twelve spend categories and route them for approval. Accuracy is good overall, but software subscriptions bought through a reseller are split unpredictably between "Software" and "Professional services". A team member wants to add chain-of-thought to every request and paste in forty labeled examples.
Work it through, then open this

The failure is narrow and judgment-based, not a multi-step reasoning problem, so blanket chain-of-thought adds latency and cost to every request for little benefit. Forty examples raise token cost and risk teaching surface features. First, state the rule explicitly in the prompt (classify by what is delivered, not who invoices). Then add two or three examples at the boundary, including a reseller subscription and a genuine services engagement, each with a one-line reason and varied wording. Measure on the eval set, broken down by category, to confirm the fix and check no other category regressed.

Build exercise — Run a technique ladder against an eval set

Advanced · 45 min

What you’ll learn

  • Writing explicit zero-shot criteria and measuring their effect
  • Selecting boundary examples that generalize
  • Isolating reasoning from the parsed answer and measuring its cost

  1. Build a labeled set of at least 50 inputs for a judgment task, tagged by input category, and run a plain zero-shot prompt. Then rewrite it with explicit criteria and rerun.

    • Why: Explicit criteria are the cheapest fix and often the largest one.
    • You should see: Fewer false positives and a smaller set of residual errors concentrated in a few categories.

  2. For the residual error categories, add two to four examples with varied surface features and one-line reasoning. Rerun and compare per category.

    • Why: Examples work best aimed at the boundary; per-category results reveal regressions an average hides.
    • You should see: The targeted categories improving with the others holding steady; if not, inspect whether an example taught a surface feature.

  3. On one genuinely multi-step task, add a tagged reasoning section before a structured answer (or enable extended thinking), parse only the answer, and record the change in accuracy, output tokens and latency.

    • Why: Reasoning is a cost you should be able to justify with numbers.
    • You should see: A measurable gain on multi-step cases and a clear token and latency cost to weigh against it.

Exam traps

Adding chain-of-thought to every call regardless of whether the task needs reasoning

It adds tokens and latency everywhere. Use it on steps where evaluation shows multi-step errors.

Using many near-identical few-shot examples that teach surface features instead of judgment

The model can learn the shared surface pattern. A few varied boundary examples with reasons generalize better.

Reaching for few-shot before the zero-shot prompt states its criteria explicitly

Examples can’t reliably convey criteria nobody wrote down. Make the rule explicit first.

Parsing the final answer out of free-form reasoning text

It’s brittle. Put reasoning and answer in separate tagged or structured sections and read only the answer.

Treating the model’s written reasoning as a faithful audit trail of how it decided

Reasoning text helps debugging but isn’t guaranteed to reflect the actual decision process. Audit inputs, sources, tool calls and outputs.

Judging a technique change on a handful of hand-picked examples

Use the same eval set with per-category results; improvements in one area can hide regressions in another.

Sources

Quick check

A marketplace uses Claude to assign a condition label (new, refurbished, used, for parts) to listings. The prompt already states explicit criteria and the output format is consistent. On the eval set, nearly all errors are refurbished items labeled as used, and vice versa, often where sellers use informal wording. What is the most appropriate next step?