Table of Contents

Click any entry to jump straight to it. You can also use the sidebar on the left at any time, filter chapters with the search box, and move with the ← / → arrow keys.

How to Use This Guide

This is a self-contained study package. You do not need any other document to prepare for the exam: everything you need to learn the material is written out in full below: concepts, working examples, common failure modes, and practice questions with explanations. The only things this guide can't replace are hands-on repetitions with the actual Claude Agent SDK, Claude Code, and Claude API: the exam is written to test judgment that comes from having actually built with these tools, so treat the "Hands-On Exercises" in each domain as mandatory, not optional.

The guide is organized as:

1. Exam overview: format, scoring, logistics (this section)
2. A structured learning plan: a suggested schedule
3. Five domain chapters: one per exam domain, each covering every task statement in depth, with worked examples and domain-specific practice questions
4. Deep walkthroughs of all 6 official exam scenarios
5. The 12 official sample questions (reproduced from the exam guide with explanations) plus a 50-question original practice exam with a full answer key
6. Quick-reference cheat sheets: one page per domain for final review
7. A footnote of external resources for further study
8. Five appendices: a technical-foundations reference (the concrete API/SDK/MCP/Claude Code artifacts you must recognize on screen), consolidated tradeoff decision tables, a guide to reading exam questions and eliminating distractors, a full glossary, and an exam-readiness self-assessment checklist

1. Exam Overview

1.1 What This Certification Validates

The Claude Certified Architect - Foundations certification validates that you can make informed decisions about tradeoffs when implementing real-world solutions with Claude. It is scenario-based and judgment-heavy. It is not a trivia test about API syntax. It tests foundational knowledge across four technology areas:

• Claude Code: the CLI-based coding agent and its configuration system
• The Claude Agent SDK: the framework for building autonomous and multi-agent systems
• The Claude API: the underlying Messages API, tool use, and structured output mechanisms
• Model Context Protocol (MCP): the standard for exposing tools and resources to Claude

Questions are grounded in realistic production scenarios: a customer support resolution agent, a multi-agent research pipeline, Claude Code integrated into CI/CD, developer productivity tooling, and structured data extraction. You're expected to reason about architecture, configuration, and tradeoffs the way an experienced solution architect would, not just recall facts.

1.2 Intended Candidate

The ideal candidate has 6+ months of hands-on experience:

• Building agentic applications with the Claude Agent SDK (multi-agent orchestration, subagent delegation, tool integration, lifecycle hooks)
• Configuring Claude Code for teams (CLAUDE.md, Agent Skills, MCP integrations, plan mode)
• Designing MCP tool/resource interfaces for backend integration
• Engineering prompts for reliable structured output (JSON schemas, few-shot examples, extraction patterns)
• Managing context windows across long documents, multi-turn conversations, and multi-agent handoffs
• Integrating Claude into CI/CD for code review, test generation, PR feedback
• Making escalation and reliability decisions (error handling, human-in-the-loop, self-evaluation)

1.3 Exam Details at a Glance

1.4 Exam Blueprint (Content Domains and Weights)

Domain 1 (Agentic Architecture) carries the most weight. Spend proportionally more study time there. Domains 3 and 4 are tied for second. Domain 2 and Domain 5 are lighter but still each represent roughly 1 in 6 (Domain 2) or 1 in 7 (Domain 5) questions. Don't skip them.

1.5 How Scoring Works

1.6 Exam Logistics

• Registration: via the Anthropic Partner Academy, delivered through Pearson VUE. Review the Exam Guide, Certification Terms and Conditions, and Certification Exam Policy before registering.
• Scheduling: create a Pearson VUE account after checkout; choose online proctoring or a test center. You can reschedule/cancel up to 24 hours before your appointment without penalty; changes inside 24 hours forfeit the fee.
• ID requirement: valid, unexpired, government-issued photo ID matching your registration name exactly.
• Retake policy: waiting periods of 14 days (after 1st fail), 30 days (after 2nd), 90 days (after 3rd). Maximum 4 attempts per 12-month rolling period. Fee applies each attempt.
• No-show/late arrival: forfeits the fee; you must re-register.
• Conduct: proctor/webcam visibility required (online), clear workspace, no communication with others, no capturing/reproducing exam content. Violations can void your result and revoke your credential.
• NDA: you must accept a confidentiality/non-disclosure agreement before the exam starts; declining ends the session with no refund.
• Recertification: credential is valid 12 months. On-time renewal = a free, non-proctored assessment reviewing what changed. Lapsed credentials require a full retake at full fee. If exam content changes significantly, Anthropic may require a full retake instead of the lighter renewal path.

1.7 In-Scope vs. Out-of-Scope (per the official guide)

Explicitly tested: agentic loop implementation (stop_reason-driven control flow), multi-agent orchestration (coordinator-subagent, decomposition, parallelism, iterative refinement), subagent context management, tool interface design, MCP tool/resource design and server configuration, error handling/propagation, escalation decision-making, CLAUDE.md configuration hierarchy, custom commands/skills, plan mode vs. direct execution, iterative refinement techniques, structured output via tool_use, few-shot prompting, batch processing, context window optimization, human review workflows, information provenance.

Explicitly out of scope: fine-tuning/training custom models, API authentication/billing/account management, language/framework-specific implementation details, deploying/hosting MCP servers (infra/networking/containers), Claude's internal architecture/training/model weights, Constitutional AI/RLHF, embeddings/vector databases, computer use (browser/desktop automation), vision/image analysis, streaming API implementation, rate limiting/quotas/pricing, OAuth/API key rotation, cloud-provider-specific configuration, benchmarking, prompt caching internals (just knowing it exists is enough), tokenization details.

2. Learning Plan

This plan assumes ~6 weeks at 4-6 hours/week (24-36 hours total), which is a reasonable pace for someone who already has some hands-on exposure to Claude but wants to fill gaps and drill scenario-style judgment questions. Compress it into 2-3 weeks if you're already deep in daily use of the Agent SDK and Claude Code; stretch it to 8-10 weeks if you're starting closer to zero hands-on experience.

Week 1 - Domain 1: Agentic Architecture & Orchestration (highest weight, 27%) Read Domain 1 in full below. Build a minimal agentic loop by hand (even a toy one) so the stop_reason lifecycle is intuitive, not memorized. Do Preparation Exercise 1 (multi-tool agent with escalation logic, described in Domain 1 and Domain 5 sections). Answer the Domain 1 practice questions.

Week 2 - Domain 2: Tool Design & MCP Integration (18%) Read Domain 2 in full. Write tool descriptions for 3-4 tools, deliberately including two with overlapping purposes, then rewrite them to disambiguate. Configure a .mcp.json with an environment-variable-expanded token. Do Preparation Exercise 2's MCP portions. Answer the Domain 2 practice questions.

Week 3 - Domain 3: Claude Code Configuration & Workflows (20%) Read Domain 3 in full. Set up a CLAUDE.md hierarchy (user, project, directory) on a real or sample repo. Create at least one path-scoped rule in .claude/rules/ and one skill in .claude/skills/ using context: fork. Practice distinguishing plan-mode-appropriate tasks from direct-execution tasks using the criteria in this guide. Answer the Domain 3 practice questions.

Week 4 - Domain 4: Prompt Engineering & Structured Output (20%) Read Domain 4 in full. Build a small extraction pipeline using tool_use with a JSON schema containing at least one nullable field and one enum-with-"other" field. Implement one validation-retry loop. Answer the Domain 4 practice questions.

Week 5 - Domain 5: Context Management & Reliability (15%) + Scenario Deep Dives Read Domain 5 in full. Read all 6 official scenario walkthroughs below and, for each, try to predict what kinds of questions would be asked before reading the analysis. Answer the Domain 5 practice questions.

Week 6: Integration and Practice Exams Take the 50-question practice exam under timed conditions (aim for ~2 minutes/question to simulate the real 120-minute/60-item pace). Review every missed question against the relevant domain chapter. Re-read the cheat sheets the day before your exam. Do a final pass over the official sample questions and their explanations: these are the closest thing to "released" exam items you have.

Agentic Loops & Multi-Agent Coordination

This is the largest domain and the conceptual core of the exam. It covers how an agent decides what to do next (the agentic loop), how multiple agents coordinate, how context flows between them, how workflows enforce ordering, how hooks intercept the loop deterministically, how work gets decomposed, and how sessions persist and fork. Almost every scenario on the exam touches this domain.

3.1 Task Statement: Design and implement agentic loops for autonomous task execution

This is the entire lifecycle. The critical exam-relevant details:

• stop_reason is the control signal, not the assistant's text content. The loop continues because stop_reason is "tool_use", not because the text "looks like" it's asking for more information or because the model said something like "let me check that."
• Tool results must be appended to conversation history as their own message (role "user" with tool_result content blocks referencing the tool_use_id) so that the next API call gives Claude the full context to reason about what to do next. Without this, Claude has no memory of what the tool returned.
• Model-driven decision-making vs. pre-configured sequences. The agentic loop pattern lets Claude decide which tool to call next based on the current state of the conversation: this is different from a hard-coded decision tree where your application code decides the next step. The power (and the risk) of agentic loops is that the model is in the driver's seat for sequencing, which is why enforcement mechanisms (Task Statement 1.4, 1.5) matter for steps that must not be skipped.

Pseudocode for a correct agentic loop:

messages = [{"role": "user", "content": user_input}]

while True:
    response = client.messages.create(
        model="claude-...",
        max_tokens=4096,
        tools=tool_definitions,
        messages=messages,
    )
    messages.append({"role": "assistant", "content": response.content})

    if response.stop_reason == "tool_use":
        tool_results = []
        for block in response.content:
            if block.type == "tool_use":
                result = execute_tool(block.name, block.input)
                tool_results.append({
                    "type": "tool_result",
                    "tool_use_id": block.id,
                    "content": result,
                })
        messages.append({"role": "user", "content": tool_results})
        continue  # loop again so Claude can see the results

    if response.stop_reason == "end_turn":
        return extract_text(response.content)  # done

