Claude Code

Claude Code is the lightest domain on the CCDV-F exam: 3.1% of the blueprint, roughly one or two items out of 53. Say the quiet part out loud — candidates over-study it precisely because it is the most familiar tool on the list, and hours spent here buy almost nothing. Learn the core operations, be able to reason about configuration precedence, and move on to Applications and Integration.

What it actually tests is configuration literacy, not command trivia. The exam will not ask you to recite every flag; it will hand you a scenario where two config files disagree, or where a permission rule blocks an automated run, and ask what happens. So the one idea that unlocks the domain is layering: memory, settings and permissions all resolve as a stack, with enterprise-managed policy at the top and user-level defaults at the bottom, and the narrower, more specific scope winning over the broader one.

Know the CLAUDE.md hierarchy, the settings file locations, the permission modes, how a custom slash command and a skill differ, and how to run non-interactively with -p. That is the whole return on investment here.

• Memory precedence, highest first: enterprise-managed policy, then project CLAUDE.md at the repo root, then user memory at ~/.claude/CLAUDE.md. More specific scope wins.
• Claude Code walks up the directory tree from the working directory and loads every CLAUDE.md it finds; CLAUDE.md files in subdirectories load on demand when work touches those directories.
• CLAUDE.md can pull in other files with an @ path reference, so a monorepo can keep one short root file that imports per-package guidance.
• /init bootstraps a CLAUDE.md for an existing repo. /memory opens the memory files for editing. Starting a line with # adds a memory without leaving the session.
• Keep CLAUDE.md short and imperative. It is prepended context on every request — bloat costs tokens on every turn and dilutes the instructions that matter.
• Settings precedence, highest first: enterprise-managed settings, then command-line flags, then .claude/settings.local.json, then .claude/settings.json, then ~/.claude/settings.json.
• Check .claude/settings.json into the repo for shared team config; leave .claude/settings.local.json untracked for personal overrides.
• Permission modes: default prompts for risky actions, acceptEdits auto-approves file edits, plan researches without mutating anything, and bypass mode skips prompts entirely. Set with --permission-mode or cycle in-session.
• Permission rules are allow, ask and deny lists of tool patterns such as Bash(npm run test:*) or Edit(src/**). `deny` always wins over allow, regardless of specificity.
• Custom slash commands are markdown files in .claude/commands/ (project) or ~/.claude/commands/ (personal). The filename is the command name; subdirectories namespace it. Use $ARGUMENTS for the whole argument string or $1, $2 for positional ones.
• Skills are folders under .claude/skills/ containing a SKILL.md with YAML frontmatter. Claude invokes them itself when the description matches the task; supporting files load only when needed.
• Non-interactive runs use claude -p "prompt". Add --output-format json for a parseable result, pre-grant tools with --allowedTools, and cap work with --max-turns.

• The classic failure is a rule that never fires because a broader one already answered. When a run behaves unexpectedly, check deny first, then enterprise policy, then the local settings file — not the file you edited.
• Invalid JSON in .claude/settings.json is a silent-feeling failure: the config does not apply and the session falls back to defaults. /doctor and startup diagnostics are the fastest way to catch it.
• A team member reporting different behavior on the same repo almost always has a .claude/settings.local.json overriding the shared file. That file is personal and untracked by design.
• Headless runs hang or fail rather than prompt. If -p needs a tool that is not pre-approved, it cannot ask a human, so allow-list every tool the automation genuinely needs before shipping it to CI.
• Do not reach for bypass mode to fix a permission error. Prefer a narrow allow rule; reserve permission bypass for isolated containers with no credentials and no network you care about.
• Long sessions degrade as context fills. /clear starts fresh between unrelated tasks; /compact summarizes and continues one task. Reaching for /compact when you meant /clear carries stale assumptions forward.
• --continue resumes the most recent session in the directory and --resume picks a specific one. Neither restores an accidentally cleared conversation, so clear deliberately.
• Overstuffed CLAUDE.md files are a real production problem: contradictory instructions accumulated over months make behavior nondeterministic. Treat memory as code and review it.
• A skill that never triggers usually has a vague description. The description is the only thing Claude sees when deciding to invoke it, so write it as when-to-use text, not as a title.
• Slash commands do not fire on their own — the user types them. If you want automatic behavior, you want a skill; if you want guaranteed behavior, you want a hook.
• Files outside the working directory are not readable by default. Grant extra roots explicitly through settings rather than launching the session from a higher directory.
• Secrets belong in the environment or a credential helper, never in CLAUDE.md or a checked-in settings file — both are shared with the team and sent as context.

CLASP — clasp the layers together, top down. It is the order you configure a repo in, and the order you debug one when the configuration misbehaves.

• C — CLAUDE.md first. Project memory before anything else. Precedence runs enterprise policy, then project, then user; subdirectory files load on demand; @ references import shared guidance.
• L — Layered settings. Enterprise-managed, then CLI flags, then .claude/settings.local.json, then .claude/settings.json, then ~/.claude/settings.json. Shared config is checked in; local overrides are not.
• A — Allow, ask, deny — and mode. Tool-pattern rules where deny beats everything, plus the session permission mode: default, acceptEdits, plan, or bypass.
• S — Slash commands and Skills. Commands live in .claude/commands/ and are invoked by the user with $ARGUMENTS. Skills live in a SKILL.md inside a named folder under .claude/skills/ and are invoked by Claude based on their description.
• P — Print mode. claude -p for automation, --output-format json for parseable output, --allowedTools because headless cannot prompt, --max-turns to bound cost.

If a scenario question asks why something did not take effect, walk CLASP in order and the answer is nearly always a layer above the one you were looking at.