# Exam Rehearsal, Practice Tests & Certification Pitfalls

> Closing certification page synthesizing Domains 3–5 (Claude Code workflows, prompt engineering with JSON schemas, context management and reliability): four hands-on practical exercises with domain mappings, worked example and practice-test question patterns, interactive HTML rehearsal workflow, out-of-scope topic traps, and the final preparation checklist — giving candidates a deliberate finish before sitting the exam.

- Repository: paullarionov/claude-certified-architect
- GitHub: https://github.com/paullarionov/claude-certified-architect
- Human wiki: https://grok-wiki.com/public/wiki/paullarionov-claude-certified-architect-1b20f95d81b9
- Complete Markdown: https://grok-wiki.com/public/wiki/paullarionov-claude-certified-architect-1b20f95d81b9/llms-full.txt

## Source Files

- `guide_en.MD`
- `practical_test_en.html`
- `utils/build_practical_test_html.py`
- `.github/workflows/markdown-to-pdf.yml`
- `.github/workflows/pdf-style.css`
- `pdf/guide_en.pdf`
- `guide_it.md`

---

<details>
<summary>Relevant source files</summary>

The following files were used as context for generating this wiki page:

- [guide_en.MD](guide_en.MD)
- [practical_test_en.html](practical_test_en.html)
- [utils/build_practical_test_html.py](utils/build_practical_test_html.py)
- [.github/workflows/markdown-to-pdf.yml](.github/workflows/markdown-to-pdf.yml)
- [.github/workflows/pdf-style.css](.github/workflows/pdf-style.css)
- [pdf/guide_en.pdf](pdf/guide_en.pdf)
- [guide_it.md](guide_it.md)

</details>

# Exam Rehearsal, Practice Tests & Certification Pitfalls

This page is the **closing certification rehearsal** for Domains 3–5: Claude Code configuration and workflows (20%), prompt engineering and structured output (20%), and context management and reliability (15%). Together these three domains account for **55%** of the exam. The real test draws four scenarios from eight possibilities, uses multiple-choice format with no guessing penalty, and requires a scaled score of **720** to pass — so every unanswered question is a missed opportunity.

Use this page after you have read Part I theory and Part II domain notes in the study guide. It ties together hands-on exercises, worked exam patterns, the interactive HTML practice test, out-of-scope traps, and a final checklist so you finish preparation deliberately rather than by rereading chapters at random.

---

## How Domains 3–5 Connect on the Exam

The exam does not test these domains in isolation. A single scenario often spans all three:

| Domain | Weight | What the exam tests | Typical scenario hook |
|---|---|---|---|
| **3 — Claude Code** | 20% | `CLAUDE.md` hierarchy, skills/commands, path rules, planning mode, CI integration | Code Generation, Claude Code for CI |
| **4 — Prompt engineering** | 20% | Explicit criteria, few-shot, JSON schemas, validation/retry, batch vs sync API | Structured Data Extraction, CI review quality |
| **5 — Context & reliability** | 15% | Context trimming, escalation, error propagation, provenance, human oversight | Multi-agent Research, Customer Support |

```text
  Scenario prompt
        │
        ├─► Domain 3: WHERE does config live? (project vs user, rules vs skills)
        ├─► Domain 4: HOW do you shape output? (few-shot, schema, retry loop)
        └─► Domain 5: WHAT happens when context fails? (escalate, propagate, preserve attribution)
```

Sources: [guide_en.MD:42-48](), [guide_en.MD:1678-1935]()

---

## Domain 3 Rehearsal: Claude Code Configuration & Workflows

### Decision framework

When a question mentions team-shared configuration, slash commands, or CI pipelines, walk through this sequence:

1. **Scope** — Is the setting for one developer or the whole team?
2. **Load behavior** — Always loaded (`CLAUDE.md`) or on-demand (Skills)?
3. **File targeting** — Cross-cutting globs (`.claude/rules/`) or directory-local `CLAUDE.md`?
4. **Execution mode** — Planning (explore first) or direct execution (clear, small change)?
5. **CI mode** — Non-interactive (`-p` / `--print`) with optional `--output-format json` + `--json-schema`?

### CLAUDE.md hierarchy — the #1 team pitfall

Three levels exist: user (`~/.claude/CLAUDE.md`), project (`.claude/CLAUDE.md` or root `CLAUDE.md`), and directory-level. User-level settings are **not** shared via version control. The classic exam trap: original developers put guidance in their personal config; a new hire sees different behavior despite working in the same repo.

