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

Domain 3 is the most operational part of the CCA-Foundations blueprint. It tests whether you can configure Claude Code so that an agent behaves predictably across an individual workstation, a shared team repository, and a non-interactive CI/CD pipeline. Roughly one in five exam questions comes from this domain, so it is worth deep, hands-on familiarity rather than memorization.

This guide walks through every key concept the blueprint covers: the CLAUDE.md memory hierarchy, @path imports, path-scoped rules, custom slash commands versus Skills, plan mode and permission models, and headless runs for automation.

1. The CLAUDE.md memory hierarchy

Claude Code loads memory from several locations and layers them, from broadest to most specific. A useful mental model of precedence (most specific wins on conflict) is:

1. Enterprise / managed policy — organization-wide rules an administrator deploys; users cannot override them.
2. Project memory — ./CLAUDE.md checked into the repo and shared with the whole team via git.
3. Directory / subtree memory — a CLAUDE.md inside a subfolder that applies when Claude works on files there.
4. User memory — ~/.claude/CLAUDE.md, your personal preferences across all projects.
5. Local project memory — ./CLAUDE.local.md, personal and not committed (typically gitignored).

The key insight: memory is additive and hierarchical, not a single file. Enterprise and user contexts are loaded, then project and directory contexts refine or override them. Everything is concatenated into the system context at session start.

Good CLAUDE.md files are short, declarative, and verifiable. Encode taste as rules a linter or test can enforce, point to deeper docs rather than inlining them, and keep the root file as a map (≈100 lines) instead of an encyclopedia.

2. @path imports

Inside any CLAUDE.md you can pull in other files with the @ syntax:

Imports support nesting (commonly up to ~5 levels deep) so you can compose a modular knowledge base. The critical exam nuance: imports load at launch, so they consume context immediately — splitting one big file into many @path imports improves organization and reuse, but it does not reduce token usage, because all imported files are injected up front. Use imports to keep files DRY and navigable, not as a context-saving trick.

3. Path-scoped rules: .claude/rules/

Beyond CLAUDE.md, .claude/rules/*.md files let you attach guidance that is scoped to particular paths or file globs. This is how you say "when editing files under apps/api/, always use the repository pattern" without bloating the global memory. Project rules live in the repo; user rules live under ~/.claude/rules/. Rules are the right tool when guidance is conditional on what is being edited.*

4. Slash commands vs Skills

Both extend Claude Code, but they are different tools:

• Custom slash commands are markdown prompt templates stored in .claude/commands/ (project) or ~/.claude/commands/ (user). Invoking /my-command expands the template into the prompt. They are lightweight, explicit, user-invoked shortcuts. $ARGUMENTS and positional placeholders let you parameterize them.
• Skills are richer, model-invoked capability packages — a folder with a SKILL.md (name + description + instructions) plus optional scripts and resources. Claude reads the description and decides on its own when a skill is relevant, then loads its full instructions on demand (progressive disclosure).

Rule of thumb: reach for a slash command when you want a reusable, explicitly-triggered prompt; reach for a Skill when you want Claude to autonomously apply specialized procedural knowledge or bundle helper scripts.

5. Plan mode and permission models

Plan mode makes Claude research and propose a plan without making edits or running side-effecting tools, so you can approve the approach before execution. It is the safe default for non-trivial or architectural work.

Permissions govern which tools may run and whether each needs confirmation. Interactively, you allow/deny tool calls; for repeatable behavior you configure allow/deny rules in settings (e.g. allow Read, prompt on Bash). Permission modes range from default (prompt on risky actions) to fully autonomous. Tightening permissions for narrowly-scoped agents is a recurring "architect" theme on the exam.

6. Headless mode for CI/CD

Headless (non-interactive) mode is the automation building block. The entry point is the -p / --print flag, which sends one prompt and writes the result to stdout:

• --output-format accepts text (human), json (structured, parse with jq), or stream-json (incremental). The JSON object includes fields such as result, session_id, num_turns, duration and cost metadata.
• --allowedTools restricts the tool set so automation cannot run arbitrary commands; --dangerously-skip-permissions removes prompts entirely (only inside an already-sandboxed CI runner).
• --resume <session_id> continues a prior session for multi-turn automation.
• Interactive-only affordances like the slash-command menu are not available in -p mode — instead, describe the task in the prompt.

For long-running automation, manage context with /compact (summarize history to reclaim the window) and inspect/edit memory with /memory. Delegating read-only exploration to the Explore subagent keeps the main context clean while gathering repo facts.

Putting it together

A strong Domain 3 answer almost always means: put shared, durable rules in committed CLAUDE.md + .claude/rules/; keep personal preferences in user/local memory; choose slash commands vs Skills by who triggers them; default to plan mode for safety; and in CI use -p with --output-format json and a tight --allowedTools allowlist.