3.2 Task Statement: Orchestrate multi-agent systems with coordinator-subagent patterns

Hub-and-spoke architecture. In a coordinator-subagent design, one coordinator agent is the hub; all subagents are spokes. The coordinator:

• Decomposes the incoming task into subtasks
• Decides which subagents to invoke (not all systems need every subagent every time: a query-complexity-aware coordinator dynamically selects a subset)
• Routes all inter-subagent communication through itself (subagents don't talk directly to each other)
• Aggregates results from subagents into a final answer
• Owns error handling for subagent failures (see Domain 5, Task 5.3)

This centralization is a deliberate architectural choice: it gives you a single place to observe, log, and control the system, and a single place to implement consistent error handling and information routing, rather than scattering that logic across every subagent pair.

Skills to internalize:

• Dynamic subagent selection. Don't always invoke the full pipeline (search → analyze → synthesize → report) regardless of the query. A coordinator should analyze what the query actually requires and invoke only the necessary subagents.
• Partitioning to minimize duplication. When multiple subagents search or analyze, assign each a distinct subtopic, source type, or angle rather than letting them redundantly cover the same ground.
• Iterative refinement loops. A coordinator should be able to evaluate the synthesis output for gaps, re-delegate to search/analysis subagents with targeted follow-up queries addressing the specific gap, and re-invoke synthesis, rather than treating the pipeline as strictly one-shot/one-directional.
• Routing everything through the coordinator, even when it would be technically possible for two subagents to communicate directly, because centralized routing preserves observability and consistent error handling.

3.3 Task Statement: Configure subagent invocation, context passing, and spawning

Context must be passed explicitly. Because subagents don't inherit the parent's context (3.2), the coordinator's prompt to each subagent must contain everything that subagent needs: e.g., the actual text of prior findings, not just a reference like "use the results from earlier." Concretely: when invoking a synthesis subagent, the coordinator includes the actual web-search results and document-analysis outputs directly in the synthesis subagent's prompt.

Preserve attribution with structured data. When passing multiple prior agents' findings into a new subagent's prompt, don't just concatenate raw text. Use a structured format that separates content (the claim/finding) from metadata (source URL, document name, page number) so that downstream synthesis can still attribute claims correctly. Example:

{
  "findings": [
    {
      "claim": "Global e-commerce grew 9% YoY in 2025.",
      "source_url": "https://example.com/report-2025",
      "source_name": "Industry Report 2025",
      "page": 12,
      "collected_date": "2026-02-01"
    }
  ]
}

AgentDefinition configuration. Each subagent type is configured with a description (used partly for the coordinator/model to understand its purpose), a system prompt (its role and instructions), and tool restrictions (which tools it's allowed to use: see Domain 2, Task 2.3, on scoping tools per role).

Parallel spawning. To run subagents in parallel rather than sequentially, the coordinator emits multiple Task tool calls within a single response/turn, rather than issuing them across separate turns (which would force sequential round-trips). This is a concrete latency lever: sequential subagent calls compound their latency; parallel calls run concurrently.

Fork-based session management. fork_session lets you create an independent branch of a session from a shared baseline: useful when you want to explore two divergent approaches (e.g., two different refactoring strategies) that both start from the same prior analysis, without either branch polluting the other or forcing you to redo the shared analysis twice. (See also Task 1.7.)

Goal-oriented vs. procedural subagent prompts. Coordinator prompts to subagents should generally specify the research goals and quality criteria ("find at least 3 credible sources per subtopic, prioritizing peer-reviewed or primary sources") rather than rigid step-by-step procedures. This gives the subagent room to adapt its approach to what it actually finds, rather than following a script that may not fit the situation.

Workflows, Hooks & Session Management

3.4 Task Statement: Implement multi-step workflows with enforcement and handoff patterns

Multi-concern decomposition. A single customer message might bundle multiple distinct issues (a billing question and a shipping complaint). The correct pattern is to decompose the request into its distinct items, investigate each (in parallel where possible, sharing context so investigations don't duplicate work), and then synthesize one unified response, rather than answering only the first-mentioned issue or looping through them so mechanically that the reply reads disjointed.

3.5 Task Statement: Apply Agent SDK hooks for tool call interception and data normalization

• PostToolUse hooks run after a tool returns, before the model sees the result. Use them to normalize heterogeneous data coming back from different tools/backends, e.g., one MCP tool returns Unix timestamps, another returns ISO 8601 strings, another returns numeric status codes; a PostToolUse hook can convert all of these into one consistent shape before Claude ever reasons over them. This reduces model confusion and errors that stem from inconsistent formats, not model reasoning failures.
• Tool-call interception hooks run before a tool executes and can block it outright. Use these to enforce hard business rules deterministically, e.g., intercept process_refund calls and block any refund above $500, redirecting the flow to a human-escalation path instead of letting the tool execute.
• Choosing hooks over prompts. As in Task 1.4: whenever a business rule must be guaranteed, not just "usually followed," hooks are the correct mechanism. Prompts are probabilistic; hooks are deterministic code that runs regardless of what the model "decided."

3.6 Task Statement: Design task decomposition strategies for complex workflows

Two decomposition patterns, and knowing which fits which situation is a recurring exam judgment call:

• Prompt chaining (fixed sequential pipeline). Best for predictable, multi-aspect work where the steps are known in advance, e.g., a code review broken into "review file A," "review file B," …, "review file N," then a final "cross-file integration pass" that looks at how the files interact. The steps don't change based on what's found; only the content being processed changes.
• Dynamic/adaptive decomposition. Best for open-ended investigation where you don't know the right subtasks until you've learned something about the problem, e.g., "add comprehensive tests to a legacy codebase" starts with mapping the codebase's structure, then identifying high-impact/high-risk areas, and only then building a prioritized task plan, a plan that itself may need to adapt as new dependencies are discovered mid-execution.

3.7 Task Statement: Manage session state, resumption, and forking

• --resume <session-name>: continue a specific, named prior conversation. Best when the prior context is still valid, e.g., resuming a long investigation the next morning where nothing relevant has changed.
• fork_session: branch off an independent copy of a session from a shared baseline, to explore two (or more) divergent approaches without one branch's changes affecting the other, e.g., comparing "migrate to library X" vs. "migrate to library Y" starting from the same codebase-analysis baseline.
• Stale tool results after external changes. If files were modified outside the session (e.g., a teammate pushed changes) since the session last read them, resuming naively risks the agent reasoning over stale information. Two correct responses: (a) explicitly tell the resumed session which specific files changed, so it does a targeted re-analysis rather than needing to re-explore everything from scratch, or (b) if enough of the prior context is now invalid, start a fresh session and inject a structured summary of what's still true, rather than resuming and hoping the agent notices staleness on its own. The exam favors "start fresh with an injected structured summary" over "resume and hope the stale tool results don't cause a problem" when a large fraction of the prior state is now invalid.

Domain 1: Practice Questions

4. Domain 2: Tool Design & MCP Integration (18%)

This domain covers how to design tool interfaces so an LLM reliably picks the right one, how to build structured error handling into tools, how to distribute tools across agents (and configure tool_choice), how to integrate MCP servers into Claude Code and agent workflows, and when to reach for built-in tools (Read/Write/Edit/Bash/Grep/Glob).

4.1 Task Statement: Design effective tool interfaces with clear descriptions and boundaries

What a good tool description includes: - The tool's purpose, stated specifically (not just a restatement of its name) - Expected input formats (e.g., "accepts an order number in the format ORD-##### or a tracking number") - Example queries that should route to this tool - Edge cases and boundaries: explicitly stating what this tool is not for, and how it differs from similarly named/purposed tools

Common misrouting causes and fixes: - Near-identical descriptions on different tools (e.g., analyze_content vs. analyze_document): fix by renaming for clarity and rewriting descriptions to be mutually exclusive (e.g., rename analyze_content to extract_web_results with a web-specific description). - A generic, overloaded tool trying to do too much (e.g., a single analyze_document tool used for extraction, summarization, and verification): fix by splitting it into purpose-specific tools with clear input/output contracts: extract_data_points, summarize_content, verify_claim_against_source. - System-prompt keyword sensitivity: sometimes the system prompt itself (not the tool description) contains wording that creates unintended associations, causing a tool to be over- or under-selected. Always review the system prompt for keyword collisions when debugging tool-selection issues, not just the tool descriptions in isolation.

4.2 Task Statement: Implement structured error responses for MCP tools

The isError flag. MCP's pattern for signaling tool failure back to the agent is a structured isError: true (or equivalent) flag in the tool result, rather than the tool result silently looking like a normal (if unhelpful) response.

Error categories matter. Not all failures are the same, and lumping them together prevents the agent from making good recovery decisions:

Recommended error payload shape:

{
  "isError": true,
  "errorCategory": "business",
  "isRetryable": false,
  "message": "This refund exceeds the $500 self-service threshold and requires manager approval.",
}

Local recovery before propagation. Within a subagent, transient errors should generally be retried/recovered locally first. Only errors the subagent cannot resolve on its own should propagate up to the coordinator, and when they do, they should include partial results and a description of what was attempted, not just a bare failure signal (this connects directly to Domain 5, Task 5.3).

4.3 Task Statement: Distribute tools appropriately across agents and configure tool choice

Cross-specialization misuse. An agent given tools outside its specialization tends to misuse them, e.g., a synthesis agent that has full web-search tools available may attempt ad hoc searches instead of staying focused on synthesis, duplicating or conflicting with the dedicated search agent's work.

Scoped cross-role tools for high-frequency needs. Sometimes an agent legitimately needs some capability from another role's domain frequently enough that routing every instance through the coordinator is wasteful. The fix isn't "give it the whole toolset", it's giving it one narrowly scoped tool for that specific high-frequency need (e.g., a verify_fact tool for a synthesis agent that often needs quick fact-checks), while still routing rarer/more complex cases of that need through the coordinator to the full search agent.

tool_choice configuration options: - "auto": the model may choose to call a tool or just respond with text. Use when you want the model to decide. - "any": the model must call some tool (any of the available ones), but can pick which. Use when you need to guarantee a tool call happens (e.g., guaranteeing structured output rather than risking a plain-text reply). - Forced tool choice, {"type": "tool", "name": "extract_metadata"}: the model must call this specific named tool. Use when a particular step must run first (e.g., forcing extract_metadata before any enrichment tools can run), then handling subsequent steps in follow-up turns once that tool's output is available.

4.4 Task Statement: Integrate MCP servers into Claude Code and agent workflows

Scoping: project vs. user. - Project-level (.mcp.json in the repo root): shared team tooling, version-controlled, everyone on the project gets the same servers. - User-level (~/.claude.json): personal or experimental servers, not shared with teammates. - Both scopes are discovered and available simultaneously: a developer sees their personal experimental server and the shared project servers at the same time.

Environment variable expansion. .mcp.json supports variable expansion (e.g., ${GITHUB_TOKEN}) so that credentials are supplied via environment variables at runtime rather than being committed to the repo in plaintext. Example:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_TOKEN": "${GITHUB_TOKEN}" }
    }
  }
}