**Fix:** Move team-wide standards to project-level `CLAUDE.md`.

Sources: [guide_en.MD:551-571](), [guide_en.MD:1680-1691](), [guide_en.MD:2680-2689]()

### Skills vs rules vs CLAUDE.md

| Mechanism | Loads when | Best for | Exam trap |
|---|---|---|---|
| **Project `CLAUDE.md`** | Every session | Universal coding/testing standards | Putting 400+ lines of workflow-specific guidance here |
| **`.claude/rules/` + `paths`** | Editing matching files | Cross-directory conventions (`**/*.test.tsx`) | Using directory `CLAUDE.md` when tests are scattered |
| **Skills (`SKILL.md`)** | On demand / trigger keywords | PR review, migrations, deep analysis | Verbose skill output polluting main session |
| **`.claude/commands/`** | Slash invocation | Team-shared `/review` command | Putting commands in `~/.claude/commands/` when team needs them |

**Skill frontmatter triad** (appears repeatedly on practice tests):

- `context: fork` — isolate verbose output in a subagent
- `allowed-tools` — restrict destructive operations
- `argument-hint` — reduce missing-argument failures

Sources: [guide_en.MD:665-690](), [guide_en.MD:1693-1705](), [guide_en.MD:2618-2629](), [guide_en.MD:2708-2719]()

### Planning mode vs direct execution

| Signal in the stem | Choose |
|---|---|
| Monolith → microservices, dozens of files, ambiguous integration options | **Planning mode** |
| Single-file fix, clear stack trace, one validation | **Direct execution** |
| "Add Slack support" with webhooks vs bot tokens vs Slack Apps | **Planning mode** (multiple valid architectures) |

Reactive switching ("start direct, plan when stuck") is consistently marked wrong. Plan first when architectural consequences are large.

Sources: [guide_en.MD:695-718](), [guide_en.MD:1719-1731](), [guide_en.MD:2000-2011](), [guide_en.MD:2602-2614]()

### CI/CD integration checklist

| Requirement | Correct approach | Wrong distractor |
|---|---|---|
| Pipeline hangs waiting for input | `claude -p "..."` | `CLAUDE_HEADLESS=true` (non-existent) |
| Inline PR comments need structured fields | `--output-format json` + `--json-schema` | Narrative format + manual parsing |
| Blocking pre-merge check | Synchronous API | Message Batches API (up to 24h, no SLA) |
| Overnight tech-debt report | Message Batches API (50% savings) | Same synchronous call as pre-merge |
| Self-review misses subtle bugs | Second **independent** review instance | Self-critique in same session |

**Session isolation pitfall:** The same session that generated code is less effective at reviewing it. Fresh-instance review mirrors human peer review.

Sources: [guide_en.MD:1747-1760](), [guide_en.MD:2075-2101](), [guide_en.MD:2359-2386]()

---

## Domain 4 Rehearsal: Prompt Engineering & Structured Output

### Syntax vs semantic errors

