This domain is about 20% of the exam, roughly 12 of its 60 questions.

Every point below comes from Anthropic's official documentation; each section lists its sources.

Think first When a teammate's Claude sessions ignore a team convention, where should that instruction live, and how do you check what loaded?

Why it matters: Questions describe Claude ignoring an instruction and ask which CLAUDE.md level, import or rule file fixes it.

CLAUDE.md files stack: user, project and subdirectory files all load and add together. Only project files committed to git reach teammates. Imports and .claude/rules/ keep instructions modular, and /memory shows which memory files are in play.

User, project and directory CLAUDE.md files all add together. Discovered files are concatenated rather than overriding each other. Content runs from the filesystem root down to the working directory, so files nearer the launch directory are read last.

The three CLAUDE.md levels compared

User-level instructions never travel through version control. A convention kept in your ~/.claude/CLAUDE.md applies only to you. Move it into the project CLAUDE.md and commit it to git. Then the instruction applies consistently to every team member.

Exam trap Asking each person to copy the line into their own user-level file is not the fix. Team standards belong in the project CLAUDE.md, committed to git.

No hard precedence rule decides between levels. If two levels disagree, the result depends on Claude's reading of them. Write rules that do not conflict, or state the precedence explicitly in the more specific file.

Exam trap A project CLAUDE.md does not silently replace a user CLAUDE.md. Both load, and Claude sees both.

Import standards files instead of pasting them in. Use @path/to/import to include, for example, the standards each package needs. Relative paths resolve from the importing file, not the working directory, and nesting stops at 4 hops. Wrap a path in backticks to mention it without importing it. External imports first need approval in a dialog.

Exam trap Imports organize a long CLAUDE.md but do not lower its context cost. Imported files load together with the file that imports them.

Split a large CLAUDE.md into one file per topic. Give each file a descriptive name, such as testing.md or api-design.md. Every .md file there is found recursively, so subfolders work. A rule without paths frontmatter loads at launch, with priority equal to .claude/CLAUDE.md. A rule with paths applies only to matching files.

Check which memory files Claude actually has. /memory lists CLAUDE.md, CLAUDE.local.md and other memory files across user and project scopes, and opens them for editing. /context lists the memory files loaded at launch; one missing there is invisible to Claude. Each session starts fresh, so lasting instructions belong in CLAUDE.md.

