CCA-F Cheat Sheet

The corrected hierarchy

The three concrete examples

Three questions you should be able to answer after this section

CLAUDE.md hierarchy (4 levels + local override)

Permissions precedence

• Deny ALWAYS wins. Across all scopes. Pattern specificity does NOT override deny.
• Otherwise, more-specific scope wins (project > user > defaults).
• Subagent tools = INTERSECTION of (subagent's declared tools) ∩ (parent's permissions). Subagents narrow further — never expand.
• Headless mode (-p): anything that would normally prompt the user is treated as denied. Pre-allow everything CI needs.
• Fail-closed default for hooks: if a hook crashes, treat as block.

CI/CD permissioning by trust level

MCP server scoping

Additional Claude Code mechanisms (from official exam guide)

• /memory command — verify which CLAUDE.md / rules files are loaded into the session. Use to diagnose inconsistent behavior across machines (e.g., "user A's instructions aren't being applied" → check whether they're in ~/.claude/CLAUDE.md only, not in the project repo).
• --resume <session-name> — named session resumption. Continue a specific prior investigation by name. Choose resume when prior context is mostly valid; choose new session with injected summary when prior tool results are stale (e.g., files changed since last analysis).
• Explore subagent — named primitive for isolating verbose discovery output. Use when codebase is unfamiliar and you need to map structure before changes. Returns summaries to the main agent, preserving context budget. Different from plan mode: Explore is for unknown-codebase navigation; plan mode is for ambiguous-approach design.
• @import syntax in CLAUDE.md — pull in topic-specific standards files (e.g., @.claude/rules/api-conventions.md) so the root CLAUDE.md stays small. Each package can selectively import only the standards relevant to it.

3 capability types — memorize "who decides invocation"

Transports

• stdio — local subprocess (most common for personal/local servers)
• HTTP / SSE — remote / multi-user
• Streamable HTTP — newer variant of HTTP/SSE
• MCP is NOT HTTP-only. Transport-flexible. Encryption depends on the transport (not guaranteed by MCP itself).

Auth patterns

Tool design — 5 rules for descriptions

1. Clear, descriptive name (action-verb_noun pattern)
2. Disambiguating description when multiple similar tools exist
3. Specify when NOT to use the tool
4. Document each parameter individually
5. Mark required fields explicitly + use enum, pattern, min/max for constraints

Tool boundaries

Tool result conventions

• isError: false + results: [] for a query that ran successfully and found nothing.
• isError: true ONLY for genuine system failure (timeout, auth, syntax error, permission denied).
• Mislabeling empty-result as isError: true → agent hallucinates "the system is down."
• Structured error metadata: { errorCategory, isRetryable, retries_attempted, description } — gives the agent enough signal to recover correctly.

Tool-use loop message ordering (the strict contract)

Agent SDK primitives (from official exam guide)

• Task tool — THE mechanism for spawning subagents in the Claude Agent SDK. A coordinator must have allowedTools: ["Task"] in its config or it cannot spawn anything. Spawning parallel subagents = emit multiple Task tool calls in one coordinator response (not across separate turns).
• AgentDefinition — configures each subagent type with: description, system prompt, tool restrictions, optional model override. Each subagent receives its findings directly in its prompt — subagents do NOT inherit the coordinator's conversation history.
• tool_choice options:
  • "auto" — model may return text instead of calling a tool
  • "any" — model must call a tool but can choose which (use when multiple extraction schemas exist and document type is unknown)
  • {"type":"tool","name":"..."} — force a specific tool first (e.g., extract_metadata before enrichment steps)
• PostToolUse hook for data normalization — specific high-yield use case: when different MCP tools return Unix timestamps vs ISO 8601 vs numeric status codes, a PostToolUse hook normalizes them before the agent processes results. Distinct from tool-call interception hooks (which block policy-violating outgoing calls).
• MCP resources for content catalogs — expose database schemas, issue summaries, documentation hierarchies as resources (host-attached passive context) to reduce exploratory tool calls. The agent gets visibility into available data without having to query for it.

Decision: synchronous vs batch

custom_id — the request-response correlation key

• Each batch request includes a custom_id; the response uses the same ID. This is how you correlate which output goes with which input — order is NOT guaranteed.
• Partial-failure recovery: filter the response by result.type == "errored", extract the failed custom_ids, resubmit ONLY those (possibly with modifications like document chunking).
• SLA calculation: if business SLA is 30 hours, batch needs ≤24h to process, so you have a 4-hour submission window for new batches.

CI hygiene patterns (from Scenario 5)

• Provide prior review findings in context when re-running on new commits — instruct Claude to report only new or still-unaddressed issues, avoiding duplicate PR comments.
• Provide existing test files in context so test generation avoids suggesting duplicate scenarios.
• CLAUDE.md as CI project context — document testing standards, fixture conventions, and review criteria so CI-invoked Claude has the same context as humans.
• Independent review instance for generated code — same session that generated retains reasoning bias; a second instance without that context catches more subtle issues.

"Lost in the middle" — attention pattern

• LLMs weight content at start and end of context more than the middle.
• Place critical instructions in system message or near the end of the user message.
• For long aggregated inputs (many sub-agent outputs), front-load summaries; use explicit section headers to help navigation.
• Don't assume "it's in context, the model will use it."

Context-bloat sources, in order of typical magnitude

1. Tool results — unbounded; trim at source.
2. Conversation history — re-billed cumulatively each turn (quadratic).
3. Tool definitions — constant overhead per turn.

Memorize

• 5 canonical workflow patterns + full agent + multi-agent variants (see Section 1 table).
• Decision ladder: prompt → workflow → agent (climb only as needed).
• 5 required stop conditions for every loop (Section 2).
• Multi-agent justification: need at least 1 of — context isolation, genuine parallelism, specialized toolsets. ~15× tokens of single-agent.
• Anti-pattern words in stems: collaborate / negotiate / debate / discuss / collectively decide → peer-to-peer.
• Pattern composition: PRIMARY = OUTERMOST coordination logic.
• Decomposition vs Orchestration: Decomposition = WHAT pieces. Orchestration = HOW they run.
• Task tool context passing: no shared memory between agents. Coordinator must inject context explicitly into Task tool prompts. No shared_context parameter exists.
• Subagent permissions: INTERSECTION of (declared tools) ∩ (parent's permissions). Can never expand.
• Per-agent-type temperature: extraction / classification → low (0.0–0.3). Synthesis / strategy → higher (0.6–0.9). Fragmented synthesis = often a temperature fix, not a decomposition fix.
• Failure-location diagnostic: per-task outputs good but fragmented synthesis → SYNTHESIS failure (not decomposition).
• Robust error propagation: retry locally with exponential backoff → propagate structured error (with errorCategory + isRetryable + suggestion) only after exhaustion. Coordinator never blind-retries when subagent already did.
• Silent failure anti-pattern: subagent must NEVER return {status: success, results: []} on a real failure. Always return typed error.
• Provenance: subagents must include claim + source_url + document_name + relevant_excerpt as structured output. Synthesis can't reconstruct provenance after the fact.
• Agentic loop control flow: continue iterating while stop_reason == "tool_use", terminate when stop_reason == "end_turn". NEVER parse natural-language phrases ("I have completed the task") for termination — that's a tell-tale anti-pattern.
• Tool result message structure: the assistant's tool_use block stays in conversation history. The tool result goes in a NEW user-role message containing a tool_result content block that references the tool_use_id. Send the FULL history on the next call.
• Task tool for subagent spawning — coordinator's allowedTools must include "Task". Spawn parallel subagents by emitting multiple Task calls in ONE coordinator response.
• Hooks for compliance enforcement: use PostToolUse hooks for data normalization (timestamp formats, status codes). Use tool-call interception hooks to block policy-violating actions (e.g., refunds > $500) and redirect to escalation. Hooks for compliance ≫ prompt-based "be careful" guidance.
• Programmatic prerequisite gates — block process_refund until get_customer has returned a verified customer ID. This is the canonical "code-level enforcement beats prompt-based ordering" example from the official sample exam (Q1).
• Mandatory human override: explicit user request to talk to a human is an unconditional exit from the automated flow, regardless of capability or sentiment.

Memorize

• Tool components: name · description · input schema (JSON Schema) · implementation.
• 5 rules for descriptions (Section 5). Most-tested: specify when NOT to use; explicit superiority statement when alternatives exist.
• Schema reliability primitives: type · enum · required · pattern · minimum / maximum.
• Read vs Write tools: reads are generally safe / auto-approvable; writes need permissions, idempotency, often HITL.
• Tool boundaries: ≤10 safe · 10–25 workable · 25–50+ refactor · 100+ wrong.
• 5 strategies to reduce surface area: consolidate · subagents with focused tool sets · hierarchical routing tools · dynamic loading per phase · description curation.
• Tool naming hygiene: cross-server collisions → namespacing (slack__search, notion__search).
• 3 MCP roles: Host (Claude Desktop / Code) · Client (component inside host) · Server (separate process).
• 3 MCP capability types + who decides (Section 5).
• Transports: stdio (local) · HTTP/SSE (remote) · Streamable HTTP. MCP is transport-flexible — encryption depends on transport.
nnect time.
• Tool result semantics:
  • Empty success → isError: false + results: [].
  • Genuine error → isError: true + structured metadata (errorCategory, isRetryable, retries_attempted, description).
  • Permission error → errorCategory: "permission" + isRetryable: false + escalation path in userMessage. Never "transient" or "validation".
  • Business-rule violation → errorCategory: "business" with customer-friendly userMessage for the agent to relay.
• Tool-use loop ordering (Section 5). Tool result MUST follow immediately in the next user-role message; tool_use_id linkage is what lets Claude map result → action.
• Transient failure handling: exponential backoff inside the tool wrapper; agent sees only the final outcome. Don't propagate transient errors that the tool itself can recover from.
• Tool-result trimming: middleware should strip agent-irrelevant fields (raw DB timestamps, internal IDs, warehouse codes) before injecting tool results into context. Don't widen the context window; trim at the source.
• Built-in tool selection (Claude Code): Grep for content search · Glob for filename pattern matching · Read/Write for full file ops · Edit for targeted edits via unique text match. When Edit fails (non-unique anchor), fall back to Read+Write.
• Tool count limits: 18+ tools per agent degrades selection reliability. Distribute across specialized subagents with 4-5 tools each. Provide scoped cross-role tools (e.g., verify_fact) for high-frequency needs while routing complex cases through the coordinator.
• Replace generic with constrained: swap fetch_url for load_document (validates document URLs only). Splits analyze_document into extract_data_points + summarize_content + verify_claim_against_source.
• MCP resources vs tools — when to choose which: resources are for passive content catalogs the agent reads (schemas, issue summaries, doc hierarchies). Tools are for active actions the agent invokes (queries, side-effecting writes).
• Choose community MCP servers over custom for standard integrations (Jira, GitHub). Reserve custom servers for team-specific workflows.
• "Use this tool instead of X" superiority statement in the description is the highest-leverage fix when Claude ignores your tool in favor of writing custom scripts.

Memorize

• 4 mechanism types: CLAUDE.md (soft) · Slash command (user-invoked) · Subagent (LLM judgment) · Hook (deterministic shell).
• CLAUDE.md is SOFT. For hard guarantees, use hooks or permissions deny.
• CLAUDE.md hierarchy: 4 levels + CLAUDE.local.md (gitignored). Subdirectory CLAUDE.md loads when files in that subdir are read, not at session start.
• Merging: all applicable files merged together. Conflict precedence: subdirectory > project > user > enterprise (enterprise often authoritative for security).
• Imports: @path/to/file syntax. Reorganizes but doesn't reduce context.
• Path-scoped rules: .claude/rules/<name>.md with paths: YAML frontmatter. Native context-bloat reduction.
• SKILL.md frontmatter: allowed-tools: = config-layer security boundary. Cannot be overridden by user prompt.
• Slash commands: .claude/commands/<name>.md (project) or ~/.claude/commands/<name>.md (user). Project-level wins on name collision.
• Permission precedence: DENY ALWAYS WINS across all scopes. Specificity does not override.
• Subagent tools = INTERSECTION, never expand.
• Headless mode (-p): non-interactive. Anything that would prompt = denied. Pre-allow everything CI needs.
• Fail-closed hooks: crash → treat as block.
• CI by trust level: untrusted = read-only allow; trusted = workflow-needed allow + deny destructive.
• Hook events: PreToolUse · PostToolUse · UserPromptSubmit · Stop · SessionStart · Notification.
• Workflow mode selection in Claude Code: Direct execution (fix known, scope clear) · Plan mode (requirements ambiguous) · Explore subagent (codebase unfamiliar). Match mode to task certainty.
• MCP scoping: .mcp.json (team-shared, committed) vs ~/.claude.json (personal). Secrets via ${ENV_VAR} expansion; never commit plaintext.
• Custom skills vs CLAUDE.md: "Always-on" universal rules → CLAUDE.md. "Opt-in, occasional, specialized workflow" → .claude/skills/<name>/SKILL.md (invoked explicitly).
• /memory command — verifies which memory files are loaded. Use to diagnose "instructions not being applied" issues (likely cause: instructions are in user-scoped ~/.claude/CLAUDE.md not project-scoped).
• Named session resumption: --resume <session-name> — continue a specific investigation. Choose resume when prior context is mostly valid; start fresh with injected summary when prior tool results are stale.
• Explore subagent — isolates verbose codebase-discovery output. Returns summaries to main agent. Use during multi-phase exploration to preserve context budget.
• Skill frontmatter options: context: fork runs the skill in isolated sub-agent context (output doesn't pollute main session) · allowed-tools: restricts tool access during skill execution · argument-hint prompts developers for required params.
• Plan mode vs direct execution vs Explore subagent: Plan mode = ambiguous-approach design (multi-file migrations, architectural decisions). Direct execution = clear-scope single-file changes. Explore = unfamiliar codebase navigation.
• /compact: mid-session context cleanup — summarize-and-condense; retain findings, discard noise.
• fork_session: branch the session for divergent exploration.

Memorize

• Reliability hierarchy (climb in order): better prompt → few-shot → tool use / prefill → validation + bounded retry → evaluator-optimizer.
• 4 levers of a good prompt: clarity · role · structure (XML / markdown) · output specification.
• System vs user message: role + persistent behavior + format rules in system. Per-turn input in user.
• XML tags are the Anthropic-recommended structural delimiter. Claude is trained to weight tagged sections.
• Positive > negative instructions. "Keep responses under 100 words" beats "don't be verbose." Prohibitions still anchor the prohibited concept.
• Few-shot: 3–5 sweet spot. > 10 → consider fine-tuning. Principles: diverse · representative · cover edge cases. Format consistency across all examples. Recency bias: the last example has stronger format influence.
• 4 ways to get structured output (most → least reliable):
  1. Tool use / function calling with JSON schema (API enforces).
  2. Prefilling the assistant turn (e.g., Assistant: {).
  3. JSON schema in instructions (relies on adherence).
  4. Free-text "respond as JSON" — least reliable.
• Common output failure modes: markdown fence wrapping → prefill or tool use; preamble → prefill; trailing commentary → prefill / stop sequences; hallucinated fields → tool use schema; type errors → tool use enforces, otherwise validate.
• Two-part fix for variable-detail extraction: optional schema fields (type: [string, null]) + explicit prompt instruction "extract if present, return null if absent, never infer." Neither alone is sufficient.
• Validation retry — 3 principles: tell Claude WHY previous output was rejected; bound retries (max 3 + cost cap); have a fallback path for final failure.
• Field-level validation feedback: include field name + wrong value + correct format + constraint violated. Never "data invalid, try again."
• Evaluator paradox: evaluator must see what generator misses. Same model + similar prompts = shared blind spots. Diversify with different family, different framing, or external rule-based check.
• Calibrated confidence thresholds: raw model confidence scores aren't probabilities — calibrate against labeled validation set before using as a routing threshold.
• tool_choice options: "auto" (model may skip), "any" (must call some tool — useful when document type is unknown), forced selection {"type":"tool","name":"X"} (specific tool first, e.g., extract_metadata before enrichment).
• "other" + detail string pattern for extensible enums — when the source has open-ended categories, define enum with known values + a string field for "other" detail. Prevents the model from forcing every value into an existing category.
• Nullable schema fields for optional source content. When a field may be absent, mark it nullable so the model returns null instead of fabricating a value to satisfy a required field.
• Validation-retry feedback loop: on failure, send a follow-up with (original document) + (failed extraction) + (specific validation error). Use Pydantic for schema-level validation. Track which retries succeed (format mismatches) vs which won't (information truly absent from source).
• detected_pattern field in structured findings — tracks which code constructs trigger each finding. Use it to analyze false-positive patterns when developers dismiss results.
• Explicit categorical criteria beat "be conservative." Vague filters like "only report high-confidence" fail. Concrete rules like "flag SQL injection ONLY when an unsanitized variable from an external HTTP request reaches a query string" precisely shape behavior.
• Multi-pass review architectures: per-file local analysis pass + cross-file integration pass. Use a second independent Claude instance for review (the generator's session retains reasoning context that biases self-review).
• Self-correction validation patterns: extract calculated_total alongside stated_total to flag arithmetic discrepancies. Add conflict_detected booleans for inconsistent source data.
• Few-shot for behavioral override: when Claude has a default "be helpful by inferring" instinct and you need verbatim preservation, few-shot examples are the most direct override.
• Escalation calibration: for inverted-escalation behavior (escalating easy cases, attempting hard ones), the fix is explicit escalation criteria in system prompt + few-shot boundary examples — not sentiment models or capability classifiers.
• Aggregate accuracy is misleading. 97% overall can hide a 50%-error subsegment. Validate by segment; for safety-critical errors, route the segment to mandatory human review.

Memorize

• What's loaded every API call: system message · conversation history · all tool definitions · prior tool results · resources/attached files · current user message.
• Stateless across separate API calls. No memory between calls — memory is an architectural choice (resending history, external store, retrieval).
• Context-bloat ranking (Section 6): tool results > conversation history (quadratic) > tool definitions.
• KNOWLEDGE → RAG · HISTORY → Summarization (Section 6 alert card).
• Why RAG fails for conversations: implicit references ("that," "as I mentioned"), inconsistent retrieval across turns, decisions get lost in different wording, no coherent voice across snippets.
• Lost in the middle: place critical info at start/end; front-load summaries; explicit section headers.
• 5 long-context strategies (Section 6 table): compact at source · summarization · RAG · sliding window · subagent isolation.
• Mid-session pivot: /compact. Divergent exploration: fork_session. Multi-phase: summarize-and-spawn between phases.
• Scratchpad pattern for long agentic sessions: write key findings to a file at the end of each phase; new phase starts by reading the scratchpad. Converts passive (buried in history) to active (fresh in context).
• Persistent case-facts block at the top of every prompt for transactional precision in long conversations.
• Confidence calibration:
  • Explicit labels: {finding, confidence: high|medium|low, reasoning}.
  • Route by confidence: high → auto; medium → secondary check; low → human review.
  • Multi-sample / consensus (~5× cost) — reserve for high-stakes.
  • Raw model scores are NOT probabilities. Calibrate against labeled validation set.
• 4 handoff boundaries: turn-to-turn · agent → subagent · session-to-session · agent → human (HITL). Each needs structured handoff.
• Agent → subagent handoff: pass goal + scope + required inputs + output schema. Return structured result, not full reasoning trail.
• Agent → human handoff (HITL): structured package — what trying to do, what's been done, why escalating, recommended action. Treat human as the next sub-agent.
• Defense in depth stack: better prompt → schema (tool use) → validation + bounded retry → confidence calibration + routing → idempotent tools + HITL on high-stakes → stop conditions + budget caps → observability.
• Recovery patterns: bounded retry with backoff · circuit breakers · graceful degradation (fall back to historical averages, flag as estimated) · idempotency for writes.
• Monitoring: task completion rate · error rate by category · cost per task · latency p50/p95/p99 · tool call distribution · stop-reason distribution · HITL escalation rate.
• Stratified random sampling for measuring error rates in high-confidence extractions. Validate accuracy by document type and field segment before reducing human review — aggregate 97% can hide a 30% segment failure.
• Field-level confidence scores calibrated using a labeled validation set. Raw model self-reported scores are NOT probabilities until calibrated.
• Structured handoff package when escalating to human: customer ID, root cause analysis, refund amount, recommended action. Human agents may not have access to the conversation transcript.
• Crash recovery via state manifests — each agent exports state to a known location; the coordinator loads a manifest on resume and injects relevant state into agent prompts.
• Coverage annotations in synthesis outputs — distinguish well-supported findings from gaps caused by unavailable sources. Helps the reader know what to trust.
• The reliability principle: predictable failure beats unpredictable success. Don't chase 100% — build bounded behavior, graceful failure, observability.
• Aggregate accuracy can mask catastrophic segment failure. Slice by segment; route safety-critical segments to mandatory human review until validated.
• Position-aware input — full mitigation: "lost in the middle" reliably affects MIDDLE positions; the model processes BEGINNING and END well. Place key findings at BOTH ends (summary at top, restate at bottom). Use explicit section headers. Don't only front-load — bookend.
• Multi-concern decomposition pattern: when a customer message has multiple distinct issues, decompose into separate items, investigate each in parallel using shared context, then synthesize a unified resolution. NOT sequential one-at-a-time; NOT a single mega-prompt jamming all concerns together.
• Render-by-content-type in synthesis: financial data → tables; news/timeline → prose; technical findings → structured lists. Forcing uniform format (e.g., bullets everywhere) destroys readability and erases signal that the content type itself carried.
• Temporal data — include dates in structured output: require publication_date / data_collection_date in subagent outputs. Prevents temporal differences ("2023 had 18%; 2025 has 27%") being mis-flagged as contradictions during synthesis. Apparent conflicts are often just time-series.
• Batch SLA math: 24-hour batch processing window means you must submit on a tighter cadence to hit downstream SLAs. Example: to guarantee a 30-hour SLA with the batch API, submit every 4 hours (4h queue wait + 24h processing + 2h buffer ≤ 30h). Frame batch as scheduled work, not a real-time call.
• PostToolUse trim pattern: raw tool outputs are often verbose (40+ fields from an order lookup). Use a PostToolUse hook to filter to the 3-5 fields the agent actually needs BEFORE the result enters context. Prevents context bloat from compounding turn-over-turn.
• Claim-source mappings preserved through synthesis: subagents must output structured {claim, source_url, source_doc, excerpt} tuples. Summarization MUST preserve and merge these, never collapse to claim-only. Attribution loss is irreversible once it happens.

Built by John for the CCA-F exam · Companion files: stem-decoder · references