Tool discovery. Tools from all configured MCP servers (project + user scope) are discovered at connection time and made available to the agent simultaneously: there isn't a separate activation step per server once connected.

MCP resources vs. tools. Tools represent actions the agent can invoke; resources represent content the agent can browse/reference, like a catalog of issue summaries, a documentation hierarchy, or a database schema. Exposing a content catalog as an MCP resource (rather than forcing the agent to make exploratory tool calls to discover what exists) reduces wasted round-trips and helps the agent understand what's available up front.

Description quality drives adoption. If an MCP tool's description is thin, the agent may default to a built-in tool it already trusts (e.g., using Grep to search code text instead of a purpose-built, more capable MCP indexing/search tool) simply because the built-in tool's behavior is better understood by the model. Enhancing MCP tool descriptions, explaining capabilities and expected outputs in detail, helps the agent actually prefer the more capable tool when appropriate.

Build vs. buy. For standard integrations (e.g., Jira, GitHub, Slack), prefer existing community MCP servers over building your own from scratch. Reserve custom MCP server development for genuinely team-specific or proprietary workflows that no existing server covers.

4.5 Task Statement: Select and apply built-in tools (Read, Write, Edit, Bash, Grep, Glob) effectively

Edit failure fallback. If Edit cannot find a unique match for its anchor text (e.g., the text you want to replace appears multiple times in the file), the reliable fallback is Read the full file, then Write the modified version back: rather than repeatedly trying slightly different anchor strings.

Incremental codebase understanding. Don't read every file upfront. The efficient pattern is: start with Grep to locate entry points or relevant symbols, use Read to follow imports and trace execution flow from there, and expand only as needed. This keeps context usage proportional to what's actually relevant.

Tracing usage across wrapper/re-export modules. To find all callers of a function that's re-exported under different names in various modules, first identify all the exported names it might be imported as, then Grep for each of those names across the codebase: a single Grep for the original name will miss call sites that import it under an alias or a wrapper.

Domain 2: Practice Questions

5. Domain 3: Claude Code Configuration & Workflows (20%)

This domain covers configuring Claude Code for teams: the CLAUDE.md hierarchy, custom slash commands and skills, path-specific rules, plan mode vs. direct execution, iterative refinement techniques, and CI/CD integration.

5.1 Task Statement: Configure CLAUDE.md files with appropriate hierarchy, scoping, and modular organization

The three-level hierarchy: - User-level: ~/.claude/CLAUDE.md: applies only to that individual user, on their machine. Not shared via version control. If instructions live only here, teammates never see them. - Project-level: .claude/CLAUDE.md or a root CLAUDE.md: version-controlled, applies to everyone who works on the project. - Directory-level: a CLAUDE.md placed in a specific subdirectory: applies when working in that subdirectory (e.g., package-specific conventions in a monorepo).

@import syntax. Lets a CLAUDE.md reference external files rather than duplicating content, keeping configuration modular, e.g., each package's CLAUDE.md can @import only the standards files relevant to that package's maintainers, instead of a single, unwieldy monolith covering every package's conventions at once.

.claude/rules/ as an alternative to one giant CLAUDE.md. Rather than a single sprawling CLAUDE.md file, you can split topic-specific content into individual files inside .claude/rules/ (e.g., testing.md, api-conventions.md, deployment.md). This keeps each concern focused and independently maintainable (and, per Task 3.3, .claude/rules/ files can also carry path-scoping so they only load when relevant).

The /memory command. Use it to inspect which memory/configuration files are actually loaded in the current session: this is the correct diagnostic tool when behavior is inconsistent across sessions or across team members, rather than guessing at what might be misconfigured.

5.2 Task Statement: Create and configure custom slash commands and skills

Slash commands: project vs. user scope. - .claude/commands/ (in the repo): project-scoped, version-controlled, shared with the whole team automatically when they clone/pull. - ~/.claude/commands/: user-scoped, personal, not shared.

If a task says "every developer should get this command automatically when they clone the repo," the answer is .claude/commands/ in the project, full stop, not a config file that doesn't exist (there is no .claude/config.json commands array), and not CLAUDE.md (which holds context/instructions, not command definitions).

Skills. Live in .claude/skills/ with a SKILL.md file that supports frontmatter configuration: - context: fork: runs the skill in an isolated sub-agent context so its (possibly verbose) output doesn't pollute the main conversation. Use this for skills that produce a lot of exploratory or intermediate content (e.g., a full codebase-analysis skill, or a brainstorming skill that considers many discarded alternatives): you want the conclusion, not the scratch work, in your main session. - allowed-tools: restricts which tools are available while the skill runs (e.g., limiting a "generate documentation" skill to file-write operations only, so it structurally cannot perform destructive actions like deleting files). - argument-hint: prompts the developer for required parameters when they invoke the skill without arguments, improving usability.

Personal skill variants. A developer can create a personalized variant of a shared skill in ~/.claude/skills/ under a different name, customizing it to their own preferences without affecting teammates who use the shared, project-scoped version.

5.3 Task Statement: Apply path-specific rules for conditional convention loading

.claude/rules/ with YAML frontmatter paths globs. Each rule file can declare which file paths it applies to, e.g.:

---
paths: ["src/api/**/*"]
---
# API conventions
Use async/await. Return typed error objects. ...

The rule loads into context only when Claude is working with a file matching that glob, keeping irrelevant conventions out of context the rest of the time (reducing token usage and noise).

Why glob-based rules beat directory-level CLAUDE.md for cross-cutting conventions. Directory-level CLAUDE.md is directory-bound: it applies to files physically located in that directory tree. But some conventions cut across the whole codebase by file type, not by location, e.g., test files (Button.test.tsx sitting right next to Button.tsx) are scattered everywhere. A directory-level CLAUDE.md can't cleanly express "apply this rule to every test file no matter where it lives", but a .claude/rules/ file with paths: ["**/*.test.tsx"] can, because it matches by pattern, not by physical location.

5.4 Task Statement: Determine when to use plan mode vs. direct execution

Plan mode is for: - Large-scale changes touching many files - Situations with multiple valid approaches that need to be weighed - Architectural decisions (e.g., service boundaries in a monolith-to-microservices migration) - Anything where exploring and designing before committing avoids costly rework

Direct execution is for: - Simple, well-scoped changes with a clear, singular path (e.g., adding one validation check to one function, a single-file bug fix with a clear stack trace)

Explore subagent. For verbose discovery/investigation phases (e.g., "map this legacy codebase"), delegate to the Explore subagent so the verbose exploration output stays isolated, and only a summary comes back to the main conversation: this prevents context window exhaustion during multi-phase tasks, similar in spirit to context: fork for skills.

Combining modes. It's entirely valid to use plan mode for the investigation/design phase, then switch to direct execution to implement the now-agreed-upon plan: plan mode and direct execution aren't mutually exclusive across an entire task; they can be sequenced.

5.5 Task Statement: Apply iterative refinement techniques for progressive improvement

• Concrete input/output examples are the most effective way to communicate an expected transformation when prose descriptions alone produce inconsistent results. If you've described a transformation in words and gotten inconsistent output, the fix is 2-3 concrete before/after examples, not a longer paragraph of prose.
• Test-driven iteration. Write a test suite (expected behavior, edge cases, performance requirements) before implementation, then iterate by sharing test failures with Claude to guide progressive correction: this gives concrete, falsifiable feedback rather than vague "this doesn't look right" comments.
• The interview pattern. Before implementing something in an unfamiliar domain, have Claude ask you questions first to surface considerations you might not have thought of (e.g., cache invalidation strategy, failure modes): this front-loads design thinking instead of discovering gaps mid-implementation.
• Batching vs. sequencing fixes. If multiple issues interact with each other (fixing one changes the right fix for another), address them together in a single detailed message. If issues are independent, fix them sequentially, one at a time, so each fix can be verified in isolation.

5.6 Task Statement: Integrate Claude Code into CI/CD pipelines