settingSources decides which files the SDK loads. With "project", CLAUDE.md and .claude/rules/*.md load at session start. With "user", ~/.claude/rules/*.md loads too. Leaving settingSources out equals user, project and local together, while an empty list limits the agent to programmatic settings.

• User-level ~/.claude/CLAUDE.md reaches only you; team standards go in the committed project CLAUDE.md.
• All CLAUDE.md levels add together, with no hard precedence rule between them.
• Use @import to include each package's relevant standards files and keep CLAUDE.md modular.
• Split a large CLAUDE.md into one-topic files in .claude/rules/.
• Use /memory to see which memory files are in play when behavior differs between sessions.

Sources: Use Claude Code features in the SDK - Claude Code Docs · How Claude remembers your project - Claude Code Docs · Explore the .claude directory - Claude Code Docs · Claude Certified Architect – Foundations Exam Guide Version 1.0 · Effective July 2026 · Exam code: CCAR-F · This guide i · How Claude Code works - Claude Code Docs

Think first Where should a reusable workflow live, and how do you keep its output out of your main session?

Why it matters: Questions describe a workflow a developer or team wants to reuse and ask where to store it and how to configure it.

Commands and skills live either in the project, shared through version control, or in your home directory, for you alone. Skills add frontmatter that controls isolation, tool access and arguments, and they load only when needed, unlike CLAUDE.md.

Team commands go in the repo, personal ones in your home directory. Commands in .claude/commands/ are version-controlled and reach everyone who clones or pulls the repo. Commands in ~/.claude/commands/ stay personal. Skills follow the same split between .claude/skills/ and ~/.claude/skills/.

Project and user scope compared

Exam trap Editing a shared project skill to suit yourself affects teammates. Create a personal variant in ~/.claude/skills/ under a different name.

A command file's name becomes the command; skills are its successor. The file .claude/commands/deploy.md creates /deploy. Each skill is a directory with a SKILL.md file, whose frontmatter needs a name and a description. The description decides when Claude invokes the skill.

Fork skills whose output would flood the main session. With context: fork, the skill runs in an isolated sub-agent context. Use it for verbose output, such as codebase analysis, or for exploratory work, such as brainstorming alternatives.

Example: The SKILL.md frontmatter line that runs a skill in an isolated sub-agent context.

context: fork

allowed-tools limits tools; argument-hint asks for parameters. You might limit a skill to file write operations, for example, to prevent destructive actions. When someone runs the skill with no arguments, argument-hint asks them for the parameters it needs. A project skill can combine context: fork with allowed-tools.

Exam trap Do not count on allowed-tools pre-approvals everywhere. In SDK sessions, Claude Code ignores them when managed settings set allowManagedPermissionRulesOnly.

Skills load on demand; CLAUDE.md is always loaded. Put task-specific workflows in skills and universal standards in CLAUDE.md. At startup only each skill's name and description load, and Claude reads the full SKILL.md once the skill becomes relevant.

Exam trap A team-wide coding standard does not belong in a skill. Always-loaded universal standards go in CLAUDE.md.

• Team commands go in .claude/commands/; personal ones go in ~/.claude/commands/.
• Use context: fork for skills with verbose or exploratory output.
• Use allowed-tools to restrict tools and argument-hint to prompt for parameters.
• Skills are on-demand workflows; CLAUDE.md holds always-loaded standards.

Sources: Claude Certified Architect – Foundations Exam Guide Version 1.0 · Effective July 2026 · Exam code: CCAR-F · This guide i · Extend agents with skills - Claude Code Docs · Skill authoring best practices - Claude Platform Docs · Get started with Agent Skills in the API - Claude Platform Docs

Think first When should a convention live in a path-scoped rule instead of a CLAUDE.md file inside a subdirectory?

Why it matters: Questions describe where a convention's files sit in the codebase and ask which rule setup loads it only when it is needed.

A rule file in .claude/rules/ can list glob patterns under paths: in its frontmatter. Claude then loads that rule only when it works with a matching file. Unrelated conventions stay out of context, wherever the matching files sit.

Split a large CLAUDE.md into topic files in .claude/rules/. Each file holds one topic, such as testing.md, api-conventions.md or deployment.md. Together they replace one monolithic CLAUDE.md. Rule files can live at project or global scope.

A paths: field in YAML frontmatter holds the rule's glob patterns. Claude loads the rule only when it reads, writes or edits a matching file. The field is optional, so a rule without it stays unscoped.

Example: Rule frontmatter that loads API conventions only for files under the src/api folder.

paths: ["src/api/**/*"]

• src/api/**/*: matches every file below src/api

Rules that match no current file stay out of context. That cuts irrelevant context and token usage. It matters because more context is not automatically better: accuracy and recall drop as tokens grow, which is called context rot.

Exam trap One big root CLAUDE.md is not the lean choice in a large codebase. It tends to spend context on unrelated instructions, or it stays too generic to help.

A glob like /.test.tsx matches test files in any directory. The pattern targets a file type, not a folder. One rule can carry testing conventions for every test file, wherever it lives. A broader pattern such as **/*.test.* works the same way.

Pick a path-scoped rule when one convention spans scattered paths. A per-directory CLAUDE.md sits beside its code and suits conventions that one directory's owners maintain. Test files spread across the codebase fit a glob rule better.

Path-scoped rule and per-directory CLAUDE.md compared

Exam trap Directory CLAUDE.md files are the wrong tool for a convention that spans many directories, like scattered test files. A glob-pattern rule covers them from one place.

Compaction summarizes the message history; scoped rules then reload on demand. A scoped rule loads into the message history, so compaction summarizes it away with everything else. Claude Code then reloads it on demand rather than re-injecting it. Unscoped rules and the project-root CLAUDE.md come back from disk.

Exam trap Do not count on a scoped rule surviving compaction. If it must persist, remove its paths: frontmatter or move it into the project-root CLAUDE.md.

The project setting source loads .claude/rules/.md files. It reads rules from the working directory and from every parent directory. User rules in ~/.claude/rules/ need the user source. Omitting settingSources loads user, project and local sources.

• Put glob patterns under paths: in a rule's YAML frontmatter so it loads only for matching files.
• Choose a glob rule over directory CLAUDE.md files when a convention spans many directories.
• A pattern like **/*.test.tsx applies a convention by file type, in any folder.
• Scoped rules reload on demand after compaction; drop paths: if a rule must always persist.

