Claude Certification

Custom slash commands and skills package repeatable workflows for your team. The exam checks where they live, how they are shared, and how frontmatter controls isolation, permissions and arguments (Task Statement 3.2).

⌨️ Commands: project vs personal

• .claude/commands/review.md — project command, committed, available to everyone who clones the repo.
• ~/.claude/commands/ — personal commands, not shared.

🎯 Skills and SKILL.md

---
name: explore-codebase
description: Map an unfamiliar area of the codebase and summarise entry points
context: fork
allowed-tools: Read, Grep, Glob
argument-hint: <directory or feature to explore>
---
Explore $ARGUMENTS. Return: purpose, entry points, key data flows, risks.

📘 Personal variants

To customise a team skill for yourself, create a copy under a different name in ~/.claude/skills/. Editing the team skill — even locally — affects others or gets shadowed.

📄 Skills vs CLAUDE.md

Skills are invoked on demand for task-specific workflows; CLAUDE.md is always loaded for universal standards. Conventions that must always apply belong in CLAUDE.md or rules, not in a skill.

🧪 Exam-Style Practice Questions

Try these before opening the answers. They use the same scenario style as the real exam.

Question 1. Where does a project slash command that every developer gets on clone belong?

• A. `.claude/commands/` in the repo
• B. CLAUDE.md
• C. `.claude/config.json`
• D. `~/.claude/commands/`

Question 2. A skill should only write files and never run Bash. Which frontmatter enforces this?

• A. `context: fork`
• B. `paths`
• C. `argument-hint`
• D. `allowed-tools: Write, Edit` (or similar, excluding Bash)

Question 3. Developers often run `/migrate-schema` with no arguments and get poor output. What helps?

• A. Plan mode
• B. `context: fork`
• C. A longer CLAUDE.md
• D. `argument-hint: <table-name> <target-version>` in the skill frontmatter

📝 Assignment

Do these tasks in order. Each one has a Done when check, so you know when it is complete. The stretch task is optional but close to what the exam expects from an architect. Keep your answers in one notes file or Git repository, and revisit them in your final week of revision together with the cheat sheet in the last lesson of this course.

1. Task 1: Create .claude/commands/review.md with your team's review checklist and run it.
   ✅ Done when: A teammate can run /review after pulling the repository, and it follows your checklist.
2. Task 2: Create a skill with context: fork, allowed-tools and argument-hint, and run it with and without arguments.
   ✅ Done when: Running the skill without arguments shows the argument hint, and its output does not flood the main conversation.
3. Stretch: make a personal variant of a team skill under a different name in ~/.claude/skills/.
   ✅ Done when: Your personal variant has a different name, and the team skill still behaves exactly as before.

❓ Frequently Asked Questions

🤔 Where do team slash commands live?

In .claude/commands/ in the repository, so everyone gets them after cloning.

🤔 What does context: fork do?

It runs the skill in an isolated sub-agent context so its output does not crowd the main conversation.

🤔 How do I stop a skill running shell commands?

List only the tools it needs in allowed-tools, leaving out Bash.

🤔 Skill or CLAUDE.md?

Use a skill for on-demand, task-specific workflows and CLAUDE.md for standards that must always apply.

🏁 Summary

• .claude/commands = team; ~/.claude/commands = personal.
• context: fork isolates, allowed-tools restricts, argument-hint prompts.
• Personal variants get a different name at user level.

Next, continue with Claude Code Plan Mode vs Direct Execution and Iterative Refinement.

Independent study material by SQA Tools. Not affiliated with, endorsed by or sponsored by Anthropic. Claude is a trademark of Anthropic. Mock questions are original practice items, not real exam content. Exam facts checked against Anthropic's official exam guides and certification FAQ on 11 November 2026.

CLAUDE.md is how you give Claude Code persistent project knowledge. The exam tests where instructions live, who receives them, and how to keep them modular so the right conventions load at the right time (Task Statements 3.1 and 3.3).

🏛️ The three-level hierarchy

📎 Keep it modular with @import

# packages/payments/CLAUDE.md
Payments service conventions.
@docs/standards/pci.md
@docs/standards/error-handling.md

Each package imports only the standards relevant to it, instead of loading everything everywhere.

📏 .claude/rules/ and path-specific rules

Split a huge CLAUDE.md into topic files such as testing.md, api-conventions.md and deployment.md in .claude/rules/. Add YAML frontmatter with paths globs so a rule loads only when Claude edits matching files:

---
paths: ["**/*.test.tsx", "**/*.test.ts"]
---
Use React Testing Library. One behaviour per test. No snapshot tests.

Path-scoped rules beat directory CLAUDE.md files when matching files are scattered (tests next to components, Terraform in many service folders), and they save context because irrelevant rules never load.

🧠 Debug with /memory

When two developers see different behaviour, run /memory in each session to see exactly which memory files are loaded. It is the first diagnostic for hierarchy problems.

🧪 Exam-Style Practice Questions

Try these before opening the answers. They use the same scenario style as the real exam.

Question 1. Your `packages/payments/CLAUDE.md` should include the PCI standards file but not the frontend style guide. What's the cleanest method?

• A. `@import` the PCI standards file in that package's CLAUDE.md
• B. Copy-paste the PCI text into it
• C. Create a skill
• D. Put everything in the root