• -p / --print flag: runs Claude Code in non-interactive mode: it processes the prompt, prints the result, and exits, instead of waiting for interactive input (which would hang a CI job indefinitely). This is the fix whenever a pipeline script "hangs waiting for input."
• --output-format json plus --json-schema: enforce machine-parseable structured output so CI tooling can reliably parse findings (e.g., to post them as inline PR comments) without fragile text-scraping.
• CLAUDE.md for CI context. The same CLAUDE.md mechanism used interactively also feeds project context (testing standards, fixture conventions, review criteria) to Claude Code when it's invoked non-interactively in CI.
• Session/context isolation for review. A Claude session that just generated some code is less effective at critically reviewing that same code than an independent session with no prior reasoning context, because the generating session tends to retain (and defend) its own reasoning rather than scrutinizing it fresh. For CI code review, use a separate, independent invocation rather than having the same session that wrote the diff also review it.
• Avoiding duplicate PR comments across re-runs. When re-running a review after new commits, include the prior review findings in context and instruct Claude to report only new or still-unaddressed issues: otherwise every re-run re-flags everything from scratch.
• Avoiding low-value/duplicate generated tests. Provide the existing test files in context during test-generation so Claude doesn't propose scenarios already covered, and document testing standards, valuable-test criteria, and available fixtures in CLAUDE.md to raise the baseline quality of generated tests.

Domain 3: Practice Questions

6. Domain 4: Prompt Engineering & Structured Output (20%)

This domain covers writing prompts that reduce false positives, using few-shot examples effectively, enforcing structured output via tool_use and JSON schemas, validation-retry loops, batch processing strategy, and multi-pass/multi-instance review architectures.

6.1 Task Statement: Design prompts with explicit criteria to improve precision and reduce false positives

False positives erode trust unevenly. If one category of finding has a high false-positive rate, it damages developer trust in all categories, including accurate ones. A pragmatic interim fix while you improve the prompt: temporarily disable the high-false-positive category rather than let it erode confidence in everything else.

Severity classification needs concrete examples per level, not just adjectives ("critical," "major," "minor"): pair each severity level with a concrete code example so classification is consistent across different reviewers/runs.

6.2 Task Statement: Apply few-shot prompting to improve output consistency and quality

When to reach for few-shot examples: when detailed prose instructions alone produce inconsistent formatting or judgment. Few-shot examples are the most effective lever for: - Achieving consistent output format (e.g., always: location, issue, severity, suggested fix) - Demonstrating ambiguous-case handling, e.g., which tool to pick when a request could plausibly go to either of two tools, or what counts as a real branch-coverage gap vs. an acceptable one - Reducing hallucination in extraction tasks, e.g., correctly handling informal units ("about a dozen" vs. "12"), or varied document structures (inline citations vs. a bibliography)

Good few-shot examples show reasoning, not just input→output. 2-4 targeted examples for genuinely ambiguous scenarios, ideally each showing why one action was chosen over a plausible alternative: this helps the model generalize the underlying judgment to novel cases it hasn't seen, rather than just pattern-matching the literal examples.