Sources: Set up Claude Code in a monorepo or large codebase - Claude Code Docs · Claude Certified Architect – Foundations Exam Guide Version 1.0 · Effective July 2026 · Exam code: CCAR-F · This guide i · Explore the context window - Claude Code Docs · Explore the .claude directory - Claude Code Docs · Context windows - Claude Platform Docs · Use Claude Code features in the SDK - Claude Code Docs

Think first How do you tell whether a coding task needs plan mode or can go straight to direct execution?

Why it matters: Questions describe a coding task and ask whether to plan first, execute directly, or combine the two.

Plan mode suits complex, multi-file or architectural work, where exploring first prevents costly rework. Direct execution suits simple, well-scoped changes. Big tasks often plan first, then execute the approved plan.

Use plan mode for complex, multi-file or architectural work. Choose it for large-scale changes, several valid approaches or architectural decisions. Examples are restructuring microservices, a library migration touching 45+ files, or picking between integration approaches with different infrastructure needs.

Exam trap A task is not simple just because it is one feature. A new feature with several valid implementation approaches still calls for plan mode.

Go direct for simple, well-scoped changes. A single-file bug fix with a clear stack trace, or one added date validation conditional, has a clear scope. Such changes are well understood, so you can make them without a planning step.

Plan mode and direct execution compared

Exam trap Plan mode is not needed for every edit. A single-file fix with a clear stack trace fits direct execution.

Claude explores and proposes, but does not edit your source. It reads files and runs shell commands to explore, then writes a plan. Edits stay blocked until you approve it, except in interactive terminal sessions with bypass permissions available. Press Ctrl+G to edit the plan yourself first.

Press Shift+Tab, or prefix one prompt with /plan. You can also start the CLI in plan mode, or set defaultMode to plan in .claude/settings.json for a project. Approving the plan exits plan mode and switches to the permission mode you chose, so Claude starts editing.

Example: Starts a Claude Code session in plan mode, which blocks edits until you approve a plan.

claude --permission-mode plan

Send verbose discovery to the Explore subagent. The Explore subagent works in its own context and returns only a summary. That prevents context window exhaustion during multi-phase tasks, while the main conversation keeps the high-level view.

Exam trap The Explore subagent cannot be resumed later. It is one-shot and returns no agentId, so use a custom or general-purpose agent instead.

Investigate in plan mode, then implement directly. For a library migration, plan the approach first, then execute it. For changes across several packages, the plan file is re-injected after each compaction, so the plan survives a long session.

• Plan mode fits large-scale, multi-file, architectural or multi-approach tasks.
• Direct execution fits well-understood changes with a clear scope.
• Plan mode explores and proposes without editing your source until you approve.
• Use the Explore subagent to keep verbose discovery out of the main context.

Sources: Claude Certified Architect – Foundations Exam Guide Version 1.0 · Effective July 2026 · Exam code: CCAR-F · This guide i · Choose a permission mode - Claude Code Docs · Set up Claude Code in a monorepo or large codebase - Claude Code Docs · Explore the .claude directory - Claude Code Docs · Subagents in the SDK - Claude Code Docs

Think first When Claude's output is close but not right, which kind of feedback moves it forward fastest?

Why it matters: Questions describe a refinement that is stuck and ask which technique, or which way of giving feedback, will fix it.

Good refinement replaces vague prose with something Claude can check against. Examples show the exact transformation, tests show what passes, and questions surface what you forgot. How you group your fixes depends on whether they interact.

Give 2-3 concrete input/output examples when prose is misread. If a written description of a transformation gets read in different ways, examples settle it. They are the most effective way to show the exact result you expect.