Question 2. Test files sit next to their sources throughout the repo. What's the best way to apply testing conventions automatically?

• A. Root CLAUDE.md
• B. A CLAUDE.md in each folder
• C. A `/test` command
• D. A `.claude/rules/testing.md` with `paths: ["**/*.test.*"]`

Question 3. What's the key difference between a skill and CLAUDE.md?

• A. CLAUDE.md can't be shared
• B. Skills are invoked on demand for specific tasks; CLAUDE.md holds always-loaded standards
• C. Skills can't restrict tools
• D. Skills are always loaded

📝 Assignment

Do these tasks in order. Each one has a Done when check, so you know when it is complete. The stretch task is optional but close to what the exam expects from an architect. Keep your answers in one notes file or Git repository, and revisit them in your final week of revision together with the cheat sheet in the last lesson of this course.

1. Task 1: Run /init in a repository, then move one team convention from your user-level file into the project CLAUDE.md.
   ✅ Done when: A teammate who pulls the repository gets the convention without changing their own machine, and /memory shows the project file.
2. Task 2: Create .claude/rules/testing.md with a paths glob for test files and confirm it loads only when you edit a test.
   ✅ Done when: The testing rule appears when you edit a test file and does not appear when you edit an unrelated source file.
3. Stretch: split a long CLAUDE.md into three rule files and use @import for one shared standards document.
   ✅ Done when: The original CLAUDE.md is shorter, the three rule files each cover one topic, and the imported file loads where you expect.

❓ Frequently Asked Questions

🤔 Why doesn't my teammate get my CLAUDE.md rules?

They are probably in ~/.claude/CLAUDE.md, which is personal. Put team rules in the project CLAUDE.md.

🤔 What does @import do in CLAUDE.md?

It pulls another file's contents into CLAUDE.md, so each package can include only the standards it needs.

🤔 When should I use .claude/rules with paths?

When conventions apply to files spread across many folders, such as all test files.

🤔 How do I see which memory files are loaded?

Run /memory in the Claude Code session.

🏁 Summary

• User-level = personal; project-level = team.
• @import for modular standards; .claude/rules/ for topic files.
• paths globs load conventions only for matching files, wherever they live.
• /memory shows what’s loaded.

Next, continue with Claude Code Slash Commands and Skills (SKILL.md Frontmatter).

Independent study material by SQA Tools. Not affiliated with, endorsed by or sponsored by Anthropic. Claude is a trademark of Anthropic. Mock questions are original practice items, not real exam content. Exam facts checked against Anthropic's official exam guides and certification FAQ on 11 November 2026.

The Model Context Protocol (MCP) connects Claude to your systems. The exam checks that you can configure servers at the right scope, keep secrets out of git, use resources to cut wasted calls, and pick the right built-in tool (Task Statements 2.4 and 2.5).

🔌 Project scope vs user scope

{
  "mcpServers": {
    "github": {
      "command": "github-mcp-server",
      "env": { "GITHUB_TOKEN": "${GITHUB_TOKEN}" }
    }
  }
}

Environment-variable expansion (${GITHUB_TOKEN}) keeps credentials out of version control. Tools from all configured servers are discovered when Claude Code connects and are available at the same time.

🛠️ Tools vs resources

• Tools perform actions (search tickets, create an issue).
• Resources expose content catalogues — issue summaries, documentation trees, database schemas — so the agent can see what exists without exploratory tool calls.

If the agent keeps choosing built-in Grep over your more capable MCP search tool, improve the MCP tool’s description. For standard systems like Jira, prefer a maintained community server; build custom servers for team-specific workflows.

🛠️ Choosing built-in tools

Explore incrementally: Grep for entry points, then Read along imports. To trace usage through wrapper modules, list all exported names first, then Grep for each.

🧪 Exam-Style Practice Questions

Try these before opening the answers. They use the same scenario style as the real exam.

Question 1. Where should a shared team GitHub MCP server be configured, and how is its token handled?

• A. `.mcp.json` with the token inline, but git-ignored
• B. `~/.claude.json` with the token inline
• C. CLAUDE.md
• D. Project `.mcp.json` committed, using `${GITHUB_TOKEN}` env expansion

Question 2. You need to find every file named `*.spec.ts`, then find which of them call `createUser(`. Which tools, in order?

• A. Grep, then Glob
• B. Bash `ls` only
• C. Glob, then Grep
• D. Read all files

Question 3. The agent makes 12 exploratory calls to discover which database tables exist. What's the better design?

• A. Increase `max_tokens`
• B. Put the full DB dump in the prompt
• C. Add a `list_everything` tool
• D. Expose the schema catalogue as an MCP **resource**

📝 Assignment

Do these tasks in order. Each one has a Done when check, so you know when it is complete. The stretch task is optional but close to what the exam expects from an architect. Keep your answers in one notes file or Git repository, and revisit them in your final week of revision together with the cheat sheet in the last lesson of this course.

1. Task 1: Create a project .mcp.json that uses ${GITHUB_TOKEN} and a personal server in user scope. Confirm both appear with /mcp.
   ✅ Done when: /mcp lists both servers, and your committed .mcp.json contains no real token.
2. Task 2: Find all callers of one function with Grep and all test files with Glob in a repo you know.
   ✅ Done when: You recorded the exact Grep and Glob patterns you used and how many matches each returned.