Distinguishing acceptable patterns from genuine issues. Include examples of code/patterns that look like they might be flaggable but are actually fine, alongside examples of genuine issues: this reduces false positives while still letting the model generalize (as opposed to a purely negative list of "don't flag X," which doesn't generalize to X-like-but-not-identical cases).

6.3 Task Statement: Enforce structured output using tool use and JSON schemas

tool_use + JSON schema is the most reliable path to guaranteed schema-compliant output. It structurally eliminates JSON syntax errors (malformed brackets, missing commas, etc.) because the model is filling a schema-constrained tool input, not free-typing JSON text that could be malformed.

tool_choice recap in the extraction context: - "auto": model might reply with plain text instead of extracting; not appropriate when you need guaranteed structured output. - "any": model must call some tool; use this when you have multiple possible extraction schemas and don't yet know the document type, letting the model pick the applicable one but still guaranteeing a structured call happens. - Forced tool choice ({"type": "tool", "name": "extract_metadata"}): use to guarantee a specific extraction runs first, before enrichment steps that depend on its output.

Schema design principles: - Optional/nullable fields for information that may genuinely be absent from the source document. If a field is marked required but the source doesn't contain that data, the model is incentivized to fabricate a value just to satisfy the schema. Making the field nullable lets the model correctly return null instead of inventing data. - Enum + "other" + detail-string pattern for categorical fields that need to stay extensible: category: enum["invoice", "receipt", "other"] plus category_other_detail: string | null lets you capture novel categories without either rejecting them or forcing a bad-fit enum value. Similarly, an "unclear" enum value handles genuinely ambiguous cases honestly instead of forcing a false-confidence pick. - Format normalization instructions belong alongside the schema (in the prompt), since the schema defines shape but doesn't by itself normalize inconsistent source formatting (e.g., different date formats across documents): you still need to instruct the model on how to normalize into the schema's expected format.

6.4 Task Statement: Implement validation, retry, and feedback loops for extraction quality

Retry-with-error-feedback pattern. When a validation check fails (e.g., a Pydantic model or JSON Schema validator rejects the output), send a follow-up request that includes: the original document, the failed extraction, and the specific validation error message: this gives the model concrete, actionable feedback to self-correct, rather than just re-asking the same question and hoping for a different (better) random result.

Feedback loops for systematic pattern analysis. Add a detected_pattern field to structured findings so that when developers dismiss/reject a finding, you can later analyze which code constructs or patterns are systematically triggering false positives, turning ad hoc dismissals into a data-driven prompt-improvement signal.

Self-correction / discrepancy-detection design. For financial-style extraction, extract both a calculated_total (computed from line items) and a stated_total (as written in the document) as separate fields, so a mismatch between them is automatically flagged rather than silently trusting whichever value the model happened to output. Similarly, a conflict_detected: boolean field can flag when source data is internally inconsistent, prompting downstream handling rather than silent pass-through.

6.5 Task Statement: Design efficient batch processing strategies

Message Batches API characteristics: - 50% cost savings vs. real-time/synchronous calls - Processing window up to 24 hours: no guaranteed latency SLA (it might finish much sooner, but you cannot rely on that) - No multi-turn tool calling within a single batch request: you cannot execute a tool mid-request and feed the result back within the same batch call; batch requests are effectively single-shot - custom_id fields let you correlate each response back to its corresponding request

SLA math. If you have a downstream SLA (e.g., "results must be ready within 30 hours of document arrival") and batch processing can take up to 24 hours, you need to calculate submission frequency so that the worst-case batch completion time still meets the SLA, e.g., submitting every 4 hours leaves a 24-hour batch window plus buffer, comfortably inside a 30-hour SLA; submitting less frequently might not.

Failure handling. When some documents in a batch fail, identify them by custom_id and resubmit only the failed ones, with appropriate modifications, e.g., chunking a document that exceeded context limits before resubmitting it, rather than reprocessing the entire batch from scratch.

Prompt-refine-before-scale. Before submitting a large batch (e.g., thousands of documents), refine your prompt against a small representative sample first, to maximize first-pass success rate: this reduces costly iterative resubmission cycles at scale.

6.6 Task Statement: Design multi-instance and multi-pass review architectures

Independent review instances catch more. A separate Claude instance, invoked fresh with no access to the generator's reasoning trace, is more effective at catching subtle issues: it evaluates the output on its own merits rather than inheriting the generator's assumptions.

Multi-pass review for large reviews. As covered in Domain 1 (Task 1.6), splitting a large multi-file review into (a) per-file local-issue passes and (b) a separate cross-file integration pass avoids attention dilution and the contradictory-findings problem that comes from processing everything in one pass.

Calibrated confidence self-reporting. Having the model report a confidence score alongside each finding (rather than as a blanket "how sure are you overall") enables calibrated routing, e.g., low-confidence findings go to human review, high-confidence findings can be auto-applied or auto-flagged, provided the confidence scores have actually been validated against ground truth (see Domain 5, Task 5.5) rather than trusted blindly.

Domain 4: Practice Questions

7. Domain 5: Context Management & Reliability (15%)

This domain covers preserving critical information across long interactions, escalation/ambiguity resolution, error propagation across multi-agent systems, managing context in large codebase exploration, human review workflow design, and provenance/uncertainty handling in synthesis.

7.1 Task Statement: Manage conversation context to preserve critical information across long interactions

"Lost in the middle." Long inputs are processed reliably at the beginning and end, but details buried in the middle are more likely to be under-weighted or missed. Mitigate by placing key findings/summaries first, and organizing detailed supporting material with explicit section headers so nothing important is stranded in an undifferentiated middle block.

Verbose tool outputs bloat context disproportionately to relevance. An order lookup might return 40+ fields; if only 5 are relevant to the current task (e.g., handling a return), keep only those 5 in context going forward rather than letting the full raw payload accumulate turn after turn.

Multi-agent context budgets. When a downstream agent (e.g., a synthesis agent with a limited context budget) depends on an upstream agent's output, have the upstream agent emit structured data (key facts, citations, relevance scores) instead of verbose prose and reasoning chains: this respects the downstream agent's context budget while preserving what's actually needed.

7.2 Task Statement: Design effective escalation and ambiguity resolution patterns

Multiple ambiguous matches require clarification, not heuristic guessing. If a customer lookup returns multiple plausible matches, the agent should ask for an additional identifying detail, not silently pick the "most likely" match based on a heuristic, which risks operating on the wrong account entirely.

7.3 Task Statement: Implement error propagation strategies across multi-agent systems

(This overlaps with Domain 2's Task 2.2 and Domain 1's coordinator patterns: the exam tests it from the "system reliability" angle here.)

• Structured error context enables intelligent coordinator recovery: failure type, what was attempted, any partial results obtained, and possible alternative approaches: this is what lets a coordinator decide to retry differently, try an alternate path, or proceed with partial results and flag the gap.
• Access failures vs. valid empty results must be distinguished: a timeout is a "something went wrong, decide what to do" situation; a successful query that legitimately found nothing is a valid answer, not a failure.
• Generic statuses hide value. "Search unavailable" tells the coordinator nothing actionable: was it a timeout? Rate limit? Invalid query? Each implies a different recovery path.
• Two explicit anti-patterns: silently suppressing errors (returning an empty result as if it were a successful search, hiding a real failure) and terminating the entire multi-agent workflow because of one subagent's failure (when the workflow could reasonably proceed with partial results and an annotated gap).
• Coverage annotations in synthesis. When some sources were unavailable, the final synthesized output should explicitly annotate which findings are well-supported vs. which topic areas have coverage gaps due to unavailable sources, rather than presenting a report that looks uniformly complete when it isn't.

7.4 Task Statement: Manage context effectively in large codebase exploration

• Context degradation in extended sessions. In very long exploration sessions, models can start giving inconsistent answers or referencing generic "typical patterns" instead of the specific classes/functions they actually discovered earlier in the session, a sign that earlier, specific findings have effectively been pushed out of effective attention.
• Scratchpad files. Have the agent persist key findings to a scratchpad file as it explores, and reference that file for later questions: this counteracts context degradation by giving the agent a durable, explicit record instead of relying on it "remembering" everything from deep in a long session.
• Subagent delegation for isolation. Spawn subagents to investigate specific, bounded questions ("find all test files," "trace the refund flow's dependencies") while the main agent stays focused on high-level coordination: this parallels the Explore subagent pattern from Domain 3 and keeps the main session's context budget from being consumed by exploratory noise.
• Summarize before delegating the next phase. Summarize key findings from one exploration phase, and inject that summary into the initial context of the next phase's subagents, rather than re-deriving everything from scratch or hoping context carries forward implicitly.
• Crash recovery via structured state exports. Design each agent to export its state to a known location (a "manifest"); on resume, the coordinator loads the manifest and injects the relevant state into the resumed agents' prompts: this makes recovery survive crashes without needing full re-exploration.
• /compact. Use this to reduce context usage during long exploration sessions once context fills with verbose discovery output, rather than letting the session silently degrade or hit hard context limits.

7.5 Task Statement: Design human review workflows and confidence calibration

• Aggregate accuracy can mask segment-level failure. A 97% overall accuracy figure can hide the fact that one document type or one specific field performs far worse than the aggregate suggests: always break down accuracy by document type and by field, not just as one overall number, before deciding it's safe to reduce human review.
• Stratified random sampling. Even for extractions the model reports as high-confidence, take a stratified random sample for ongoing human review: this measures the true error rate on "confident" outputs (which is not necessarily zero) and helps detect novel error patterns that wouldn't show up if you only ever reviewed low-confidence cases.
• Field-level confidence, calibrated against labeled data. Have the model output a confidence score per field (not one blanket document-level score), and calibrate the meaning of those scores (e.g., "confidence 0.8 corresponds to roughly X% actual accuracy") using a labeled validation set: routing decisions should be based on this calibrated mapping, not the model's raw, unvalidated confidence number.
• Routing priority. Send low-confidence extractions, and extractions from ambiguous or internally contradictory source documents, to human review first: this prioritizes limited reviewer capacity where it has the highest expected value.

7.6 Task Statement: Preserve information provenance and handle uncertainty in multi-source synthesis

• Summarization loses attribution by default. If findings are compressed during a summarization step without deliberately preserving which claim came from which source, that link is gone: attribution has to be a first-class structured field, not something you hope survives prose compression.
• Structured claim-source mappings (claim, evidence excerpt, source URL/document name, publication/collection date) should be preserved and merged, not discarded, as findings flow from research/analysis subagents through to the synthesis agent.
• Conflicting statistics from credible sources. Don't arbitrarily pick one value and discard the other. Annotate the conflict explicitly, with both values and their respective source attributions, and let the report itself (or the coordinator, before final synthesis) present the disagreement rather than silently resolving it in one direction.
• Temporal data. Require publication/collection dates on structured findings so that a difference between two sources that's actually just a temporal difference (the world changed between when each source was published) isn't misread as a contradiction.
• Content-appropriate rendering. Different content types deserve different presentation in a synthesized report: financial data as tables, news narrative as prose, technical findings as structured lists, rather than flattening everything into one uniform text format, which tends to obscure exactly the structure (numeric precision, categorical breakdowns) that makes each type useful.

Domain 5: Practice Questions

8. The Six Official Exam Scenarios: Deep Walkthroughs

The exam presents 4 of these 6 scenarios at random each sitting. Each scenario below explains what it's really testing and which domain concepts to have ready.

Scenario 1: Customer Support Resolution Agent

You are building a customer support resolution agent using the Claude Agent SDK. The agent handles high-ambiguity requests like returns, billing disputes, and account issues. It has access to your backend systems through custom MCP tools (get_customer, lookup_order, process_refund, escalate_to_human). Target: 80%+ first-contact resolution while knowing when to escalate.

Primary domains tested: Agentic Architecture & Orchestration, Tool Design & MCP Integration, Context Management & Reliability.

What to have ready: - The enforcement vs. prompt distinction for the get_customer → process_refund ordering (Domain 1, Task 1.4/1.5): programmatic gates, not prompt reminders, when money is involved. - Tool description quality for get_customer vs. lookup_order: thin, near-identical descriptions cause misrouting (Domain 2, Task 2.1). - Escalation calibration: explicit criteria + few-shot examples, not sentiment or self-confidence (Domain 5, Task 5.2). - Structured error handling for process_refund (business-rule violations like refund-over-threshold) vs. transient failures (Domain 2, Task 2.2). - Multi-concern decomposition when a customer bundles several issues in one message (Domain 1, Task 1.4). - Ambiguous customer matches requiring clarification (Domain 5, Task 5.2). - Structured handoff summaries for escalate_to_human (Domain 1, Task 1.4).

Scenario 2: Code Generation with Claude Code

You use Claude Code for code generation, refactoring, debugging, documentation. You need custom slash commands, CLAUDE.md configuration, and to know when to use plan mode vs. direct execution.

Primary domains tested: Claude Code Configuration & Workflows, Context Management & Reliability.

What to have ready: - CLAUDE.md hierarchy: user vs. project vs. directory scope, and the classic "new teammate doesn't get the rules" diagnostic (Domain 3, Task 3.1). - Slash command scoping: .claude/commands/ (project, shared) vs. ~/.claude/commands/ (personal) (Domain 3, Task 3.2). - Plan mode vs. direct execution decision criteria: scale, ambiguity of approach, architectural stakes (Domain 3, Task 3.4). - Path-specific rules in .claude/rules/ for conventions that vary by file type/area (Domain 3, Task 3.3). - Iterative refinement techniques: concrete examples, test-driven iteration, the interview pattern (Domain 3, Task 3.5). - Explore subagent and /compact for managing context during long exploration (Domain 5, Task 5.4).

Scenario 3: Multi-Agent Research System

A coordinator delegates to a web-search subagent, a document-analysis subagent, a synthesis subagent, and a report-generation subagent. Produces cited, comprehensive reports.

Primary domains tested: Agentic Architecture & Orchestration, Tool Design & MCP Integration, Context Management & Reliability.

What to have ready: - Task decomposition breadth: the "narrow decomposition misses whole subtopics" failure mode is the single most repeated pattern for this scenario (Domain 1, Task 1.2). - Explicit context passing between subagents (no automatic inheritance), and structured content/metadata separation for attribution (Domain 1, Task 1.3). - Parallel subagent spawning via multiple Task calls in one turn (Domain 1, Task 1.3). - Scoped tool distribution: synthesis agent shouldn't have full search tools; maybe a narrow verify_fact tool (Domain 2, Task 2.3). - Error propagation: structured context on subagent failure, distinguishing access failures from valid empty results (Domain 5, Task 5.3). - Provenance preservation: claim-source mappings, conflict annotation, temporal metadata (Domain 5, Task 5.6).

Scenario 4: Developer Productivity with Claude

An agent helps engineers explore unfamiliar codebases, understand legacy systems, generate boilerplate, and automate repetitive tasks, using built-in tools (Read, Write, Bash, Grep, Glob) plus MCP servers.

Primary domains tested: Tool Design & MCP Integration, Claude Code Configuration & Workflows, Agentic Architecture & Orchestration.

What to have ready: - Built-in tool selection: Grep for content search, Glob for filename patterns, Read/Write vs. Edit, and the Edit-fails-on-non-unique-match fallback (Domain 2, Task 2.5). - Incremental exploration: Grep for entry points, then Read to trace flows, not reading everything upfront (Domain 2, Task 2.5). - MCP resources vs. tools for exposing content catalogs, and MCP server scoping (project vs. user) (Domain 2, Task 2.4). - Task decomposition for open-ended work, e.g., "add comprehensive tests to a legacy codebase" (Domain 1, Task 1.6). - Subagent delegation for context isolation during large-scale exploration (Domain 5, Task 5.4).

Scenario 5: Claude Code for Continuous Integration

Claude Code runs automated code reviews, generates test cases, and gives PR feedback in CI/CD. You need prompts that give actionable feedback and minimize false positives.

Primary domains tested: Claude Code Configuration & Workflows, Prompt Engineering & Structured Output.

What to have ready: - -p/--print for non-interactive CI runs; --output-format json + --json-schema for machine-parseable output (Domain 3, Task 3.6). - Session isolation for review: an independent instance reviews better than the generating session reviewing itself (Domain 3, Task 3.6 / Domain 4, Task 4.6). - Explicit precision criteria to reduce false positives, not vague "be conservative" instructions (Domain 4, Task 4.1). - Avoiding duplicate re-review comments across commits, and avoiding duplicate generated tests (Domain 3, Task 3.6). - Multi-pass review for large PRs to avoid attention dilution/contradictions (Domain 1, Task 1.6 / Domain 4, Task 4.6).

Scenario 6: Structured Data Extraction

Extracts information from unstructured documents, validates output using JSON schemas, handles edge cases, integrates downstream.

Primary domains tested: Prompt Engineering & Structured Output, Context Management & Reliability.

What to have ready: - tool_use + JSON schema for guaranteed-shape output; know it doesn't catch semantic errors (Domain 4, Task 4.3). - Nullable fields to prevent fabrication; enum + "other" for extensibility (Domain 4, Task 4.3). - Validation-retry loops and knowing when retries can't help (missing info vs. format errors) (Domain 4, Task 4.4). - Batch processing fit: Message Batches API for latency-tolerant bulk extraction, not blocking workflows (Domain 4, Task 4.5). - Human review routing: field-level calibrated confidence, stratified sampling, accuracy by document type/field (Domain 5, Task 5.5).

9. Official Sample Questions (from the Exam Guide, with explanations)

These 12 questions are reproduced directly from the official Claude Certified Architect - Foundations Exam Guide, which explicitly publishes them "to illustrate the format and difficulty level of the exam." They are the closest thing to real, sanctioned exam items available for study, so make sure you can explain why each wrong answer is wrong, not just which letter is correct.

Scenario: Customer Support Resolution Agent

Scenario: Code Generation with Claude Code

Scenario: Multi-Agent Research System

Scenario: Claude Code for Continuous Integration

Full Practice Exam · Q1-10

This section simulates real exam pacing: a mix of scenario-flavored, multiple-choice and multiple-response questions spanning all five domains, roughly weighted to the blueprint. Answer every question first, then check the answer key at the end: resist the urge to peek early, since the point is to rehearse the actual exam experience (120 minutes / 60 items ≈ 2 minutes/item; try 30 items in ~55-60 minutes).

Full Practice Exam · Q11-20

Full Practice Exam · Q21-30

11. Domain Cheat Sheets (Final-Review Quick Reference)

Domain 1: Agentic Architecture & Orchestration (27%)

• Loop control = stop_reason (tool_use → keep going; end_turn → done). Never parse NL text or rely on an iteration cap as the primary mechanism.
• Coordinator = hub; subagents = spokes. Subagents have no automatic context inheritance: pass everything explicitly.
• Task tool must be in coordinator's allowedTools to spawn subagents at all.
• Parallel subagents = multiple Task calls in one turn.
• Narrow decomposition is the #1 root cause of "each subagent worked, but coverage failed."
• Enforcement (hooks/prerequisite gates) beats prompts whenever compliance must be guaranteed (money, identity, safety).
• PostToolUse hooks normalize data; tool-interception hooks block policy violations deterministically.
• Prompt chaining = fixed, predictable multi-step pipelines. Dynamic decomposition = open-ended investigation.
• --resume <name> for still-valid context; fork_session for divergent-approach branching; inject a fresh structured summary when prior state is largely stale.

Domain 2: Tool Design & MCP Integration (18%)

• Tool descriptions are THE primary tool-selection mechanism. Thin/near-identical descriptions → misrouting. Fix descriptions before adding few-shot examples or routing layers.
• isError flag + errorCategory (transient/validation/business/permission) + isRetryable boolean = structured error design. Generic "failed" messages are an anti-pattern.
• Distinguish access failures (needs a decision) from valid empty results (a real, successful answer).
• Fewer, role-scoped tools beat many tools (18 vs. 4-5 measurably hurts reliability). Give narrow cross-role tools for high-frequency needs only.
• tool_choice: "auto" (model may skip tools), "any" (must call some tool), forced/named (must call this tool).
• .mcp.json = project scope (shared, ${VAR} expansion for secrets); ~/.claude.json = personal scope. Both active simultaneously.
• MCP resources = browsable content catalogs; MCP tools = actions.
• Prefer existing community MCP servers for standard integrations; build custom only for team-specific gaps.
• Grep = content search; Glob = filename/path pattern; Edit fails on non-unique anchor → fallback to Read + Write.

Domain 3: Claude Code Configuration & Workflows (20%)

• CLAUDE.md hierarchy: user (~/.claude/CLAUDE.md, personal, not shared) → project (.claude/CLAUDE.md or root, shared/versioned) → directory (subfolder-scoped). "New hire missing rules" = usually a user-vs-project scoping bug.
• @import keeps CLAUDE.md modular; .claude/rules/ splits topic-specific files as an alternative to one monolith.
• .claude/commands/ = project-scoped, shared slash commands; ~/.claude/commands/ = personal.
• Skills live in .claude/skills/; frontmatter: context: fork (isolate verbose output), allowed-tools (restrict tool access), argument-hint (prompt for missing args).
• .claude/rules/ with YAML paths glob = conditional, file-pattern-based convention loading: the answer whenever conventions must apply "regardless of directory."
• Plan mode = large scale, multiple valid approaches, architectural stakes. Direct execution = simple, well-scoped, one clear path. They can be sequenced (plan then execute).
• Explore subagent isolates verbose discovery; /compact reduces context usage mid-session; /memory shows what's actually loaded.
• Iterative refinement: concrete I/O examples > vague prose; test-driven iteration (write tests, share failures); the interview pattern (ask before building); batch interacting fixes, sequence independent ones.
• CI: -p/--print for non-interactive mode; --output-format json + --json-schema for structured CI output; independent review instance beats self-review; include prior findings to avoid duplicate re-review comments; include existing tests to avoid duplicate generated tests.

Domain 4: Prompt Engineering & Structured Output (20%)

• Explicit, categorical criteria reduce false positives; vague "be conservative"/confidence-based instructions don't.
• Few-shot examples are the top lever for consistent formatting, ambiguous-case handling, and reduced extraction hallucination: 2-4 targeted examples showing why, not just input→output.
• tool_use + JSON schema eliminates syntax errors, not semantic errors (sums, misplaced values): still need validation.
• tool_choice: "any" when schema/document type is uncertain; forced/named when a specific extraction must run first.
• Nullable/optional fields prevent fabrication when data is genuinely absent; enum + "other" + detail string handles novel categories; "unclear" enum handles genuine ambiguity honestly.
• Retry-with-error-feedback fixes format/structural failures; it cannot fix "the information simply isn't in the document" failures.
• Message Batches API: 50% cheaper, up to 24h processing, no SLA guarantee, no multi-turn tool calls, custom_id for correlation. Good for non-blocking/overnight; bad for blocking/real-time workflows.
• Self-review is structurally weaker than independent-instance review (retained reasoning context). Split large reviews into per-file + cross-file integration passes to avoid attention dilution/contradictions.

Domain 5: Context Management & Reliability (15%)

• Progressive summarization erodes precise facts (amounts, dates): extract them into a persistent "case facts" block outside the summarized narrative.
• "Lost in the middle": put key findings first/last; use explicit section headers for detailed middle content.
• Trim verbose tool outputs to only relevant fields before they accumulate in context.
• Escalate on: explicit human request (immediately), policy gaps/silence, inability to progress. Do not rely on sentiment or self-reported confidence as escalation triggers.
• Multiple ambiguous matches → ask for another identifier, don't guess heuristically.
• Structured error propagation (failure type, attempted query, partial results, alternatives) enables coordinator recovery; distinguish access failures from valid empty results; never silently suppress errors or kill the whole workflow over one failure.
• Long exploration sessions degrade: use scratchpad files, subagent delegation for isolated investigation, pre-phase summarization, manifest-based crash recovery, and /compact.
• Aggregate accuracy can mask segment-level failure: validate by document type/field. Use stratified sampling on "confident" outputs. Calibrate field-level confidence against labeled data before routing on it.
• Preserve claim-source mappings through synthesis; annotate (don't silently resolve) conflicting stats; require publication/collection dates to avoid mistaking temporal differences for contradictions; render different content types appropriately (tables, prose, lists).

12. External Resources for Further Study

This guide is designed to be sufficient on its own, but if you want primary-source documentation or hands-on practice beyond it, these are the most relevant official resources (search for the current versions, since URLs and docs structure can change):

• Anthropic Partner Academy: Claude Certified Architect - Foundations page: the official course page, exam guide PDF, terms and conditions, and exam policy (the source material this guide was built from).
• Anthropic's official documentation site (docs.claude.com): look for sections on the Claude Agent SDK, Model Context Protocol, tool use, the Messages API, and Claude Code: these host the canonical, most current reference material for anything this guide summarizes.
• Claude Code documentation: CLAUDE.md configuration, slash commands, Agent Skills, plan mode, and CLI reference: useful for hands-on practice mirroring Domain 3.
• Model Context Protocol specification and server registry (modelcontextprotocol.io and its GitHub organization): the MCP spec itself, plus a directory of existing community MCP servers: useful for Domain 2's "prefer existing servers over custom builds" guidance and for seeing real tool/resource definitions.
• Anthropic's prompt engineering documentation: deeper guidance on few-shot prompting, structured output via tool use, and prompt chaining: directly supports Domain 4.
• Anthropic's cookbook/example repositories (typically found under Anthropic's GitHub organization): worked code samples for agentic loops, multi-agent patterns, and structured extraction pipelines: good for the hands-on practice this exam explicitly expects.
• The other Claude certifications (Claude Certified Associate - Foundations, Claude Certified Developer - Foundations, Claude Certified Architect - Professional) on the same Anthropic Partner Academy site, in case you want a broader or deeper credential path afterward.

A final note on studying: this exam is explicitly scenario- and judgment-based, not trivia-based. The single highest-leverage thing you can do beyond reading this guide is to actually build a small version of each of the 6 scenarios, even a toy one, because the "why is A right and B, C, D wrong" reasoning throughout this guide is exactly the reasoning the real exam expects you to reconstruct on the fly for scenarios you haven't seen before. Good luck.

API & Tool-Use Fundamentals

The exam is judgment-based, but its scenarios and answer options are written using the concrete artifacts of the Claude API, the Agent SDK, MCP, and Claude Code. You need to recognize these on sight, e.g., to know at a glance that {"type": "tool", "name": "..."} is a forced tool choice, or that a tool_result block carries an is_error flag. This appendix collects those artifacts in one place. The exam's own Appendix lists exactly these technologies as testable, so treat this as required recognition-level knowledge.

A.1 The Claude Messages API: request and response shape

A single API call sends a list of messages (alternating user / assistant roles), optional system prompt, tools, tool_choice, and max_tokens. Minimal request:

{
  "model": "claude-...",
  "max_tokens": 1024,
  "system": "You are a customer support agent. ...",
  "tools": [ /* tool definitions, see A.4 */ ],
  "tool_choice": {"type": "auto"},
  "messages": [
    {"role": "user", "content": "Where is my order #12345?"}
  ]
}

Key fields to recognize: - system: top-level system prompt (a string or list of blocks). Not a message with role: "system"; it's its own parameter. Wording here influences tool selection (Domain 2, Task 2.1). - max_tokens: hard cap on tokens generated in that response. If the model hits it mid-output, the response comes back with stop_reason: "max_tokens" (a truncated, not a completed, turn). - messages: the full conversation so far. The API is stateless: you resend the entire history every call. This is why "passing complete conversation history in subsequent requests" (Domain 5, Task 5.1) matters: the model has no memory beyond what you send. - content: can be a plain string or a list of typed content blocks (text, tool_use, tool_result, image, etc.). Multi-block content is what makes tool use work.

A.2 stop_reason values: the loop control signal

Every assistant response includes a stop_reason. This is the field your agentic loop inspects (Domain 1, Task 1.1).

The exam's canonical anti-patterns: deciding termination by scanning assistant text ("looks done"), or using an iteration cap as the primary stop mechanism. Both are wrong because stop_reason is the designed, reliable signal.

A.3 tool_use and tool_result content blocks

When stop_reason is "tool_use", the assistant message contains one or more blocks like:

{
  "type": "tool_use",
  "id": "toolu_01A2b3...",
  "name": "lookup_order",
  "input": {"order_id": "12345"}
}

You execute the tool, then append a new user message whose content contains a matching tool_result block referencing the same id:

{
  "role": "user",
  "content": [
    {
      "type": "tool_result",
      "tool_use_id": "toolu_01A2b3...",
      "content": "{\"status\": \"shipped\", \"eta\": \"2026-07-24\"}",
      "is_error": false
    }
  ]
}

Recognition points that show up in answer options: - The tool_use_id on the result must match the id of the tool_use block: that's how the model correlates request to result. - is_error: true is the API-level signal that a tool call failed. This is the mechanism behind MCP's isError pattern (Domain 2, Task 2.2): a failed tool doesn't throw; it returns a result flagged as an error so the model can reason about recovery. - Parallel tool use: a single assistant turn can contain multiple tool_use blocks. You return all their results in a single following user message (multiple tool_result blocks). This is the API basis for "emit multiple Task calls in one turn" (Domain 1, Task 1.3).

A.4 Tool definition schema

A tool is defined by a name, a description (the primary selection signal, Domain 2, Task 2.1), and an input_schema (JSON Schema):

{
  "name": "lookup_order",
  "description": "Retrieve the status, line items, and shipping details for a single order. Use when the user references an order number (format ORD-##### or a bare 5-digit number) or asks about shipping/delivery/returns for a specific purchase. Do NOT use for account-level questions. Use get_customer for those.",
  "input_schema": {
    "type": "object",
    "properties": {
      "order_id": {"type": "string", "description": "Order number, e.g. ORD-12345"}
    },
    "required": ["order_id"]
  }
}

Notice the description does the four things the exam rewards: states purpose, gives input format, gives when-to-use, and draws a boundary against the similar get_customer tool.

Tool Choice, Hooks & MCP Artifacts

A.5 tool_choice object syntax

(There is also an optional disable_parallel_tool_use flag to force one-tool-at-a-time; recognize it but it's a minor point.)

A.6 Agent SDK: AgentDefinition and hooks

AgentDefinition (the configuration for a subagent type) conceptually carries: - a description (what this agent is for; helps the coordinator/model decide when to delegate to it), - a system prompt / instructions (its role and quality criteria: prefer goals over rigid procedures, Domain 1, Task 1.3), - tool restrictions (allowedTools / an allowed tool set: scope tightly to role, Domain 2, Task 2.3), - optionally a model choice.

For a coordinator to spawn subagents, its allowedTools must include "Task" (Domain 1, Task 1.3).

Hooks run deterministic code inside the loop, independent of the model's choices (Domain 1, Task 1.5):

Conceptually a PreToolUse hook can allow, block, or modify the pending call; a PostToolUse hook can transform the result. The exam's core point: use hooks (deterministic) whenever a rule must be guaranteed; use prompts only for probabilistic guidance.

A.7 MCP artifacts

MCP tool: same shape as an API tool (name, description, inputSchema), exposed by an MCP server. On failure, an MCP tool returns a result with isError: true plus (best practice) structured metadata:

{
  "isError": true,
  "errorCategory": "transient",   // transient | validation | business | permission
  "isRetryable": true,
  "message": "Order service timed out after 10s."
}

MCP resource: content, not an action. Identified by a URI, with a name and MIME type; the agent can list and read resources to understand what data exists (issue catalogs, doc hierarchies, DB schemas) without exploratory tool calls (Domain 2, Task 2.4). Rule of thumb: tools = verbs (do something), resources = nouns (browse something).

.mcp.json (project scope: shared, version-controlled) with environment-variable expansion for secrets:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {"GITHUB_TOKEN": "${GITHUB_TOKEN}"}
    }
  }
}

