Home / CCA-F / Claude Code
DWG 03 — 20% OF EXAM

Claude Code

What this domain covers

Architecture and setup, the CLAUDE.md configuration hierarchy, slash commands / skills / subagents, and hooks, the Agent SDK, and CI/CD.

3.1Architecture and Setup

Claude Code runs as an agentic loop against your local (or CI) filesystem and shell: it reads code, proposes and takes actions, and observes the result, the same action loop as Domain 1 but applied specifically to a development environment.

Installation and configuration happen through settings.json, which controls permissions — what commands, file paths, and tools Claude Code is allowed to touch without asking, and what requires explicit approval each time. Permission scope is a real security boundary, not just a convenience setting.

Key points
  • Claude Code's core loop is the same act/observe/decide loop as any agentic system, scoped to a dev environment.
  • settings.json governs permissions — what's auto-allowed vs. what requires approval.

Full breakdown & examples → 3.1 Architecture and Setup

3.2CLAUDE.md Configuration

Claude Code reads configuration from three levels: user (~/.claude/CLAUDE.md, personal, never checked into git, applies only to you), project (.claude/CLAUDE.md or a root CLAUDE.md, version-controlled, applies to every teammate who clones the repo), and further path-scoped rules below that.

The exam's favorite trap in this domain: a developer stores team-wide conventions — naming, error handling, test structure — in their own user-level file instead of the project-level file. Claude Code behaves perfectly for them and inconsistently for every teammate who clones the repo, because the conventions never travel with the project.

For modular organization, @path imports are loaded eagerly — every imported file is inlined exactly as if pasted in, so splitting one large file into several imported files makes the source easier to maintain but does not shrink what's actually loaded into context. To reduce per-session context, use .claude/rules/ instead: path-scoped rules that load only when Claude is working in the matching directory.

Key points
  • User-level = personal, not version-controlled. Project-level = team-wide, version-controlled.
  • Classic trap: team conventions saved at user-level → inconsistent behavior across teammates.
  • @path imports load eagerly (no context savings); .claude/rules/ is path-scoped and does shrink context.

Full breakdown & examples → 3.2 CLAUDE.md Configuration

3.3Slash Commands, Skills, and Subagents

Custom slash commands package a specific, repeatable instruction (a code review checklist, a release process) behind a short invocation, so a team doesn't have to retype the same detailed prompt every time.

Skills package reusable procedural knowledge — not just a prompt, but instructions, examples, and sometimes scripts — that Claude Code can draw on across many different tasks.

Subagents in Claude Code follow the same context-isolation logic as Domain 1's orchestration model: delegate to a subagent when a piece of work is self-contained and would otherwise pollute the main session's context; handle it inline when it's short or depends heavily on context already in the main conversation.

Key points
  • Slash commands = shortcuts for repeatable, specific instructions.
  • Skills = packaged, reusable procedural knowledge, not just a single prompt.
  • Delegate to a subagent for self-contained work; keep short or context-dependent work inline.

Full breakdown & examples → 3.3 Slash Commands, Skills, and Subagents

3.4Hooks, SDK & CI/CD

Hooks let you enforce behavior programmatically rather than by instruction — running before or after a tool use, or gating permissions — so a rule like "never run this command" is guaranteed rather than merely requested.

The Claude Agent SDK exposes the same agentic loop Claude Code uses, but embeddable in your own application rather than the terminal — the building block for custom agent products.

In CI/CD, Claude Code defaults to an interactive mode that expects keyboard input, which will simply hang forever in a pipeline with no keyboard attached. The fix is the -p (or --print) flag, which switches Claude Code to non-interactive print mode: it processes the prompt, writes the result to stdout, and exits. Pair it with --output-format json to get machine-parseable output a downstream CI step can consume.

Key points
  • Hooks enforce rules programmatically (pre/post tool-use, permission gating) — guaranteed, not requested.
  • The Agent SDK embeds Claude Code's loop into your own application.
  • -p / --print is the fix for a CI job hanging on stdin; --output-format json makes output machine-parseable.

Full breakdown & examples → 3.4 Hooks, SDK & CI/CD


Check yourself
1.A CI pipeline invoking Claude Code hangs indefinitely and never completes. What's the fix?
Show answer
Add the -p (or --print) flag to run Claude Code in non-interactive print mode. Without it, Claude Code waits for interactive keyboard input that a CI job can never provide.
2.Developer A's Claude Code follows all team conventions; Developer B clones the same repo and gets inconsistent results. What's the most likely root cause?
Show answer
The conventions live in Developer A's user-level ~/.claude/CLAUDE.md instead of the project-level .claude/CLAUDE.md (or root CLAUDE.md) — so they never travel to teammates who clone the repository.
3.You split a 500-line CLAUDE.md into five 100-line files pulled in with @path imports, hoping to reduce context usage. Did it work?
Show answer
No. @path imports load eagerly — every imported file is inlined in full, so the loaded context is the same size as before. Path-scoped rules in .claude/rules/ are the tool for actually shrinking per-session context.

Claude Certified Architect — Study NotesDWG 03