3. Stretch: expose a list of documents as an MCP resource and compare the number of tool calls before and after.
   ✅ Done when: You counted tool calls before and after adding the resource, and the count went down.

❓ Frequently Asked Questions

🤔 Where do shared MCP servers go?

In the project's .mcp.json, committed to the repository, with secrets supplied through environment-variable expansion.

🤔 What is an MCP resource?

Read-only content the server exposes, such as a catalogue or schema, so the agent can see what exists without exploratory calls.

🤔 What is the difference between Grep and Glob?

Grep searches inside files for text. Glob finds files whose names or paths match a pattern.

🤔 What if Edit cannot find a unique match?

Read the whole file, then Write the corrected content.

🏁 Summary

• Team servers in .mcp.json with ${ENV}; personal servers in ~/.claude.json.
• Resources for catalogues, tools for actions.
• Grep = contents, Glob = paths, Edit needs unique anchors.

Next, continue with CLAUDE.md Configuration Guide: Hierarchy, @import and Path-Specific Rules.

Independent study material by SQA Tools. Not affiliated with, endorsed by or sponsored by Anthropic. Claude is a trademark of Anthropic. Mock questions are original practice items, not real exam content. Exam facts checked against Anthropic's official exam guides and certification FAQ on 11 November 2026.

When a tool fails, the agent can only recover sensibly if it knows why. A generic “Operation failed” leads to pointless retries of policy violations and early surrender on simple timeouts. This is Task Statement 2.2.

🚨 The isError pattern

MCP tools signal failure with isError: true in the tool result. Put structured metadata in the content:

{
  "isError": true,
  "content": [{"type": "text", "text": "{\"errorCategory\": \"business\", \"isRetryable\": false, \"message\": \"Refund window is 30 days; this order was delivered 41 days ago.\", \"customerMessage\": \"This order is outside our 30-day refund window.\"}"}]
}

🚨 Four error categories

🚨 Empty result is not an error

“No orders found for this customer” is a successful query with zero matches. A database timeout is an access failure. Reporting empty results as errors triggers retries; reporting failures as empty results hides problems.

📘 Local recovery in multi-agent systems

Subagents should handle transient failures themselves and propagate only what they can’t resolve — with what they attempted and any partial results — so the coordinator can decide what to do next.

🧪 Exam-Style Practice Questions

Try these before opening the answers. They use the same scenario style as the real exam.

Question 1. An MCP tool times out. What should it return?

• A. A Python stack trace
• B. A result with `isError: true` and structured metadata (category transient, retryable)
• C. An empty array
• D. Nothing; let the client hang

Question 2. A search returns no matching orders for a valid customer. How should the tool report this?

• A. As an error with `isRetryable: true`
• B. By throwing a timeout
• C. As a successful result with an empty list
• D. As a permission error

Question 3. Which error should **not** be retried?

• A. Network timeout
• B. 503 Service Unavailable
• C. Rate limited
• D. "Refund exceeds the 30-day policy window"

📝 Assignment

Do these tasks in order. Each one has a Done when check, so you know when it is complete. The stretch task is optional but close to what the exam expects from an architect. Keep your answers in one notes file or Git repository, and revisit them in your final week of revision together with the cheat sheet in the last lesson of this course.

1. Task 1: List three failures your own tools can produce and classify each as transient, validation, business or permission.
   ✅ Done when: Each failure is assigned exactly one category and marked retryable or not retryable, with a reason.
2. Task 2: Write the JSON error body for a business-rule failure, including a customer-friendly message.
   ✅ Done when: Your JSON includes isError, errorCategory, isRetryable and a message a customer could read without confusion.
3. Stretch: make a subagent retry a transient error locally and report partial results to the coordinator only if it still fails.
   ✅ Done when: A simulated timeout is retried inside the subagent, and only a persistent failure reaches the coordinator with partial results.

❓ Frequently Asked Questions

🤔 What is the isError flag in MCP?

A field on the tool result that tells the client and Claude the tool call failed.

🤔 Which errors should not be retried?

Business-rule violations and permission errors. Retrying cannot change their outcome.

🤔 Is no results an error?

No. A valid query that matches nothing is a successful result with an empty list.

🤔 Why is 'Operation failed' a bad error message?

It hides whether the failure is temporary, caused by bad input or a policy, so the agent cannot choose a sensible recovery.

🏁 Summary

• Return isError plus errorCategory, isRetryable and a readable message.
• Business and permission errors are not retryable.
• Empty ≠ failure.

Next, continue with MCP Integration in Claude Code: Scopes, Resources and Built-in Tools.

Independent study material by SQA Tools. Not affiliated with, endorsed by or sponsored by Anthropic. Claude is a trademark of Anthropic. Mock questions are original practice items, not real exam content. Exam facts checked against Anthropic's official exam guides and certification FAQ on 11 November 2026.

Claude decides which tool to call mostly from the tool’s name and description. Weak descriptions are the number-one cause of misrouting, and too many tools make selection worse. This lesson covers Task Statements 2.1 and 2.3.

📘 Write descriptions that differentiate

A good tool description states what the tool does, the accepted input formats, example queries, edge cases, what it returns, and when to use it rather than a similar tool.