Personal/experimental servers go in user scope (~/.claude.json). Tools from all connected servers are available simultaneously.

Claude Code Config, Schemas & Batches

A.8 Claude Code configuration files

CLAUDE.md hierarchy (all three can coexist; more specific augments more general): - ~/.claude/CLAUDE.md: user scope (personal, not shared via version control) - .claude/CLAUDE.md or root CLAUDE.md: project scope (shared, committed) - <subdir>/CLAUDE.md: directory scope - @path/to/file.md inside a CLAUDE.md: import syntax to keep it modular - /memory: command to inspect which memory files are actually loaded

Slash commands: .claude/commands/<name>.md (project, shared) vs ~/.claude/commands/<name>.md (personal).

Skill: .claude/skills/<name>/SKILL.md with frontmatter:

---
name: analyze-codebase
description: Map module structure and dependencies for a target directory.
context: fork          # run in isolated sub-agent context; keeps verbose output out of main convo
allowed-tools: [Read, Grep, Glob]   # restrict tools during skill execution
argument-hint: "<directory path>"    # prompt user for args if invoked without them
---
Instructions the skill follows...

Path-scoped rule: .claude/rules/<name>.md with glob paths frontmatter (loads only when editing matching files, regardless of directory):

---
paths: ["**/*.test.tsx", "**/*.test.ts"]
---
# Testing conventions
Use React Testing Library. One assertion theme per test. ...

