Cram Sheet — The Day-Before One-Pager

Ask five questions: What is the task? Who chooses the next step? Who executes it? Which component enforces the rule? What evidence proves success?

Use this page to recall ideas you already understand. If a phrase is unclear, open its glossary example before memorizing it.

The one sentence

The model decides; the harness executes. The harness is the software around the model that runs the actions. Every correct answer puts rule enforcement into code that always behaves the same way (gates, hooks, schemas, allowlists, budgets). Prompts are only used to guide the model.

Blueprint (CCAR-F)

Agentic 27 · Claude Code 20 · Prompting/Structured 20 · Tools/MCP 18 · Context/Reliability 15 — 60 questions · 4 of 6 scenarios appear · 120 min · 720/1000 (= the scaled score you need to pass).

Tables to hold in your head

Stop reasons (why the model stopped) → end_turn: give the answer to the user · tool_use: your code runs the tool, then loops back · max_tokens: output is CUT OFF, never parse it · stop_sequence: your custom stop text was reached · refusal: send the case to a human.

Workflow patterns → chain (fixed steps in order) · route (classify, then send to the right handler) · parallel-section (independent parts run at the same time) · parallel-vote (several runs vote, for confidence) · orchestrator–workers (the task is split at run time) · evaluator–optimizer (check against criteria, then improve). Use workflows before agents when the path is known.

MCP primitives → tools = model decides when to use them · resources = app decides · prompts = user decides. One client connects to one server, and the connection keeps state. stdio for local servers · Streamable HTTP for remote servers. Value: N×M custom integrations become N+M.

Claude Code surface → CLAUDE.md memory (shared project instructions plus personal user instructions) = GUIDANCE: the model reads it, usually follows it, no guarantee (same as the API system prompt) · settings permissions + hooks = ENFORCEMENT: Claude Code checks them in code, whatever the model decides (API twin: your harness code, output_config.format) · stem says must/never/always/guarantee/compliance/block → enforcement; conventions/style/know/context → guidance · skills = expertise that the model CHOOSES (by its description) and the harness RUNS · slash commands = templates the user starts ($ARGUMENTS) · subagents = their own separate context + tool policy · hooks = code that always runs the same way (PreToolUse exit-2 blocks the action; PostToolUse changes the result) · settings priority: enterprise > CLI > local-project > shared-project > user · headless claude -p + stream-json for CI.

Output controls: a prompt only asks for a format. tool_choice selects a tool. strict: true enforces the tool's argument schema (supported features only). output_config.format controls the JSON answer text (supported features only). Your code checks that the output is complete and the values are correct. Prefill is an older technique that depends on the model, and you cannot use it together with thinking.

Injection defense → limit the input → treat it as data, not instructions → gates in code that check the output. Layer 3 is the one that really holds.

Caching → the prefix must be byte-identical; put stable content BEFORE the breakpoint and changing content after it; cache reads cost ≈10% of the normal price; loops spread the cost over many calls.

Reliability → 429 (rate limit) / 529 (overloaded) = retry with backoff+jitter (wait longer each time, plus a random delay) · idempotency keys for actions with side effects, so a retry does not repeat them · checkpoints let you resume, never replay from the start · the fallback steps end in honest failure · Batch API for large offline volume · pin model versions in production · add monitoring before you try to fix things.

Multi-agent → subagents exist to keep CONTEXT SEPARATE; they return summaries; run reads in parallel and writes one at a time; hub-and-spoke (a coordinator in the center); know when one loop is enough.

The six scenarios in one line each

S1 support: escalation is a planned final path; anything with money = gate + HITL (a human approves). S2 team Claude Code: guarantees come from hooks, standards come from the project CLAUDE.md. S3 research: a coordinator + subagents that return summaries. S4 dev tooling: Bash allowlists with a narrow scope; Grep/Glob only read. S5 CI/CD: headless + least privilege; block a merge only on checks that always give the same result. S6 extraction: a forced schema tool + stop_reason check + closed schema.

Exam mechanics

About 90 s per question, after 1 min to read each scenario · flag hard questions and move on · "most appropriate" = Anthropic's published guidance (the simplest solution, workflows first, enforcement in code) · read the constraint sentence again before you answer · keep 10 min at the end for review.

Night-before checklist

Pearson VUE system test done · ID ready · wired internet · clean desk · water · sleep is worth more than studying past this page.

Named features added from the official exam guide (v0.2) — last-pass list

• Task tool starts subagents. The coordinator's allowedTools must include "Task": the list pre-approves tools, and in an unattended run nobody answers a permission prompt, so an unlisted Task call is denied (the list does not remove other tools). Subagents get NO context from the coordinator, so pass the findings in their prompt. To run them in parallel, make several Task calls in ONE response.
• --resume <name> = continue a named session (tell it which files changed); fork_session = start parallel branches from one shared starting point; if tool results are out of date → start a fresh session and add a summary to it.
• Plan mode = for architecture changes, many files, or several valid approaches; direct execution = for small fixes in one file; Explore subagent = keeps long search output out of the main context.
• .claude/rules/ + YAML paths: globs = rules that apply to file patterns anywhere in the tree (for example, all test files); a nested CLAUDE.md = only one folder and its subfolders; skill frontmatter: context: fork (separate context), allowed-tools (pre-approves the listed tools; it does not limit them — to restrict, use a subagent's tools: or permissions.deny), argument-hint (tells the user which arguments to give).
• CI flags: claude -p (non-interactive), --output-format json, --json-schema (structured findings). Review with an INDEPENDENT session, and give it the earlier findings so it does not report them twice.
• Batches API: 50% cost · finishes within 24h · no SLA · does not run a multi-turn tool loop for you · match results with custom_id · resend only the failed requests · plan enough time for completion and retries; check the deadline you promised · never use it for checks that must block a merge.
• MCP errors: isError + errorCategory (transient/validation/business/permission) + isRetryable + a description a human can read. An access failure is not the same as a valid empty result. Retry locally first; if that fails, pass the error up with any partial results.
• Schemas: nullable fields stop the model from inventing values; use enum + "other"+detail + "unclear"; supported strict output features enforce the shape; the harness checks facts and business values (calculated_total vs stated_total).
• Context: models lose facts in the middle of long input → put key findings at the TOP and use section headers; cut tool outputs down to the needed fields; keep a "case facts" block outside the summarized history; use scratchpad files; the coordinator loads crash-recovery manifests.
• Review routing: measure accuracy per document type and per field before you trust overall numbers; take stratified samples even from high-confidence output; calibrate confidence on labeled data sets; keep claim→source links through the final summary; mark conflicts with their sources; add dates to data that changes over time.