{
  "name": "lookup_order",
  "description": "Fetch ONE order by order number (format: # followed by 5 digits, e.g. #12345) for a customer already verified with get_customer. Use for order status, items, totals and delivery dates. Do NOT use for customer profile, address or loyalty questions — use get_customer. Returns {order_id, status, items[], total, delivered_at}.",
  "input_schema": {"type": "object",
    "properties": {"customer_id": {"type": "string"}, "order_id": {"type": "string"}},
    "required": ["customer_id", "order_id"]}
}

• Overlapping tools? Rename and rescope (analyze_content → extract_web_results), or split a generic tool into purpose-specific ones (extract_data_points, summarize_content, verify_claim_against_source).
• Check the system prompt for keyword-triggered rules (“whenever the user says account, call get_customer”) that override good descriptions.

🛠️ How many tools per agent?

Giving an agent 18 tools instead of 4–5 increases decision complexity and lowers selection reliability. Agents also misuse tools outside their speciality (a synthesis agent running web searches). Scope tools to the role, and add a narrow cross-role tool (e.g. verify_fact) only for frequent needs, routing complex cases back through the coordinator. Replace generic tools with constrained ones — fetch_url → load_document, which validates the URL.

🛠️ tool_choice options

🧪 Exam-Style Practice Questions

Try these before opening the answers. They use the same scenario style as the real exam.

Question 1. Two tools have the descriptions "Gets data" and "Gets info". What's the best first fix for misrouting?

• A. Merge them
• B. Add 8 few-shot examples
• C. Add a routing classifier
• D. Rewrite the descriptions with purpose, input formats, example queries, edge cases, and when to use each versus the other

Question 2. An agent has 18 tools and selects poorly. What's the best design move?

• A. Use `tool_choice: "any"`
• B. Add more tools for coverage
• C. Increase the temperature
• D. Give each specialised agent the 4–5 tools its role needs

Question 3. `analyze_content` and `analyze_document` keep being confused. Content-analysis is only ever used for web search results. What's the best change?

• A. Set `tool_choice` to `auto`
• B. Add "IMPORTANT" to one description
• C. Delete both
• D. Rename it to `extract_web_results` with a web-specific description

📝 Assignment

Do these tasks in order. Each one has a Done when check, so you know when it is complete. The stretch task is optional but close to what the exam expects from an architect. Keep your answers in one notes file or Git repository, and revisit them in your final week of revision together with the cheat sheet in the last lesson of this course.

1. Task 1: Rewrite two one-line tool descriptions from your own project using the purpose, inputs, examples and boundaries pattern.
   ✅ Done when: Each rewritten description names its inputs with an example, says when to use it instead of a similar tool, and states what it returns.
2. Task 2: Split a generic analyze_document tool into three purpose-specific tools with clear input and output contracts.
   ✅ Done when: Your three tools have distinct names, non-overlapping purposes and defined input and output fields.
3. Stretch: test tool_choice auto versus any on the model you use and note how it behaves.
   ✅ Done when: Your notes record what happened with each tool_choice setting, including any error the model returned.

❓ Frequently Asked Questions

🤔 How does Claude choose which tool to call?

Mainly from each tool's name and description, so descriptions must explain purpose, inputs and when to use the tool over similar ones.

🤔 How many tools should an agent have?

Ideally four or five relevant to its role. Large tool sets make selection less reliable.

🤔 What does tool_choice any do?

It forces Claude to call some tool rather than reply with text, while letting it pick which one.

🤔 Do new Claude models support forced tool_choice?

The newest models reject forced any and named tool_choice. Use auto with strict tools or structured outputs there, but answer exam questions as the exam guide teaches.

🏁 Summary

• The description is the selection signal — make it differentiate.
• Give each agent 4–5 role-relevant tools.
• auto = may call; any = must call some tool; forced = must call that tool.

Next, continue with MCP Tool Error Handling: isError, Error Categories and Retries.

Independent study material by SQA Tools. Not affiliated with, endorsed by or sponsored by Anthropic. Claude is a trademark of Anthropic. Mock questions are original practice items, not real exam content. Exam facts checked against Anthropic's official exam guides and certification FAQ on 11 November 2026.

How you split work determines whether Claude stays focused or drowns in context. The exam asks you to choose the right decomposition pattern and the right way to continue work across sessions.

✍️ Prompt chaining vs dynamic decomposition

🔍 Large code reviews: per-file plus integration

Reviewing many files in one pass dilutes attention: some files get deep feedback, others shallow, and identical code can get contradictory verdicts. Split the review into per-file passes for local issues plus a separate integration pass for cross-file data flow. A bigger context window doesn’t fix this — attention quality is the problem, not space.

📘 Open-ended tasks

For “add comprehensive tests to a legacy service”: map the structure, identify high-impact or high-risk areas, create a prioritised plan, then adapt it as dependencies are discovered.

💾 Resume, fork or start fresh?

🧪 Exam-Style Practice Questions

Try these before opening the answers. They use the same scenario style as the real exam.

Question 1. "Review this PR": each of 9 files should get the same checklist, followed by a cross-file data-flow check. Which decomposition fits?

• A. Three random full-PR passes with voting
• B. Dynamic adaptive decomposition
• C. A single pass with a larger context
• D. Prompt chaining: per-file passes, then an integration pass

Question 2. Yesterday you analysed a module in a named session. Overnight, teammates changed 3 of its 40 files. What's the best way to continue?