CLI flags for CI/CD (Domain 3, Task 3.6): - -p / --print: non-interactive mode (prints result and exits; prevents CI hangs) - --output-format json: machine-parseable output - --json-schema <schema>: constrain that JSON output to a schema - --resume <session-name>: continue a named session; fork_session (SDK): branch from a baseline - /compact: compress context mid-session; Explore subagent: isolate verbose discovery

A.9 JSON Schema patterns for structured output

Structured output via tool_use uses JSON Schema for the tool input_schema. Patterns the exam expects (Domain 4, Task 4.3):

{
  "type": "object",
  "properties": {
    "invoice_number": {"type": "string"},
    "due_date": {"type": ["string", "null"]},          // nullable: model returns null instead of fabricating
    "document_type": {"type": "string", "enum": ["invoice", "receipt", "other"]},
    "document_type_detail": {"type": ["string", "null"]}, // paired with "other"
    "confidence": {"type": "number"},
    "line_items": {"type": "array", "items": {"type": "object"}}
  },
  "required": ["invoice_number", "document_type"]
}

• Nullable = "type": ["string", "null"] (or anyOf). Use for data that may genuinely be absent, so the model returns null rather than inventing a value.
• Enum + "other" + detail keeps categories extensible; add "unclear" for genuine ambiguity.
• required vs optional: mark a field required only if it must always be present; over-requiring drives fabrication.
• Strict schemas eliminate syntax errors, not semantic ones: a schema-valid object can still have line items that don't sum to the total. That's what validation-retry loops and self-check fields (calculated_total vs stated_total, conflict_detected) are for (Domain 4, Task 4.4).
• Pydantic is commonly used to validate the parsed object server-side; a validation failure feeds the retry-with-error-feedback loop.

A.10 Message Batches API shape

For latency-tolerant bulk work (Domain 4, Task 4.5): ~50% cheaper, up to 24h processing, no latency SLA, no multi-turn tool calling within a request, correlate by custom_id.

{
  "requests": [
    {"custom_id": "doc-001", "params": {"model": "...", "max_tokens": 1024, "messages": [ ... ]}},
    {"custom_id": "doc-002", "params": { ... }}
  ]
}