Exam trap Rewriting the prose description in more detail is the tempting fix. When descriptions are read inconsistently, concrete examples work better.

Give the failing input and the output you expect. For a migration script that mishandles null values, a specific test case pins down the right behavior. Explicit examples of how to handle an edge case also help where Claude might misclassify an input.

Cover behavior, edge cases and performance before any code exists. Then iterate by sharing the test failures. Claude Code can run the suite, read the errors, edit the code and rerun the tests.

Have Claude ask questions before it implements anything. This surfaces points you may not have anticipated. It helps most in an unfamiliar domain, where design issues such as cache invalidation or failure modes are easy to miss.

Send interacting issues together; fix independent ones in turn. When fixes interact, describe all of them in one detailed message. Fix independent issues sequentially, one per iteration.

Grouping feedback by how the issues relate

Exam trap Sequential fixes suit independent issues only. When the fixes interact, describe all of them together in a single detailed message.

Refine with feedback when the first attempt misses. Claude Code is conversational, so you correct course instead of starting over. A message typed while Claude works is queued and read as soon as the running tool calls finish.

Tune the prompt on a sample set before a large batch. This raises the first-pass success rate and cuts the cost of resubmitting. Judge readiness against the success criteria and thresholds you set in advance.

• When prose is read inconsistently, show 2-3 concrete input/output examples instead.
• Write tests for behavior, edge cases and performance first, then iterate on the failures.
• Use the interview pattern in unfamiliar domains to surface design issues before building.
• Send interacting issues in one detailed message; fix independent issues one at a time.

Sources: Claude Certified Architect – Foundations Exam Guide Version 1.0 · Effective July 2026 · Exam code: CCAR-F · This guide i · Ticket routing - Claude Platform Docs · How Claude Code works - Claude Code Docs

Think first What does Claude Code need to run unattended in a pipeline and produce findings your CI can act on?

Why it matters: Questions describe a CI job that hangs, produces unusable output or weak reviews, and ask which flag or setup fixes it.

In CI, nobody is there to answer prompts, so Claude Code must run non-interactively. It needs machine-readable output for the pipeline, project context from CLAUDE.md, and a reviewer that did not write the code.

Use -p so a CI run never hangs waiting for input. Non-interactive mode suits pipelines. Unattended runs differ in small ways: a background command is stopped at its time limit, unlike in a local interactive session.

Exam trap Running Claude Code in CI without -p is the mistake to spot. The run can then hang waiting for interactive input that never comes.

Pair --output-format json with --json-schema. The findings then come back structured and parseable. Your pipeline can post them automatically as inline comments on the pull request.

CLAUDE.md carries project context into CI runs. Record testing standards, what makes a test valuable, and the fixtures available. That raises test quality and cuts low-value tests. The review command follows CLAUDE.md even in a -p run.

Exam trap Do not look for a /code-review file on disk to hold review rules: it is a bundled skill with none. Put the rules every review must follow in CLAUDE.md.

Put the existing test files in context before generating tests. Claude can then see which scenarios the suite already covers. It suggests new cases rather than repeating old ones.

The session that wrote the code is a weak reviewer of it. It keeps the reasoning that produced the code, so it rarely questions its own choices. An independent instance catches subtle issues better than self-review instructions or extended thinking.

Self-review compared with an independent review instance

Exam trap Asking the same session to review its work, or turning on extended thinking, is not the fix. Use an independent review instance.

Automatic follow-up reviews focus on what changed. In managed Code Review, a review that starts after a push looks at changes since the last review. It posts fewer nits and pre-existing findings.

• Run Claude Code in CI with -p so it never waits for interactive input.
• Use --output-format json with --json-schema for findings your pipeline can post as inline comments.
• Document testing standards and fixtures in CLAUDE.md to raise the quality of generated tests.
• Review generated code with an independent instance, not the session that wrote it.

Sources: Claude Certified Architect – Foundations Exam Guide Version 1.0 · Effective July 2026 · Exam code: CCAR-F · This guide i · Use Claude Code features in the SDK - Claude Code Docs · Interactive mode - Claude Code Docs · Review locally with /code-review - Claude Code Docs · Read and request reviews on a pull request - Claude Code Docs