• A. Use the Batches API
• B. Start over and re-read all 40 files
• C. `–resume <name>` and tell the agent which 3 files changed so it re-analyses them
• D. Resume without mentioning the changes

Question 3. You want to compare two refactoring strategies starting from the same codebase analysis. Which feature fits?

• A. `fork_session`
• B. `/memory`
• C. `/compact`
• D. `–print`

📝 Assignment

Do these tasks in order. Each one has a Done when check, so you know when it is complete. The stretch task is optional but close to what the exam expects from an architect. Keep your answers in one notes file or Git repository, and revisit them in your final week of revision together with the cheat sheet in the last lesson of this course.

1. Task 1: Classify five tasks from your own work as prompt chaining or dynamic decomposition.
   ✅ Done when: Each of your five tasks is labelled, with a one-line reason that mentions whether its steps are known in advance.
2. Task 2: Plan a review of a 12-file pull request as per-file passes plus an integration pass.
   ✅ Done when: Your plan lists every file pass plus a separate integration pass, and says what the integration pass checks.
3. Stretch: in Claude Code, resume a named session after changing two files and tell it exactly which files changed.
   ✅ Done when: Claude re-analyses only the two changed files and does not re-read the whole codebase.

❓ Frequently Asked Questions

🤔 What is prompt chaining?

A fixed sequence of focused steps, such as reviewing each file and then running an integration pass. It suits predictable work.

🤔 When should I use dynamic decomposition?

For open-ended tasks where the next steps depend on what you discover, such as adding tests to a legacy codebase.

🤔 Does a bigger context window fix inconsistent reviews?

No. The problem is attention dilution, so split the review into focused passes.

🤔 When should I fork a session?

When you want to compare two approaches starting from the same analysis.

🏁 Summary

• Predictable multi-aspect work → prompt chaining; open-ended work → dynamic decomposition.
• Big reviews → per-file passes plus an integration pass.
• Resume when context is valid, fork to compare approaches, start fresh with a summary when it is stale.

Next, continue with Claude Tool Design: Descriptions, Tool Distribution and tool_choice.

Independent study material by SQA Tools. Not affiliated with, endorsed by or sponsored by Anthropic. Claude is a trademark of Anthropic. Mock questions are original practice items, not real exam content. Exam facts checked against Anthropic's official exam guides and certification FAQ on 11 November 2026.

Prompt instructions are probabilistic: even a well-written rule fails a small percentage of the time. When a business rule must always hold — verify identity before a refund, never refund over a limit — the exam expects programmatic enforcement (Task Statements 1.4 and 1.5).

✍️ Prompt guidance vs programmatic enforcement

🚧 Prerequisite gates

A gate blocks a downstream tool until an upstream step has succeeded — for example, process_refund is rejected unless get_customer returned a verified customer ID in this session.

def guard(tool_name, tool_input, session):
    if tool_name in {"lookup_order", "process_refund"} and not session.verified_customer_id:
        return deny("Verify the customer with get_customer first.")
    if tool_name == "process_refund" and tool_input["amount"] > 500:
        return redirect("escalate_to_human", reason="Refund above $500 needs approval")
    return allow()

🪝 The two hook patterns the exam tests

• Tool-call interception (pre-tool) — inspects outgoing calls and blocks or redirects policy-violating ones (refunds over a threshold, rm -rf, writes to production paths).
• PostToolUse — transforms tool results before the model sees them, e.g. normalising Unix epochs, ISO-8601 strings and numeric status codes from different MCP servers into one format, or trimming verbose results to the relevant fields.

📘 Multi-concern requests

“My item arrived broken, I was double-charged, and my address is wrong” is three concerns. Decompose them, investigate each (in parallel where possible) using shared context, then send one combined resolution. Having several issues is not, by itself, a reason to escalate.

🤝 Structured human handoffs

Human agents usually can’t see the bot transcript. When escalating, pass a structured summary: customer ID, the issue, the root cause found, actions already taken, amounts, and the recommended next step.

🧪 Exam-Style Practice Questions

Try these before opening the answers. They use the same scenario style as the real exam.

Question 1. Identity must be verified before any refund. What's the strongest implementation?

• A. Few-shot examples
• B. A post-hoc audit log
• C. A system-prompt rule
• D. A programmatic gate that rejects `process_refund` unless `get_customer` returned a verified ID in this session

Question 2. What does a PostToolUse hook typically do in this exam's context?

• A. Blocks dangerous outgoing tool calls
• B. Compacts the conversation
• C. Transforms or normalises tool results before the model processes them
• D. Selects which tool to call

Question 3. When should you choose a hook over a prompt instruction?

• A. Whenever you want shorter prompts
• B. When a business rule needs a guaranteed outcome
• C. Never; hooks add latency
• D. Only for logging

📝 Assignment

Do these tasks in order. Each one has a Done when check, so you know when it is complete. The stretch task is optional but close to what the exam expects from an architect. Keep your answers in one notes file or Git repository, and revisit them in your final week of revision together with the cheat sheet in the last lesson of this course.

1. Task 1: Write pseudo-code for a gate that blocks process_refund until get_customer has verified the customer.
   ✅ Done when: Your gate denies the refund call when verification is missing and allows it once get_customer has returned verified.
2. Task 2: Add a threshold rule that redirects refunds over $500 to escalate_to_human.
   ✅ Done when: A refund of $501 is redirected to escalation, while a refund of $499 goes through unchanged.