Each result comes back tagged with its custom_id and a status such as succeeded, errored, canceled, or expired. On partial failure, resubmit only the failed custom_ids (e.g., chunk a document that exceeded context, then resubmit just that one). Use it for overnight/weekly jobs; never for a blocking, human-waiting workflow (pre-merge checks).

Appendix B: Tradeoff Decision Tables

This exam is fundamentally about choosing correctly between close alternatives under a specific constraint. These tables compress the recurring decisions. For each, the exam almost always signals the answer through one keyword in the scenario (the "tell"). Learn the tells.

B.1 Prompt instruction vs. programmatic enforcement (hook/gate)

Tell: if the scenario reports a failure rate ("in 9-12% of cases it skips X") on a consequential step, the answer is enforcement, not a reworded prompt or more few-shot examples. Probabilistic fixes for deterministic requirements are always distractors here.

B.2 Session resumption vs. fork vs. fresh start

Tell: "compare two approaches" → fork. "stale/changed a lot" → fresh + summary. "changed these specific files" → resume + targeted note.

B.3 Plan mode vs. direct execution

Tell: the scenario states the complexity up front (dozens of files / multiple approaches / boundaries) → plan mode now, not "try direct first and switch later." "Only switch to plan mode if it gets hard" is a distractor when complexity is already known.

B.4 Synchronous API vs. Message Batches API

Tell: "developers wait / pre-merge / real-time" → sync. "overnight / next morning / weekly / save cost on bulk" → batch. Moving a blocking workflow to batch "for the 50% savings" is always wrong.

B.5 tool_choice: auto vs. any vs. forced

B.6 Skill vs. CLAUDE.md vs. .claude/rules/

Tell: "regardless of directory / wherever these files live / automatically" → rules with globs. "run this workflow when I ask" → skill. "everyone should always follow" → CLAUDE.md. Note the distinction between .claude/rules/ for conditional convention loading and directory-level CLAUDE.md, which is directory-bound.

B.7 Fixing output quality: criteria vs. few-shot vs. schema

B.8 Escalate vs. resolve (customer support)

Never escalate based on sentiment/frustration alone or self-reported confidence: acknowledge frustration and offer to resolve; escalate only if the customer reiterates. Multiple ambiguous identity matches → ask for another identifier, don't guess.

B.9 Retry vs. don't retry (extraction)

B.10 Tool descriptions: improve vs. split vs. consolidate

Appendix C: How to Read Exam Questions (Distractor Patterns & Elimination Strategy)

Most items give you four (or more) plausible-sounding options where more than one would "work": the exam wants the best answer given the constraint, usually the most proportionate, root-cause-addressing, and correctly-layered one. The wrong answers are not random; they recur in predictable shapes. If you can name the shape, you can eliminate it.

C.1 The recurring wrong-answer archetypes

1. The over-engineered solution. Introduces heavy infrastructure (a trained classifier, an ML pipeline, a separate routing model, a new service) when a prompt/description/config change would fix the root cause. Tell: "train a model," "deploy a classifier," "build a routing layer." Usually wrong when a simpler first step hasn't been tried.

2. The probabilistic fix for a deterministic need. Offers a prompt tweak, more few-shot examples, or a confidence threshold for a rule that must be guaranteed (money, identity, ordering). Tell: the scenario cites a failure rate on a consequential step. Beaten by a hook/prerequisite gate.

3. Blame the downstream agent. In multi-agent scenarios, points at the synthesis/analysis/search agent when the logs show the coordinator's decomposition (or context passing) was the real cause. Tell: "each subagent completed successfully." The fault is upstream, in what they were assigned.

4. The bigger hammer. "Switch to a larger context-window / higher-tier model." Rarely correct: attention dilution, self-review bias, and missing-information problems are not solved by more context or a bigger model.

5. Silent suppression / false success. "Return an empty result marked successful," "catch the error and continue quietly." Always an anti-pattern: hides failures the coordinator needs to see.

6. Nuke the workflow. "Terminate the entire pipeline on one subagent failure." Over-reacts; partial results + annotated gaps are usually preferable.

7. The plausible-but-nonexistent feature. Invented flags/config: --headless, CLAUDE_HEADLESS=true, --batch, .claude/config.json commands array, scope: private. If you don't recognize it from Appendix A, be suspicious.

8. Solves a different problem. Technically fine but addresses tool availability when the issue is tool ordering, or sentiment when the issue is complexity. Re-read what the scenario actually asked.

9. Fabricate to satisfy structure. Making a field required and telling the model to "provide a best guess" when data may be absent: drives hallucination. Nullable is the fix.

10. Consensus/averaging that hides truth. "Only flag issues appearing in 2 of 3 runs" (suppresses real intermittent bugs); "average the two conflicting statistics" (fabricates a number). Preserve and annotate instead.

C.2 A four-step elimination method

1. Identify the constraint. What does the scenario optimize for: determinism? latency? cost? precision? coverage? attribution? That single constraint usually decides it.
2. Find the root cause. Especially in multi-agent items: read the logs described. If "each subagent succeeded," suspect the coordinator.
3. Match proportionality. Prefer the smallest change that addresses the root cause. "First step / most effective first" phrasing rewards the cheap high-leverage fix (often: improve descriptions, add explicit criteria) over architecture.
4. Check the layer. Is this a guarantee need (→ hook/gate/enforcement) or a guidance need (→ prompt/few-shot)? Is recovery local (subagent) or escalated (coordinator)? Wrong-layer answers are the most common trap.

C.3 Answering multiple-response items

The item states how many to select. Treat each option as an independent true/false against the scenario; don't force a pattern. A common design: two clearly-correct best practices plus two that are real anti-patterns dressed in reasonable language (e.g., "self-reported confidence" and "sentiment threshold" as escalation triggers). Select exactly the number asked: partial-credit rules vary, so don't over- or under-select.

C.4 Time and flag strategy

60 items in 120 minutes = ~2 minutes each. Scenario stems are long; read the question sentence first, then mine the stem for the specific fact it hinges on (a failure rate, a log excerpt, a latency number, an SLA). Flag-and-return on anything past ~2.5 minutes: the scenario context you've already loaded makes later questions in the same scenario faster, so momentum matters more than perfection on any single item.

Appendix D: Glossary

Appendix E: Exam-Readiness Self-Assessment

Score yourself honestly. If you can't do a line from memory (concept and why the alternatives are wrong), return to the referenced domain. Aim to clear every box before scheduling. Because the passing bar is a scaled 720/1000 and Domain 1 is 27% of the exam, prioritize any Domain 1 gaps.

Domain 1: Agentic Architecture & Orchestration (27%)

• I can write the agentic loop and name what each stop_reason value does (A.2).
• I can explain why parsing text or an iteration cap are wrong loop-termination signals.
• I can explain hub-and-spoke, and why subagents don't inherit context.
• I can spot "narrow decomposition" as the root cause when subagents "each succeeded."
• I know Task must be in allowedTools, and that parallel = multiple Task calls in one turn.
• I can choose prompt vs. hook vs. prerequisite gate for a given rule.
• I can pick prompt chaining vs. dynamic decomposition, and resume vs. fork vs. fresh.

Domain 2: Tool Design & MCP Integration (18%)

• I can write a strong tool description (purpose, input format, when-to-use, boundary).
• I know improve-descriptions is the first fix for confusion between similar tools.
• I can design a structured MCP error (isError, errorCategory, isRetryable) and classify error types.
• I can explain why 18 tools hurts vs. 4-5, and how scoped cross-role tools help.
• I can choose auto vs. any vs. forced tool_choice.
• I know project (.mcp.json) vs. user (~/.claude.json) scope and env-var expansion.
• I can distinguish MCP resources (content) from tools (actions).
• I can pick Grep vs. Glob vs. Read/Write vs. Edit, and the Edit→Read+Write fallback.

Domain 3: Claude Code Configuration & Workflows (20%)

• I can place config correctly across the CLAUDE.md hierarchy and diagnose the "new hire" bug.
• I know .claude/commands/ vs ~/.claude/commands/ scope.
• I know SKILL.md frontmatter (context: fork, allowed-tools, argument-hint).
• I know when .claude/rules/ globs beat directory CLAUDE.md.
• I can decide plan mode vs. direct execution from the stated complexity.
• I know -p, --output-format json, --json-schema, and why independent review beats self-review.
• I know the iterative-refinement techniques (examples, test-driven, interview, batch vs. sequence).

Domain 4: Prompt Engineering & Structured Output (20%)

• I can replace vague criteria with explicit categorical criteria to cut false positives.
• I know when few-shot examples are the right lever and how many to use.
• I know tool_use+schema fixes syntax but not semantics.
• I can design nullable fields and enum+"other" patterns; I know why over-requiring causes fabrication.
• I know when retries help (format) vs. don't (missing info).
• I can judge sync vs. batch and do the SLA/submission-frequency math.
• I know why independent/multi-pass review beats self-review for large reviews.

Domain 5: Context Management & Reliability (15%)

• I can preserve facts via a case-facts block and mitigate lost-in-the-middle.
• I know the three real escalation triggers and the two unreliable ones (sentiment, self-confidence).
• I can design structured error propagation and distinguish access failures from empty results.
• I know scratchpads, subagent isolation, manifests, and /compact for long sessions.
• I know aggregate accuracy hides segment failure; I know stratified sampling and calibrated confidence.
• I can preserve claim-source mappings, annotate conflicts, and use dates to avoid false contradictions.

Cross-cutting

• I can name the distractor archetypes (Appendix C) and eliminate on sight.
• I can recognize every artifact in Appendix A on screen.
• I've taken the 30-question practice exam timed and reviewed every miss.
• I've built (even a toy version of) at least 2 of the 6 scenarios end-to-end.

When every box is checked and you're consistently reconstructing the why-not for wrong options without looking, you're ready to schedule. Good luck.