How to use this roadmap
Click a day's checkbox when you finish it — progress saves to your browser automatically. Click a phase header to collapse/expand.
Your local resources:
- • Official exam guide PDF — the source of truth
- • paullarionov study guide — 13 foundational chapters + 5 domain task statements (HTML, with TOC)
- • paullarionov practical_test_en.html — practice questions
- • daronyondem prep guide — narrative prep guide (HTML, with TOC)
- • Skilljar — Anthropic Academy (official free courses). 7 courses on the public catalog map directly to exam domains; specific courses and modules are linked per day below.
- • References page — every external source used in this study pack, organized by category, plus video explainers for the trickier concepts.
Domain weights: D1 Agentic Architecture 27% · D2 Tool Design & MCP 18% · D3 Claude Code 20% · D4 Prompt Engineering 20% · D5 Context & Reliability 15%
▼
Phase 1 · Orientation & API Foundations
Days 1–5DAY 01Orientation: read the exam guide end to endFoundations
Read the full 30-page official exam guide. Don't take notes — just absorb the shape of the exam: 5 domains, 6 scenarios, the format of sample questions, the pass mark (720/1000).
Objectives
- Know the 5 domains and their weightings by heart
- Recognize all 6 exam scenarios by name
- Read the 9 sample questions + answer rationales carefully
DAY 02Messages API: structure, roles, and stop_reasonFoundations
Understand the fundamental building block: a Messages API request. Roles (user/assistant/tool), how conversation history accumulates, and the critical
stop_reason field that drives every agentic loop.Objectives
- Explain why the API is stateless
- List the possible values of
stop_reasonand what each means - Understand why you inspect
stop_reason, NOT parse assistant text, to decide next action
DAY 03System prompts and context windowsFoundations
System prompts shape behavior; context windows bound what the model sees. Learn how tokens are counted, how the "lost in the middle" effect works, and why keyword-sensitive instructions matter.
Objectives
- Describe the lost-in-the-middle phenomenon
- Know Claude's typical context window sizes
- Understand that every turn resends the full history
DAY 04Tool use fundamentals and tool definitionsFoundations
Tools are how the model affects the world. Study the tool definition structure (name, description, input_schema), why descriptions are the primary selection mechanism, and what a
tool_use response block looks like.Objectives
- Write a well-formed tool definition from memory
- Explain why tool descriptions outrank system prompts for tool selection
- Recognize the
tool_use→tool_resultround-trip
DAY 05tool_choice modes: auto, any, forcedFoundations
The
tool_choice parameter is a common exam hook. Learn the three modes and when each is right: "auto" (model decides), "any" (must call some tool), {"type":"tool","name":"..."} (forced).Objectives
- Match each mode to its use case
- Know that
"any"guarantees tool call when you need structured output - Know when forced selection matters (e.g., forcing extract_metadata before enrichment)
▼
Phase 2 · Structured Output & Error Basics
Days 6–9DAY 06JSON schemas for structured outputFoundations
Tool use with JSON schemas is the most reliable way to get machine-parseable output. Study required vs optional fields, enum with "other" + detail pattern, and nullable fields for missing data.
Objectives
- Design a schema with required + optional fields
- Explain why nullable fields prevent fabrication
- Know the
enum + "other" + detailpattern for extensible categories
DAY 07Syntax vs semantic errorsFoundations
Tool use via JSON schema eliminates syntax errors — but NOT semantic ones (line items that don't sum, values in wrong fields). Learn to distinguish these because they need different fixes.
Objectives
- Give 3 examples of semantic errors that pass schema validation
- Know retry-with-error-feedback fixes semantic errors when info exists in the source
- Know retries don't help when required info is absent
DAY 08Error categories: transient, validation, business, permissionFoundations
Four categories of errors drive different recovery strategies. Transient errors (timeout) can retry; business rule errors cannot. Returning a generic "Operation failed" hides context the agent needs.
Objectives
- Classify 10 real error messages into the four categories
- Design a structured error response with
errorCategory,isRetryable, human-readable message - Understand the third "uncertain state" category (write timeouts)
DAY 09Error-handling anti-patternsFoundations
Study what NOT to do: silent suppression (returning empty success on failure), generic "search unavailable" status, throwing exceptions instead of
isError flags, terminating entire workflows on one failure.Objectives
- Internalize: return errors as tool output with
isError: true, not as exceptions - Distinguish access failures from valid empty results
- Connect this to Sample Question 8 in the exam guide
▼
Phase 3 · Domain 1: Agentic Architecture & Orchestration
Days 10–22 · 27%DAY 10What is an agentic loop?Domain 1
The agentic loop is: send request → inspect
stop_reason → if "tool_use", execute tools and append results, loop; if "end_turn", stop. This is the foundation of everything.Objectives
- Draw the loop on paper without references
- Know that checking for assistant text as a completion signal is an anti-pattern
- Know that arbitrary iteration caps are a weak stopping mechanism
DAY 11Hands-on: build a raw agentic loopDomain 1
Write Python or TypeScript that loops the Messages API directly. Give it one tool (e.g.,
get_weather). Iterate until stop_reason == "end_turn". Append tool results to history each turn.Objectives
- Have a working, runnable loop script
- See the full conversation history growing each turn
- Confirm you handle both stop reasons correctly
DAY 12AgentDefinition config in the Agent SDKDomain 1
Now the Agent SDK abstracts the loop. Study
AgentDefinition: system prompts, tool restrictions, allowedTools, and why each subagent needs its own definition.Objectives
- Write a valid
AgentDefinitionfor a "web search" subagent - Know that
allowedToolsmust include"Task"for a coordinator - Understand how agent-specific system prompts differ from the main session
DAY 13Hub-and-spoke: coordinator + subagentsDomain 1
The canonical multi-agent pattern. All inter-subagent communication flows through the coordinator. Subagents DON'T inherit parent context — you must pass it explicitly in the prompt.
Objectives
- Draw a 4-agent hub-and-spoke diagram (coordinator + 3 subagents)
- Explain why routing through the coordinator improves observability
- Recognize the "narrow decomposition" failure mode (Sample Q7)
DAY 14The Task tool: spawning subagents in parallelDomain 1
Subagents are spawned via the Task tool. Emit multiple Task calls in a single coordinator response to spawn them in parallel. Pass findings from prior agents in subsequent prompts.
Objectives
- Know the Task tool's parameters and expected behavior
- Understand why parallel spawning (single response) beats sequential turns
- Practice: spawn 2 parallel subagents that both feed into a synthesis agent
DAY 15Agent SDK hooks: PreToolUse, PostToolUseDomain 1
Hooks intercept tool calls or results.
PostToolUse normalizes data (e.g., unix timestamp → ISO 8601) before the model sees it. PreToolUse-style gates block policy violations (e.g., refunds > $500).Objectives
- Write a hook that normalizes mixed timestamp formats
- Write a hook that blocks an outgoing call based on a parameter threshold
- Know: when compliance is required, hooks > prompts (Sample Q1)
DAY 16Multi-step workflow enforcement: gates vs promptsDomain 1
When Tool B must run only after Tool A (e.g.,
process_refund requires a verified customer ID from get_customer), enforce programmatically, not via prompt instruction. Prompt compliance is probabilistic.Objectives
- Build a prerequisite gate that blocks downstream calls until prior data is present
- Know that even strong prompt instructions have a non-zero failure rate
- Understand when structural enforcement is worth the complexity
DAY 17Structured handoff protocols for human escalationDomain 1
When an agent escalates, it must hand off a structured summary: customer ID, root cause, refund amount, recommended action. Human agents don't see the conversation transcript.
Objectives
- Design a JSON structure for an escalation handoff
- Know that acknowledging frustration while offering resolution is valid — escalate only on reiterated request
- Internalize: explicit human request = immediate escalation (no investigation)
DAY 18Task decomposition: fixed pipelines (prompt chaining)Domain 1
Fixed sequential pipelines work when the steps are predictable: e.g., analyze each file locally, then run a cross-file integration pass. Splits large tasks to avoid attention dilution.
Objectives
- Give 3 examples where prompt chaining is the right choice
- Know: per-file local analysis + separate cross-file integration pass avoids attention dilution
- Contrast with dynamic decomposition
DAY 19Task decomposition: dynamic adaptive plansDomain 1
Open-ended tasks ("add comprehensive tests to a legacy codebase") can't be pre-planned. Adaptive decomposition: first map structure, identify high-impact areas, then generate subtasks based on findings.
Objectives
- Know when dynamic decomposition beats a fixed pipeline
- Describe an adaptive investigation plan for a legacy migration
- Understand that coordinator prompts should state goals + quality criteria, not procedural steps
DAY 20Session state: named sessions and --resumeDomain 1
Long-running investigations use
--resume <session-name> to continue across work sessions. When files change, inform the agent of specific edits — don't rely on stale tool results.Objectives
- Use
--resumewith a session name on a real project - Know: starting fresh with an injected summary beats resuming with stale tool results
- Understand when to inform the resumed session about specific file changes
DAY 21fork_session for divergent explorationDomain 1
fork_session creates independent branches from a shared baseline. Use it to compare two refactoring approaches or testing strategies from the same codebase analysis.Objectives
- Fork a session to compare two approaches from a shared baseline
- Know the difference between fork_session and --resume
- Understand why forking preserves the expensive analysis step
DAY 22Domain 1 review + practice questionsDomain 1
Re-read all Domain 1 task statements. Take every Domain 1 question in
practical_test_en.html. For each wrong answer, map it back to the specific task statement and write a one-line rule.Objectives
- Score ≥ 75% on Domain 1 practice questions
- Start a NOTES.md file with one-line rules for weak areas
- Re-read Sample Q1, Q7, Q8 in the exam guide
▼
Phase 4 · Domain 2: Tool Design & MCP Integration
Days 23–30 · 18%DAY 23Writing tool descriptions that LLMs actually readDomain 2
Tool descriptions are the PRIMARY selection mechanism. Include: what it does, when to use it vs alternatives, input formats with examples, expected output shape. Sample Q2 is a direct test of this.
Objectives
- Rewrite 3 weak tool descriptions into strong ones
- Know: when two tools overlap, fix descriptions first — not routing layers, not consolidation
- Understand why
account_number_integer_eight_digits< a concise description with example
DAY 24Lookup-then-act pattern and entity resolutionDomain 2
When users reference entities by free text ("my order from Tuesday"), split into a lookup tool (returns IDs) and an act tool (takes the ID). Prevents ambiguous parameter binding at the root.
Objectives
- Refactor a single ambiguous tool into a lookup + act pair
- Know: multiple customer matches → ask for clarification, don't heuristically pick
- Understand that splitting by interdependent constraints is a structural safety mechanism
DAY 25Structured MCP errors: isError, errorCategory, isRetryableDomain 2
MCP's
isError flag signals failure via tool output, not exceptions. Structured metadata (errorCategory, isRetryable: false, human-readable message) lets the agent make intelligent recovery decisions.Objectives
- Implement a structured error response in a mock MCP tool
- Know to distinguish access failures from valid empty results
- Understand why subagents should locally recover transient errors before propagating
DAY 26Tool allocation: 4-5 tools beats 18Domain 2
Too many tools degrades selection reliability. Scope each subagent to 4-5 tools directly relevant to its role. For high-frequency cross-role needs, provide a narrow scoped helper (e.g.,
verify_fact on the synthesis agent — see Sample Q9).Objectives
- Design tool allocation for a 3-subagent research system
- Know:
tool_choice: "any"to force a tool call; forced selection for a specific tool - Understand when to add a scoped cross-role tool vs always routing through coordinator
DAY 27MCP server scoping: .mcp.json vs ~/.claude.jsonDomain 2
Project-level
.mcp.json = shared team tooling (committed). User-level ~/.claude.json = personal/experimental. Env expansion (${GITHUB_TOKEN}) keeps secrets out of source control.Objectives
- Configure a real MCP server in a project .mcp.json with env var expansion
- Know which scope to choose for a team Jira integration vs a personal scratchpad
- Understand that all configured MCP tools are discovered at connection time
DAY 28MCP resources: content catalogs for agentsDomain 2
MCP resources expose content catalogs (issue summaries, doc hierarchies, DB schemas) so agents don't waste tool calls exploring. Resources reduce exploratory overhead on large knowledge bases.
Objectives
- Know when to use resources vs tools
- Prefer community MCP servers for standard integrations; reserve custom for team-specific workflows
- Understand how enhanced MCP tool descriptions prevent the agent from defaulting to built-ins
DAY 29Built-in tools: Read, Write, Edit, Bash, Grep, GlobDomain 2
Grep for content search, Glob for path patterns, Read for full file loads, Edit for targeted modifications (fails on non-unique text — fallback to Read+Write). Build understanding incrementally.
Objectives
- Memorize the primary use case for each built-in tool
- Know the Read + Write fallback when Edit can't find unique anchor text
- Understand the investigation strategy: Grep entry points → Read imports → trace flows
DAY 30Domain 2 review + practiceDomain 2
Take all Domain 2 questions in the practical test. Re-read Sample Q2 and Q9. Add any new rules to NOTES.md.
Objectives
- Score ≥ 75% on Domain 2 practice questions
- Internalize: tool description fixes come BEFORE routing layers or consolidation
- Confirm you can configure .mcp.json from memory
▼
Phase 5 · Domain 3: Claude Code Configuration & Workflows
Days 31–38 · 20%DAY 31CLAUDE.md hierarchy: user, project, directoryDomain 3
Three levels:
~/.claude/CLAUDE.md (personal, not shared), .claude/CLAUDE.md or root CLAUDE.md (project, shared via VCS), subdirectory CLAUDE.md (directory-scoped).Objectives
- Know which scope to pick for team standards vs personal preferences
- Recognize the "new teammate doesn't have my instructions" diagnosis
- Use
/memoryto inspect what's loaded
DAY 32@import syntax for modular CLAUDE.mdDomain 3
Use
@path/to/file.md inside CLAUDE.md to include other standards files. Keeps monorepos with many packages from ending up with a monolithic CLAUDE.md.Objectives
- Set up a package-level CLAUDE.md that imports shared standards
- Know the difference between @import and subdirectory CLAUDE.md
- Understand when to split vs consolidate
DAY 33.claude/rules/ with glob path scopingDomain 3
Rule files with YAML frontmatter (
paths: ["**/*.test.tsx"]) load only when editing matching files. Better than subdirectory CLAUDE.md for conventions that span the codebase. This is Sample Q6.Objectives
- Write a .claude/rules/testing.md with a glob path
- Know: when conventions span directories, .claude/rules wins over subdirectory CLAUDE.md
- Understand why this reduces irrelevant context / token usage
DAY 34Custom slash commands: project vs personalDomain 3
Project-scoped commands in
.claude/commands/ are shared via VCS; user-scoped in ~/.claude/commands/ are personal. Sample Q4 is a direct test. Create a real /review command.Objectives
- Create a project-scoped /review slash command from scratch
- Know: "available to every developer on clone/pull" = project scope
- Understand that CLAUDE.md is for context, not command definitions
DAY 35Skills: SKILL.md with frontmatter (context: fork, allowed-tools)Domain 3
Skills in
.claude/skills/ are on-demand workflows. Frontmatter options: context: fork (isolates output from main session), allowed-tools (restricts destructive actions), argument-hint.Objectives
- Write a SKILL.md with context: fork for a verbose codebase analysis
- Know when to use a skill (on-demand) vs CLAUDE.md (always-loaded)
- Understand why personal skill variants go in ~/.claude/skills/
DAY 36Plan mode vs direct executionDomain 3
Plan mode: complex tasks, multiple valid approaches, architectural decisions, multi-file changes. Direct execution: single-file bug fixes, well-scoped edits. Sample Q5 is microservice restructuring = plan mode.
Objectives
- Classify 5 tasks as plan mode vs direct execution
- Know the Explore subagent for isolating verbose discovery output
- Understand the "plan first, execute after" combo pattern
DAY 37Claude Code in CI/CD: -p, --output-format json, --json-schemaDomain 3
Run non-interactively with
-p. Enforce structured output with --output-format json --json-schema schema.json. CLAUDE.md provides context (testing standards, review criteria) to CI-invoked runs.Objectives
- Run Claude Code headlessly on a sample repo producing JSON-schema output
- Know: independent review instance > self-review (session retains bias)
- Know how to pass prior review findings to avoid duplicate comments
DAY 38Iterative refinement + Domain 3 reviewDomain 3
Iterative refinement: 2-3 concrete input/output examples when prose fails; test-driven iteration; interview pattern (have Claude ask questions first). Then take all Domain 3 practice questions.
Objectives
- Use the interview pattern on a real unfamiliar feature
- Score ≥ 75% on Domain 3 practice
- Re-read Sample Q4, Q5, Q6
▼
Phase 6 · Domain 4: Prompt Engineering & Structured Output
Days 39–46 · 20%DAY 39Explicit criteria over vague instructionsDomain 4
"Be conservative" and "only report high-confidence findings" don't improve precision. Specific categorical criteria do: "flag comments only when claimed behavior contradicts actual code behavior."
Objectives
- Rewrite 3 vague prompts into explicit categorical criteria
- Know why LLM self-reported confidence is a poor filter
- Understand: temporarily disable high-false-positive categories to restore developer trust
DAY 40Few-shot prompting for consistencyDomain 4
Few-shot examples are the most effective technique when detailed instructions alone produce inconsistent output. 2-4 targeted examples for ambiguous cases. Show reasoning for why one action was chosen.
Objectives
- Add 2-4 few-shot examples to a struggling extraction prompt, measure improvement
- Know: few-shot for varied document structures (inline vs bibliographic citations)
- Understand few-shot enables generalization to novel patterns — not just matching examples
DAY 41Prompt chaining: sequential passesDomain 4
Break reviews into sequential steps: analyze each file individually, then cross-file integration. Prevents attention dilution on large multi-file tasks.
Objectives
- Design a prompt chain for a multi-file code review
- Know when to chain vs have one big prompt
- Understand attention dilution effects on large inputs
DAY 42Interview pattern for unfamiliar domainsDomain 4
When implementing in an unfamiliar domain, have Claude ask questions first to surface considerations you hadn't anticipated (cache invalidation strategies, failure modes).
Objectives
- Use the interview pattern on a real unfamiliar problem
- Know the difference: interactive interview vs test-driven iteration
- Understand when single-message batch vs sequential messages
DAY 43Validation, retry-with-feedback, self-correctionDomain 4
On validation failure, append the original document + failed extraction + specific errors to the retry prompt. Add
calculated_total vs stated_total and conflict_detected booleans for self-correction.Objectives
- Implement a retry-with-error-feedback loop end to end
- Know when retries fail (info absent from source) vs succeed (format mismatch)
- Add a detected_pattern field for dismissal analysis
DAY 44Message Batches API: 50% cheaper, 24h windowDomain 4
Batch: 50% cost savings, up to 24-hour processing window, NO guaranteed latency. Appropriate for overnight/weekly jobs. INAPPROPRIATE for pre-merge checks. Does NOT support multi-turn tool use in one request.
Objectives
- Submit a batch job with
custom_idfields for correlation - Know how to calculate submission frequency for a given SLA
- Understand how to handle partial failures (resubmit only failed custom_ids)
DAY 45Multi-instance & multi-pass review architecturesDomain 4
Self-review fails: the generator retains reasoning context. Use a separate independent instance to review generated code. For large reviews, per-file passes + a separate cross-file integration pass.
Objectives
- Set up a generate → independent review pipeline
- Know why extended thinking doesn't replace independent review
- Add self-reported confidence alongside findings for calibrated routing
DAY 46Domain 4 review + practiceDomain 4
All Domain 4 practice questions. Focus on the distinction between tool-use + JSON schema (eliminates syntax errors) and semantic validation (catches wrong-field placement, non-summing totals).
Objectives
- Score ≥ 75% on Domain 4 practice
- Internalize: tool_choice "any" guarantees structured output
- Know when to use batch vs synchronous API from workflow latency requirements
▼
Phase 7 · Domain 5: Context Management & Reliability
Days 47–54 · 15%DAY 47Managing long conversations: case facts blocksDomain 5
Progressive summarization loses numerical facts (amounts, dates, order numbers). Extract transactional facts into a persistent "case facts" block included in EVERY prompt, outside the summarized history.
Objectives
- Design a case-facts persistence layer for a customer support agent
- Know why trimming tool results to only relevant fields matters
- Understand how verbose tool outputs disproportionately consume tokens
DAY 48Position-aware input: lost in the middleDomain 5
Models reliably process beginning and end of long inputs, may omit middle. Put key findings summaries at the start. Use explicit section headers to mitigate position effects.
Objectives
- Restructure a long-context prompt to put key findings first
- Know to have subagents include metadata (dates, sources) for accurate downstream synthesis
- Design prompts that survive the lost-in-the-middle effect
DAY 49Scratchpad files, /compact, subagent delegationDomain 5
For hour-long codebase exploration, have the agent maintain scratchpad files referenced across context boundaries. Use
/compact to reduce verbose discovery. Delegate verbose work to subagents; main agent keeps high-level coordination.Objectives
- Use /compact in a long exploration session
- Design structured state exports (manifests) for crash recovery
- Know: spawn subagents for "find all X" work, main agent coordinates
DAY 50Escalation patterns: when to escalateDomain 5
Escalate on: explicit customer request, policy gaps (not just complex cases), inability to make progress. Do NOT escalate on sentiment or self-reported confidence (unreliable). Sample Q3 tests this directly.
Objectives
- Design escalation criteria with few-shot examples demonstrating when to escalate vs resolve
- Know: explicit human request → escalate immediately (no investigation)
- Acknowledge frustration + offer resolution; escalate only if reiterated
DAY 51Confidence calibration and human review workflowsDomain 5
Aggregate accuracy (97% overall) may mask poor performance on specific doc types. Stratified random sampling for error rate measurement. Field-level confidence scores calibrated with labeled validation sets.
Objectives
- Design stratified sampling for ongoing extraction quality measurement
- Know that per-doc-type accuracy must be validated before reducing human review
- Route low-confidence / ambiguous extractions to human reviewers
DAY 52Error propagation in multi-agent systemsDomain 5
Return structured error context to the coordinator: failure type, attempted query, partial results, potential alternatives. Generic "search unavailable" hides everything. Distinguish access failures from valid empty results.
Objectives
- Design structured errors for a multi-agent research system
- Know: subagents recover transient errors locally; propagate only unresolvable ones
- Connect this to Sample Q8
DAY 53Provenance: attribution, conflicts, temporal dataDomain 5
Subagents must output claim-source mappings (URLs, document names, excerpts). Preserve them through synthesis. Handle conflicting credible sources by annotating conflicts — don't arbitrarily pick. Include publication dates.
Objectives
- Design a structured claim-source output format
- Know: financial data as tables, news as prose, technical findings as lists — don't force uniform format
- Explicitly annotate conflicts rather than hiding them
DAY 54Domain 5 review + practiceDomain 5
All Domain 5 practice questions. Re-read Sample Q3 and Q8. Check that all 5 domains are now ≥ 75% on practice.
Objectives
- Score ≥ 75% on Domain 5 practice
- Confirm weak areas across all 5 domains in NOTES.md
- Prioritize what to review in Phase 9
▼
Phase 8 · Scenario Mastery
Days 55–60DAY 55Scenario 1 deep dive: Customer Support Resolution AgentScenarios
Tools:
get_customer, lookup_order, process_refund, escalate_to_human. Target: 80% first-contact resolution. Primary domains: D1, D2, D5. Expect questions on prerequisites, escalation, tool overlap.Objectives
- Re-read Sample Q1 (prerequisites), Q2 (tool descriptions), Q3 (escalation)
- Design the programmatic prerequisite gate for process_refund
- Write the structured handoff JSON for human escalation
Exam guide PDF — Scenario 1 + Sample Q1–Q3
DAY 56Scenario 2 deep dive: Code Generation with Claude CodeScenarios
Custom slash commands, CLAUDE.md, plan mode vs direct execution. Primary domains: D3, D5. Expect questions on where configs live, when to use plan mode, convention scoping.
Objectives
- Re-read Sample Q4 (command location), Q5 (plan mode), Q6 (rules vs CLAUDE.md)
- Build a real project with proper CLAUDE.md hierarchy + .claude/rules + slash commands
- Practice the plan-then-execute combo on a refactor
Exam guide PDF — Scenario 2 + Sample Q4–Q6
DAY 57Scenario 3 deep dive: Multi-Agent Research SystemScenarios
Coordinator + web search + document analysis + synthesis + report. Primary domains: D1, D2, D5. Expect questions on coordinator decomposition, error propagation, verification round-trips.
Objectives
- Re-read Sample Q7 (narrow decomposition), Q8 (error propagation), Q9 (scoped tools)
- Build a 3-subagent research system end to end
- Implement structured claim-source mappings through synthesis
Exam guide PDF — Scenario 3 + Sample Q7–Q9
DAY 58Scenario 4 deep dive: Developer Productivity ToolsScenarios
Built-in tools (Read, Write, Bash, Grep, Glob) + MCP servers. Primary domains: D2, D3, D1. Expect questions on tool selection, MCP integration, codebase exploration strategies.
Objectives
- Practice the Grep-then-Read investigation strategy on a real codebase
- Know when to use Edit vs Read+Write fallback
- Configure a project MCP server for team workflows
Exam guide PDF — Scenario 4
DAY 59Scenario 5 deep dive: Claude Code for CI/CDScenarios
Non-interactive runs, JSON schema output, minimizing false positives, independent review instances. Primary domains: D3, D4. Expect questions on review prompt design, test generation, duplicate comment avoidance.
Objectives
- Set up a working CI check using
claude -p --output-format json --json-schema - Design a review prompt with explicit categorical criteria (not "be conservative")
- Pass prior review findings to avoid duplicate comments on re-runs
Exam guide PDF — Scenario 5
DAY 60Scenario 6 deep dive: Structured Data ExtractionScenarios
JSON schemas, few-shot for varied formats, validation + retry, batch processing. Primary domains: D4, D5. Expect questions on schema design, nullable fields, semantic error detection, batch strategy.
Objectives
- Build a structured extraction tool with calculated_total vs stated_total
- Design a batch strategy for a 30-hour SLA (answer: 4-hour windows)
- Know when to use synchronous API over batch (pre-merge checks)
Exam guide PDF — Scenario 6
▼
Phase 9 · Mock Exams, Practice Loops & Weak-Area Patching
Days 61–70DAY 61Mock exam 1: full practical test, timedPractice
Take the full paullarionov practical_test_en.html in one sitting. Time yourself. Don't look anything up. Note every question you're unsure of — not just the ones you got wrong.
Objectives
- Complete the full test in a single session
- Capture score by domain
- List every question marked "uncertain"
practical_test_en.html — full test, timed
DAY 62Review every wrong + uncertain answerPractice
For each wrong/uncertain question: map it to the specific task statement in the exam guide. Write a one-line rule in NOTES.md. If 3+ wrong in one domain → re-read that domain's task statements.
Objectives
- NOTES.md has a rule for every missed question
- Identify the single weakest domain
- Plan tomorrow's study around the weakest area
Exam guide PDF — task statements for weak domain
DAY 63The 9 recurring answer patternsPractice
Drill the 9 patterns from the sample questions until they're instant. Compliance → hooks. Tool-selection → fix descriptions first. Escalation → explicit criteria. Architecture → plan mode. Cross-dir conventions → .claude/rules. Coverage gaps → coordinator decomposition. Errors → structured context. Round-trips → scoped tool.
Objectives
- Recite all 9 patterns from memory
- Write a one-sentence anti-pattern for each
- Quiz yourself by covering the answer and reading only the question
STUDY_PLAN.md — "Recurring answer patterns" section
DAY 64Build-from-scratch: coordinator + 2 subagents + hookPractice
Using the Agent SDK, build a working coordinator with 2 subagents (e.g., web search + summary) and a PostToolUse hook that normalizes timestamps. No references — do it from memory first, then check.
Objectives
- Working demo without looking up syntax
- Confirm allowedTools includes "Task"
- Hook actually modifies a tool result before the model sees it
DAY 65Build-from-scratch: MCP tool with structured errorsPractice
Write a minimal MCP server with one tool. Return structured errors with
errorCategory, isRetryable, human-readable messages for 3 distinct failure modes (transient / validation / business rule).Objectives
- Working MCP server with isError flag usage
- Trigger each error category deliberately
- Verify an agent can read the structured fields and decide retry vs give up
DAY 66Mock exam 2 + Skilljar practice (if access granted)Practice
Re-take the practical test OR take the Skilljar practice test if you have access. Goal: score higher than Day 61 across every domain.
Objectives
- Score ≥ 80% overall
- No domain below 70%
- Identify any remaining weak areas
practical_test_en.html or Skilljar practice test
DAY 67Weak-area deep divePractice
Spend the full hour on your single weakest domain. Re-read every task statement, the relevant sections of the paullarionov study guide, and the daronyondem narrative guide for that domain.
Objectives
- Weakest-domain confidence raised measurably
- All NOTES.md rules for this domain make sense and stick
- Do one small hands-on exercise in the weak area
DAY 68Daronyondem guide full re-readPractice
Read the entire daronyondem preparation guide in one sitting. It's narrative and captures nuance the task statements compress. Focus on "Common Pitfalls" and "Go Deeper" sections.
Objectives
- Finish all 4 domains of the daronyondem guide
- Add any new pitfalls to NOTES.md
- Spot gaps between this narrative and the official task statements
DAY 69Final mock examPractice
Full timed mock. If ≥ 80% across all domains, you're ready. If not, extend by a few days — don't rush the exam. Book the real exam only after hitting the bar.
Objectives
- Score ≥ 80% overall, ≥ 70% every domain
- Book the real exam for Day 71+
- Final NOTES.md pass before tomorrow
practical_test_en.html — final attempt
DAY 70Light review + rest. Read the exam guide PDF one more time.Practice
Re-read the official exam guide PDF cover to cover. Skim NOTES.md. Review the 9 recurring answer patterns. Do NOT cram new material. Sleep well. Show up.
Objectives
- Official guide PDF fresh in mind
- NOTES.md one-line rules internalized
- Rested and ready — the exam is tomorrow
Exam guide PDF — full re-read