3. Stretch: write a PostToolUse function that converts Unix epochs and ISO-8601 strings into one date format.
   ✅ Done when: Both 1731000000 and '2024-11-07T17:20:00Z' come out of your function in the same format.

❓ Frequently Asked Questions

🤔 When should I use a hook instead of a prompt instruction?

When a rule must hold every time, such as identity checks, refund limits or blocking destructive commands. Prompts are probabilistic.

🤔 What does a PostToolUse hook do?

It transforms a tool's result before Claude sees it, for example normalising formats or trimming irrelevant fields.

🤔 Should a multi-issue request be escalated?

Not automatically. Split it into separate concerns, investigate each, and send one combined resolution.

🤔 What should a human handoff include?

Customer ID, the issue, the root cause found, actions taken, amounts involved and the recommended next step.

🏁 Summary

• “Must always” → hooks and gates. “Should usually” → prompts.
• Pre-tool interception blocks or redirects calls; PostToolUse normalises results.
• Escalations carry a structured handoff summary.

Next, continue with Task Decomposition and Session Management in Claude Code.

Independent study material by SQA Tools. Not affiliated with, endorsed by or sponsored by Anthropic. Claude is a trademark of Anthropic. Mock questions are original practice items, not real exam content. Exam facts checked against Anthropic's official exam guides and certification FAQ on 11 November 2026.

Multi-agent systems split a large job across specialised agents. The exam focuses on the coordinator–subagent pattern used by the Claude Agent SDK, and on the mistakes that make such systems produce incomplete or unattributed results (Task Statements 1.2 and 1.3).

🕸️ Hub-and-spoke architecture

A coordinator agent decomposes the task, decides which subagents to invoke, delegates, aggregates results and handles errors. Subagents never talk to each other directly — every message goes through the coordinator. That gives you observability, consistent error handling and controlled information flow.

• Select subagents per query. A simple factual question should not run the full search → analysis → synthesis → report pipeline.
• Partition the scope. Give each subagent distinct subtopics or source types so work isn’t duplicated.
• Refine iteratively. The coordinator checks the synthesis for gaps, re-delegates targeted queries, and re-runs synthesis until coverage is sufficient.

🤖 Spawning subagents in the Agent SDK

• Subagents are spawned with the Task tool. The coordinator’s allowedTools must include "Task", or it cannot delegate.
• Each subagent type is configured with an AgentDefinition: a description, a system prompt and tool restrictions.
• To run subagents in parallel, the coordinator emits several Task calls in one response — not one per turn.

🤖 Subagents start with an empty context

Subagents do not inherit the coordinator’s conversation and don’t share memory between invocations. Anything a subagent needs must be in its prompt.

{
  "task": "Synthesise findings on EU battery regulation",
  "quality_bar": "Two independent sources per claim; flag conflicts",
  "findings": [
    {"claim": "Battery passport required from Feb 2027",
     "excerpt": "...",
     "source_url": "https://example.org/reg",
     "published": "2025-08-14"}
  ]
}

Structured data that separates content from metadata (URL, document, page, date) keeps attribution intact across handoffs. Write coordinator prompts as goals and quality criteria, not step-by-step procedures, so subagents can adapt to what they find.

🧪 Exam-Style Practice Questions

Try these before opening the answers. They use the same scenario style as the real exam.

Question 1. A research report on "renewable energy policy" covers only solar subsidies. Every subagent completed its assignment successfully. Coordinator logs show the subtasks "solar tax credits", "solar feed-in tariffs" and "rooftop solar rebates". What's the root cause?

• A. The analysis agent filters out wind sources
• B. The synthesis agent drops content
• C. The search agent's queries are too narrow
• D. The coordinator's decomposition was too narrow

Question 2. A subagent receives the task "Synthesise the findings" and produces generic text. Why?

• A. It needs `context: fork`
• B. Subagents can't read JSON
• C. Its model is too small
• D. It doesn't automatically inherit the coordinator's history, so the findings must be in its prompt

Question 3. A subagent should run in parallel with two others. Where do the three Task calls go?

• A. In three consecutive coordinator turns
• B. In separate sessions started by a cron job
• C. In a single coordinator response
• D. In a batch request

📝 Assignment

Do these tasks in order. Each one has a Done when check, so you know when it is complete. The stretch task is optional but close to what the exam expects from an architect. Keep your answers in one notes file or Git repository, and revisit them in your final week of revision together with the cheat sheet in the last lesson of this course.

1. Task 1: Sketch a coordinator with three subagents for a research task and list the tools each subagent gets (no more than five).
   ✅ Done when: Every subagent has a one-line role and no more than five tools, and no tool is given to a subagent that does not need it.
2. Task 2: Write the JSON you would pass to a synthesis subagent, including claim, excerpt, source URL and date for two findings.
   ✅ Done when: Your JSON keeps content and metadata in separate fields, so a synthesis agent could cite each claim correctly.
3. Stretch: write a coordinator prompt that states goals and quality criteria without step-by-step instructions.
   ✅ Done when: Your coordinator prompt states the goal and at least three quality criteria, and contains no numbered step-by-step instructions.

❓ Frequently Asked Questions

🤔 Do subagents see the coordinator's conversation?

No. Subagents start with isolated context, so the coordinator must put everything they need in their prompt.