JSON schemas via `tool_use` eliminate **syntax** errors (malformed JSON, wrong types). They do **not** eliminate **semantic** errors (totals that don't reconcile, values in wrong fields, fabricated required fields).

| Error class | Example | Primary mitigation |
|---|---|---|
| Syntax | Trailing comma, missing brace | `tool_use` + JSON Schema |
| Semantic | `stated_total` ≠ sum of line items | Validation loop + retry with specific error feedback |

Sources: [guide_en.MD:252-302](), [guide_en.MD:1793-1819]()

### `tool_choice` decision table

| Setting | Behavior | When to use |
|---|---|---|
| `"auto"` | Model may return text or call a tool | General chat |
| `"any"` | Must call a tool (picks among defined tools) | Guaranteed structured output when multiple schemas exist |
| `{"type":"tool","name":"..."}` | Forces a specific tool | Pipelines requiring a fixed first step |

Sources: [guide_en.MD:238-250](), [guide_en.MD:1793-1805]()

### Schema design rules (exam favorites)

1. Mark fields **required** only when always present — otherwise the model fabricates values.
2. Use **nullable** types (`"type": ["string", "null"]`) when source may lack data.
3. Add enum values `"unclear"` and `"other"` plus a detail string for extensibility.
4. Pair strict schema with **normalization rules** in the prompt for messy real-world inputs.

### Few-shot beats vague instructions

When stems say "developers find feedback inconsistent" or "output structure still doesn't match after prose descriptions," the correct answer is usually **2–4 concrete input/output examples** showing location, issue, severity, and fix — not more abstract wording.

For CI false-positive crises: **temporarily disable** noisy categories (style, naming, documentation) while keeping high-precision categories (security, correctness). Uniform strictness reduction or pre-filtering findings before developers see them are common wrong answers when stakeholders rejected filtering.

Sources: [guide_en.MD:1766-1790](), [guide_en.MD:2419-2430](), [guide_en.MD:2541-2565](), [guide_en.MD:2588-2599]()

### Batch processing — match latency to workflow

```text
  Blocking pre-merge check ──► Synchronous API (developer waiting)
  Overnight audit/report   ──► Message Batches API (50% cost, ≤24h window)
  Multi-turn tool loop     ──► NOT batch-compatible (no mid-request tool execution)
```

Sources: [guide_en.MD:1821-1833](), [guide_en.MD:2389-2415]()

---

## Domain 5 Rehearsal: Context Management & Reliability

### Context preservation patterns

| Problem | Symptom | Correct mitigation |
|---|---|---|
| Progressive summarization | Numbers/dates become "about", "roughly" | Persistent "case facts" block outside summarized history |
| Lost-in-the-middle | Middle findings ignored in long inputs | Key findings at start/end with explicit headings |
| Verbose tool output | 40 fields returned, 5 needed | Trim to relevant fields before next turn |
| Long codebase session | Model cites "typical patterns" not actual classes | Subagents, scratchpad files, `/compact` |

Sources: [guide_en.MD:179-194](), [guide_en.MD:1851-1905]()

### Escalation calibration

**Escalate immediately when:**
- Customer explicitly requests a human
- Policy is silent or ambiguous for the specific request (e.g., competitor price matching)

**Do not escalate on:**
- First expression of dissatisfaction (unless they ask for a manager)
- Model self-rated confidence scores (unreliable)
- Sentiment analysis thresholds

**Deterministic guarantees beat prompts** when business logic requires tool sequencing (e.g., block `process_refund` until `get_customer` returns a verified ID).

Sources: [guide_en.MD:1865-1877](), [guide_en.MD:1940-1981](), [guide_en.MD:2878-2905]()

### Multi-agent error propagation

When a subagent times out, return **structured error context**: failure type, query attempted, partial results, alternatives. Wrong patterns:

- Generic "search unavailable" (hides recovery options)
- Empty success result (masks failure)
- Abort entire workflow on single subagent failure

For **conflicting sources**, preserve both values with attribution and pass reconciliation to the coordinator — do not pick one heuristically or hide the conflict.

Sources: [guide_en.MD:1879-1934](), [guide_en.MD:2045-2056](), [guide_en.MD:2130-2141]()

### Human oversight and provenance

- Aggregate accuracy (97%) can mask poor performance on specific document types — stratify sampling by type and field.
- Require subagents to output **claim → source** mappings (URL, quote, publication date).
- Separate confirmed findings from disputed ones in synthesis reports.

Sources: [guide_en.MD:1907-1934]()

---

## Four Hands-On Practical Exercises (Domain-Mapped)

The study guide ships four exercises designed to rehearse exam patterns hands-on. Two map primarily to Domains 3–5; two reinforce cross-domain skills you will still see in Domains 3–5 scenarios.

### Exercise 1: Multi-tool Agent with Escalation Logic

**Domains:** 1, 2, **5**

| Step | Action | Exam skill tested |
|---|---|---|
| 1 | Define 3–4 MCP tools with differentiated descriptions | Tool selection (Domain 2, appears in Domain 5 scenarios) |
| 2 | Agent loop on `stop_reason` (`tool_use` / `end_turn`) | Agent architecture fundamentals |
| 3 | Structured errors: `errorCategory`, `isRetryable` | Error propagation (Domain 5.3) |
| 4 | Interceptor hook blocking high-threshold operations → escalation | Deterministic policy enforcement |
| 5 | Test multi-aspect requests | Escalation calibration |

Sources: [guide_en.MD:3285-3296]()

### Exercise 2: Configuring Claude Code for Team Development

**Domains:** **3**, 2

| Step | Action | Exam skill tested |
|---|---|---|
| 1 | Project-level `CLAUDE.md` with universal standards | Hierarchy scope (3.1) |
| 2 | `.claude/rules/` with `paths: ["src/api/**/*"]`, `paths: ["**/*.test.*"]` | Path-specific loading (3.3) |
| 3 | Skill with `context: fork` + `allowed-tools` | Skill isolation (3.2) |
| 4 | MCP in `.mcp.json` + personal override in `~/.claude.json` | MCP config layering |
| 5 | Compare planning mode vs direct execution | Execution mode (3.4) |

Sources: [guide_en.MD:3300-3311]()

### Exercise 3: Structured Data Extraction Pipeline

**Domains:** **4**, **5**

| Step | Action | Exam skill tested |
|---|---|---|
| 1 | Extraction tool with JSON schema (required/optional, enums, nullable) | Schema design (4.3) |
| 2 | Validation/retry loop with specific error feedback | Semantic error handling (4.4) |
| 3 | Few-shot examples for varied document structures | Few-shot prompting (4.2) |
| 4 | Message Batches API: 100 docs, retry failures via `custom_id` | Batch strategy (4.5) |
| 5 | Field-level confidence + document-type routing to humans | Human oversight (5.5) |

Sources: [guide_en.MD:3315-3326]()

### Exercise 4: Multi-agent Research Pipeline

**Domains:** 1, 2, **5**

| Step | Action | Exam skill tested |
|---|---|---|
| 1 | Coordinator + subagents with explicit context in prompts | Context passing |
| 2 | Parallel `Task` calls in single response | Orchestration efficiency |
| 3 | Structured output: claim, quote, source URL, date | Provenance (5.6) |
| 4 | Simulate timeout → structured error to coordinator | Error propagation (5.3) |
| 5 | Conflicting data: preserve both with attribution | Reconciliation pattern |

Sources: [guide_en.MD:3330-3341]()

---

## Worked Example: End-to-End Scenario Walkthrough

**Exam-style stem (Domain 3 + 4 + 5):** Your CI pipeline runs `claude -p` with `CLAUDE.md` for PR review. Reviews are substantive but narrative. You need automatic inline GitHub comments with `file`, `line`, `severity`, and `suggested_fix`. After enabling structured output, developers still spend too long triaging a 40% false-positive rate across categories, and the same Claude session that generated a fix missed a regression another reviewer caught.

### Step-by-step reasoning

| Step | Question to ask yourself | Answer |
|---|---|---|
| 1 | Non-interactive CI? | Already using `-p` — correct |
| 2 | Need guaranteed JSON fields? | `--output-format json` + `--json-schema`, not CLAUDE.md prose templates |
| 3 | False positives eroding trust? | Temporarily disable noisy categories; keep security/correctness |
| 4 | Investigation time too high? | Include rationale + confidence **in each finding** (not pre-filter) |
| 5 | Generator missed its own bug? | Second independent review instance without generation context |
| 6 | Multi-file PR inconsistent depth? | Per-file passes + separate cross-file integration pass |

This single narrative chains Domains 3 (CI flags, `CLAUDE.md` context), 4 (schema, few-shot, category tuning), and 5 (session isolation, multi-pass review architecture).

Sources: [guide_en.MD:2359-2370](), [guide_en.MD:2374-2386](), [guide_en.MD:2541-2565](), [guide_en.MD:2105-2116](), [guide_en.MD:1836-1845]()

---

## Practice Test Question Patterns

The guide includes **60 questions across 4 scenarios** matching real exam format and difficulty. An interactive HTML version is generated for multiple languages.

### Scenario coverage in the practice test

| Scenario | Question range | Primary domains |
|---|---|---|
| Multi-agent Research System | Q1–Q15 | 5 (provenance, error propagation, synthesis) |
| Claude Code for Continuous Integration | Q16–Q30 | 3 + 4 (CI, few-shot, batch, structured output) |
| Code Generation with Claude Code | Q31–Q45 | 3 (hierarchy, skills, planning, rules) |
| Customer Support Agent | Q46–Q60 | 5 (escalation, tool sequencing, multi-issue handling) |

Sources: [guide_en.MD:2120-2124](), [guide_en.MD:2126](), [guide_en.MD:2355](), [guide_en.MD:2584](), [guide_en.MD:2813]()

### Recurring answer patterns (memorize the logic, not letter positions)

| Pattern | Correct principle | Typical wrong distractor |
|---|---|---|
| Team-shared `/review` command | `.claude/commands/` in repo (VCS) | `~/.claude/commands/` |
| Scattered test conventions | `.claude/rules/` with `**/*.test.*` globs | Root `CLAUDE.md` with headings |
| 400-line `CLAUDE.md` mixing workflows | Universal standards in `CLAUDE.md`; workflow guidance in Skills | Move everything to Skills (loses always-on standards) |
| Ambiguous API transformation | 2–3 concrete input/output examples | JSON schema validation alone on prose requirements |
| Conflicting research statistics | Both values + attribution → coordinator reconciles | Pick one via credibility heuristic |
| Subagent timeout | Structured error context to coordinator | Empty success or abort workflow |
| Mandatory tool sequence | Programmatic precondition / hook | Stronger system prompt only |
| Escalation miscalibration | Explicit criteria + few-shot examples | Self-rated confidence threshold |
| Blocking vs batch API | Sync for pre-merge; batch for overnight | Move both to batch for 50% savings |

Sources: [guide_en.MD:1938-2116](), [guide_en.MD:2588-2734]()

### How to study each practice question

1. Read the **situation** — identify which domain signal words appear (`CLAUDE.md`, `CI`, `schema`, `escalate`, `coordinator`, `batch`).
2. Predict the answer **before** reading options.
3. Read **Why X** explanation — it states the trade-off principle the exam rewards.
4. Tag the question with domain numbers (3, 4, or 5) for gap analysis.
5. Revisit wrong tags after the HTML summary groups misses by scenario.

---

## Interactive HTML Rehearsal Workflow

The repository ships self-contained practice test pages (`practical_test_en.html`, plus `ru`, `ja`, `zh`, `it`, `ko`) built from guide questions.

### Build pipeline

```text
  guide_<lang>.md (Practice Test section)
           │
           ▼
  extract_question.py <lang> all   ──► JSON question array
           │
           ▼
  utils/build_practical_test_html.py ──► practical_test_<lang>.html
```

The builder embeds questions as `const QUESTIONS = [...]`, applies exam-like styling, and ships a sidebar navigation UI.

Sources: [utils/build_practical_test_html.py:1-24](), [utils/build_practical_test_html.py:423-475]()

### Runtime behavior (what to expect when rehearsing)

| UI element | Behavior |
|---|---|
| Sidebar | Groups questions by scenario; tracks answered count |
| Question card | Scenario badge, situation, prompt, four options |
| Answer lock | First click locks choice; shows correct/wrong styling |
| Explanation | Reveals "Why {letter}" rationale immediately after answering |
| Finish & Review | Score summary (total/correct/incorrect) + wrong answers grouped by scenario |
| Restart | Clears answers for a full retake |

```text
  ┌─────────────┐     select option      ┌──────────────────┐
  │  Sidebar    │ ─────────────────────► │  Locked answer   │
  │  (scenario  │                        │  + explanation   │
  │   groups)   │ ◄── navigate Prev/Next └────────┬─────────┘
  └─────────────┘                                   │
                                                    ▼
                                          ┌──────────────────┐
                                          │ Finish & Review  │
                                          │ (score by scenario)│
                                          └──────────────────┘
```

Sources: [utils/build_practical_test_html.py:235-420](), [practical_test_en.html:223-242]()

### Offline study paths

- **Browser:** Open `practical_test_en.html` locally (no server required — questions are embedded).
- **Print/PDF:** The guide PDF is auto-built from markdown on push to `main` via `md-to-pdf` with shared stylesheet; use `pdf/guide_en.pdf` for offline reading of the same question rationales.

Sources: [.github/workflows/markdown-to-pdf.yml:35-46](), [README.md:30-41]()

### Rehearsal schedule (recommended)

| Day | Activity | Target |
|---|---|---|
| 1 | Domains 3–5 notes + Exercise 2 | Configure a real repo's `CLAUDE.md` / rules / skills |
| 2 | Exercise 3 + Domain 4 schema drills | Build one extraction tool + retry loop |
| 3 | HTML practice test, scenarios 1–2 (Q1–30) | ≥80% with explanations read for misses |
| 4 | HTML practice test, scenarios 3–4 (Q31–60) | ≥80%; list recurring miss patterns |
| 5 | Exercise 4 + timed full 60-question retake | Simulate exam pacing; answer every question |

---

## Out-of-Scope Topic Traps

The guide explicitly lists topics **not** on the exam. These appear as plausible-sounding distractors:

| Trap topic | Why it sounds right | Why it's wrong |
|---|---|---|
| Fine-tuning / custom model training | "Improve accuracy" | Exam focuses on prompting, tools, and architecture — not training |
| Claude internal architecture / RLHF | "Understand the model" | Not tested |
| Deploying/hosting MCP servers (K8s, networking) | Scenario mentions MCP | Exam covers tool design and integration, not infra |
| OAuth / API key rotation details | Security scenarios | Authentication protocols are out of scope |
| Cloud-specific configs (AWS/GCP/Azure) | Enterprise scenarios | Provider-neutral Claude patterns only |
| Streaming API / SSE | Real-time systems | Out of scope |
| Token counting algorithms | Context management domain | Know context limits; not tokenization internals |
| Computer use / Vision | Agent capabilities | Not on this certification |
| Embedding models / vector DB implementation | RAG patterns | Out of scope |

**Exam tactic:** If an answer requires infrastructure you would configure in a cloud console rather than in `CLAUDE.md`, a prompt, or an agent loop — it is likely a trap.

Sources: [guide_en.MD:3366-3385]()

---

## Certification Pitfalls: Quick-Reference

### Domain 3 pitfalls

- Putting team standards in `~/.claude/CLAUDE.md`
- Using `@import` (not a real syntax — correct is `@path`)
- Choosing direct execution for architectural migrations
- Using batch API for blocking CI checks
- Expecting narrative CI output to parse reliably without `--json-schema`

### Domain 4 pitfalls

- Assuming JSON schema fixes semantic correctness
- Making all fields required (forces fabrication)
- "Be more conservative" instead of explicit categorical criteria
- Moving iterative tool-calling workflows to Message Batches API
- Self-review in the same session that generated the code

### Domain 5 pitfalls

- Escalating on sentiment or low self-rated confidence
- Picking one conflicting source without attribution
- Returning generic error strings from failed subagents
- Relying on progressive summarization for numeric facts
- Filtering findings before developers see them when stakeholders rejected filtering

---

## Final Preparation Checklist

Complete every item before scheduling the exam:

### Knowledge verification

- [ ] Explain the three-level `CLAUDE.md` hierarchy and when each level applies
- [ ] Describe when to use `.claude/rules/` globs vs Skills vs always-on `CLAUDE.md`
- [ ] State when planning mode beats direct execution (and vice versa)
- [ ] Configure CI non-interactive mode (`-p`) and structured output flags
- [ ] Design a JSON schema with nullable fields, enums, and `"other"` + detail
- [ ] Explain syntax vs semantic errors and when retry-with-feedback helps
- [ ] Match workflows to sync API vs Message Batches API by latency requirement
- [ ] List escalation triggers: explicit human request, policy gaps, inability to progress
- [ ] Describe structured subagent error propagation and provenance preservation

### Hands-on verification

- [ ] Complete Exercise 2 (Claude Code team config)
- [ ] Complete Exercise 3 (extraction pipeline with validation loop)
- [ ] Run the HTML practice test to completion with score review
- [ ] Score ≥80% on practice test; for misses, read the "Why" explanation and tag the domain

### Exam-day tactics

- [ ] Remember: **no guessing penalty** — answer every question
- [ ] Passing score is **720** on a 100–1000 scale
- [ ] Expect **4 of 8 scenarios** — Domains 3–5 surface across Code Generation, CI, Research, Support, and Structured Extraction scenarios
- [ ] For each question: identify the **root cause** the stem describes, then pick the fix with the most **deterministic** or **proportional** impact
- [ ] Eliminate out-of-scope distractors (fine-tuning, cloud infra, streaming, tokenization)

Sources: [guide_en.MD:31-36](), [guide_en.MD:3389-3405]()

---

## Summary

Domains 3–5 reward architects who configure Claude Code deliberately (`CLAUDE.md` hierarchy, path rules, skills with `context: fork`, planning mode for architectural work, CI structured output), shape prompts with explicit criteria and schemas while separating syntax from semantic validation, and manage context with escalation discipline, structured error propagation, and provenance through multi-agent pipelines. The four practical exercises and 60-question HTML practice test in this repository are your highest-fidelity rehearsal tools: work the exercises for muscle memory, run the HTML test for pacing and gap analysis, and use the out-of-scope list to avoid elegant but irrelevant distractors. Finish with the checklist above — if you can explain every "Why" explanation for your missed practice questions, you are ready to sit the exam.