🤔 How do I run subagents in parallel?

Have the coordinator emit several Task tool calls in a single response instead of one per turn.

🤔 Why route everything through the coordinator?

It gives you observability, consistent error handling and control over what information each agent sees.

🤔 What causes a report to miss whole topics?

Usually the coordinator decomposed the topic too narrowly, even though each subagent completed its own task.

🏁 Summary

• All communication flows through the coordinator.
• "Task" must be in the coordinator’s allowedTools; parallel = multiple Task calls in one turn.
• Pass context explicitly, as structured data with source metadata.
• Missing coverage with “successful” subagents → narrow decomposition.

Next, continue with Claude Agent SDK Hooks, Prerequisite Gates and Human Handoffs.

Independent study material by SQA Tools. Not affiliated with, endorsed by or sponsored by Anthropic. Claude is a trademark of Anthropic. Mock questions are original practice items, not real exam content. Exam facts checked against Anthropic's official exam guides and certification FAQ on 11 November 2026.

Every Claude agent — whether you write it yourself or use the Agent SDK — is built on one loop: ask Claude, run the tools it requests, give it the results, repeat. Get the stop condition wrong and your agent either quits mid-task or never finishes. This is Task Statement 1.1 of the exam.

🔁 The loop, step by step

1. Send the conversation (and tool definitions) to the Messages API.
2. Inspect stop_reason on the response.
3. If it is "tool_use": run each requested tool and append one user message containing every tool_result block, matched by tool_use_id.
4. Call Claude again with the updated history.
5. Stop when stop_reason is "end_turn".

messages = [{"role": "user", "content": user_question}]
while True:
    resp = client.messages.create(model=MODEL, max_tokens=4096,
                                  tools=TOOLS, messages=messages)
    messages.append({"role": "assistant", "content": resp.content})
    if resp.stop_reason != "tool_use":       # "end_turn" (also handle max_tokens, refusal)
        break
    results = []
    for block in resp.content:
        if block.type == "tool_use":
            results.append(run_tool(block))      # returns a tool_result dict
    messages.append({"role": "user", "content": results})   # ALL results, ONE message

📘 Why the model chooses the next step

In an agent, Claude reasons about which tool to call next from the context, including the results it has just seen. That is the difference from a pre-configured decision tree, where code fixes the sequence. Tool results must be appended to the history, otherwise the model cannot use them and will often request the same tool again.

⚠️ Termination anti-patterns (exam favourites)

🛑 Other stop reasons you should know

🧪 Exam-Style Practice Questions

Try these before opening the answers. They use the same scenario style as the real exam.

Question 1. Which loop condition is correct for a manual Claude agentic loop?

• A. Loop until the assistant message contains no text
• B. Loop until the model says "DONE"
• C. Loop while `stop_reason == "tool_use"`, stop on `"end_turn"`
• D. Loop exactly 5 times

Question 2. After executing the three tool calls Claude requested in one turn, how should you return the results?

• A. Three separate user messages, one per result
• B. Put the results in the system prompt
• C. One assistant message with the results
• D. One user message containing three `tool_result` blocks, each with its `tool_use_id`

Question 3. What best distinguishes an *agent* from a *workflow*?

• A. In an agent the model decides the next action from context; in a workflow, code defines the path
• B. Workflows can't use tools
• C. Agents never need a system prompt
• D. Agents use bigger models

📝 Assignment

Do these tasks in order. Each one has a Done when check, so you know when it is complete. The stretch task is optional but close to what the exam expects from an architect. Keep your answers in one notes file or Git repository, and revisit them in your final week of revision together with the cheat sheet in the last lesson of this course.

1. Task 1: Implement the loop from this lesson with one tool (get_weather returning fixed data) and print stop_reason on every iteration.
   ✅ Done when: Your script prints tool_use and then end_turn, and the final answer uses the tool's data.
2. Task 2: Deliberately break it by stopping on 'response contains text'. Find a prompt where Claude writes a sentence and a tool call together and observe the failure.
   ✅ Done when: You can show a transcript where the broken loop stops early, and explain in one sentence why stop_reason fixes it.
3. Stretch: add handling for max_tokens and refusal stop reasons with a clear message to the user.
   ✅ Done when: A response cut off by max_tokens or a refusal produces a clear message instead of a crash or a silent empty answer.

❓ Frequently Asked Questions

🤔 What stop_reason means Claude wants a tool run?

tool_use. Run every tool_use block in the response and send all results back in one user message.

🤔 Why not stop when the response contains text?

Claude often writes a short sentence and a tool call in the same turn, so text alone does not mean the task is finished.

🤔 Is an iteration cap wrong?

A cap is a good safety backstop, but it should never be the main way the loop decides it is done.

🤔 What happens if I forget to append tool results?

Claude cannot see the results, so it usually asks for the same tool again and the loop repeats.

🏁 Summary

• Loop on stop_reason == "tool_use"; stop on "end_turn".
• Return every tool result for a turn in a single user message.
• Never terminate on text content, phrases or a bare iteration count.

Next, continue with Multi-Agent Orchestration with Claude: Coordinators and Subagents.

Independent study material by SQA Tools. Not affiliated with, endorsed by or sponsored by Anthropic. Claude is a trademark of Anthropic. Mock questions are original practice items, not real exam content. Exam facts checked against Anthropic's official exam guides and certification FAQ on 11 November 2026.

The CCAR-F exam shows you four of six scenarios, picked at random. Each scenario frames 10–15 questions, so knowing the setup in advance saves you minutes of reading and helps you spot what each question is really testing.

🎬 Scenario 1: Customer Support Resolution Agent

An Agent SDK agent handles returns, billing disputes and account issues through MCP tools such as get_customer, lookup_order, process_refund and escalate_to_human, targeting 80%+ first-contact resolution.

What it tests: prerequisite gates (verify before refund), interception hooks for thresholds, multi-concern requests, structured errors, escalation calibration, handoff summaries and preserving case facts in long conversations.

🎬 Scenario 2: Code Generation with Claude Code

A team uses Claude Code for generation, refactoring, debugging and documentation with custom slash commands and CLAUDE.md.

What it tests: the CLAUDE.md hierarchy, .claude/rules/ with path globs, commands vs skills, skill frontmatter, plan mode vs direct execution, iterative refinement and context degradation.

🎬 Scenario 3: Multi-Agent Research System

A coordinator delegates to search, document-analysis, synthesis and report subagents to produce cited reports.

What it tests: decomposition breadth, explicit context passing, parallel Task calls, scoped tools, error propagation, conflicting sources and provenance.

🎬 Scenario 4: Developer Productivity with Claude

An Agent SDK assistant explores codebases and automates chores using built-in tools (Read, Write, Edit, Bash, Grep, Glob) and MCP servers.

What it tests: built-in tool selection, incremental exploration, MCP scoping and resources, tool descriptions that beat built-ins, session resume and fork.

🎬 Scenario 5: Claude Code for Continuous Integration

Claude Code reviews pull requests and generates tests in CI, with a focus on actionable, low-false-positive feedback.

What it tests: -p, --output-format json + --json-schema, CLAUDE.md as CI context, independent reviewers, explicit criteria, multi-pass review and batch-vs-synchronous decisions.

🎬 Scenario 6: Structured Data Extraction

Unstructured documents are turned into JSON validated against schemas and passed downstream.

What it tests: tool_use with JSON schemas, nullable fields, enum design, validation-retry loops, batch processing, confidence calibration and human-review routing.

🧪 Exam-Style Practice Questions

Try these before opening the answers. They use the same scenario style as the real exam.

Question 1. A customer message says: "My order arrived damaged, I was double-charged, and I want to change my email." What's the best agent strategy?

• A. Answer the easiest issue first and end the session
• B. Handle only the first issue and ask them to open new tickets
• C. Split into three items, investigate each (in parallel where possible) using shared context, then give one unified reply
• D. Escalate, because it's multi-issue

Question 2. Your CI posts Claude's review findings as inline PR comments. What output configuration should you use?

• A. Markdown output
• B. Default text output parsed with regexes
• C. `–verbose`
• D. `–output-format json` with `–json-schema` defining the findings structure

Question 3. The synthesis output should show readers which sections rest on thin evidence because a source failed. What should you add?

• A. Nothing; keep it clean
• B. Remove the affected sections
• C. Coverage annotations marking well-supported findings versus gaps from unavailable sources
• D. A generic disclaimer

📝 Assignment

Do these tasks in order. Each one has a Done when check, so you know when it is complete. The stretch task is optional but close to what the exam expects from an architect. Keep your answers in one notes file or Git repository, and revisit them in your final week of revision together with the cheat sheet in the last lesson of this course.

1. Task 1: For each scenario, write one sentence describing a system you have built or seen that is similar.
   ✅ Done when: Each of the six scenarios has one sentence describing a real or familiar system, so you can picture it on exam day.
2. Task 2: Map each scenario to its two most-tested domains without looking back at the lesson.
   ✅ Done when: Your mapping matches the lesson for at least five of the six scenarios when you compare it afterwards.
3. Stretch: draft one exam-style question of your own for Scenario 6 with four options and an explanation.
   ✅ Done when: Your question has one clearly correct answer, three plausible distractors, and an explanation of why each distractor is wrong.

❓ Frequently Asked Questions

🤔 How many scenarios appear on the CCAR-F exam?

Four, picked at random from a bank of six. Each frames roughly 15 questions.

🤔 Which scenario is best for QA engineers?

Scenario 5, Claude Code for Continuous Integration, and Scenario 6, Structured Data Extraction, are closest to test-automation work.

🤔 Do I need to memorise the tool names in the scenarios?

No, but knowing the setup (for example get_customer before process_refund) saves reading time and helps you spot what a question tests.

🤔 Do the mock tests use the same scenarios?

Yes. The five mock tests on this site rotate through all six scenarios so you meet each one at least twice.

🏁 Summary

• Scenarios 1, 3 and 6 lean on Domains 1, 4 and 5; Scenarios 2, 4 and 5 lean on Domains 2 and 3.
• Read the scenario once, carefully — every question in that block assumes you remember it.
• Our five mock tests rotate through all six scenarios so you meet each at least twice.

Next, continue with Claude Agentic Loop: stop_reason, Tool Results and Anti-Patterns.

Independent study material by SQA Tools. Not affiliated with, endorsed by or sponsored by Anthropic. Claude is a trademark of Anthropic. Mock questions are original practice items, not real exam content. Exam facts checked against Anthropic's official exam guides and certification FAQ on 11 November 2026.