CCA-F Part 3: Claude Code Configuration and Workflows (20%)

Part 3 of 7 of Claude Certified Architect — Foundations: a complete self-study tutorial. See all parts.

Domain 2: Claude Code Configuration & Workflows (20%)

This domain tests whether you can configure Claude Code for a team, scope rules to the right files, and choose the right mode for each kind of work.

The CLAUDE.md hierarchy

CLAUDE.md is the persistent system prompt for a project. It is loaded at the start of every session. There are three levels, merged in order:

1. User-level ~/.claude/CLAUDE.md — applies everywhere on this machine. Personal preferences ("use UK English in any prose I write").
2. Project-level <repo>/CLAUDE.md — shared with the team, committed to Git. Architectural rules, coding conventions, "always read X first."
3. Directory-level <repo>/some/path/CLAUDE.md — applies only when you are working inside that directory. Useful when one part of the repo (a Python backend, say) has different rules from another (a TypeScript frontend).

The deeper file wins on conflicts. Keep each level short — the merged prompt is a tax on every turn.

.claude/rules/ with path scoping

Inside <repo>/.claude/rules/ you can drop YAML-frontmatter Markdown files that apply only to matching paths:

---
paths:
  - "src/components/**/*.tsx"
  - "src/components/**/*.ts"
description: React/TypeScript style rules
---
- Functional components only, no class components.
- Prefer hooks over render props.
- Co-locate styles in module CSS.

Use rules instead of stuffing everything into CLAUDE.md when a rule applies only to certain files. The exam often shows a scenario where "frontend devs get Python-style comments in TS" — the right answer is add a .claude/rules/ file with paths: matching *.ts*.

Custom skills

Skills are reusable Claude Code procedures, stored in .claude/skills/, invoked via /skill-name. A skill can:

• Declare a fixed list of allowed-tools (sandboxing — e.g., a "release notes" skill that can only Read and Write, never Bash).
• Use context: fork so the skill runs in an isolated context window that won't pollute the main session.

The exam asks "the skill's tool calls keep contaminating the conversation" — the right answer is context: fork.

Plan mode vs. direct mode

• Plan mode (Shift+Tab to toggle, or --permission-mode plan from the CLI). Claude produces a written plan and waits for your "go ahead" before touching any file. Use for: architectural decisions, refactors, anything where the wrong move is expensive.
• Direct mode. Claude edits and runs commands subject to your permission settings. Use for: typo fixes, small renames, anything where reading the diff afterwards is enough.

The exam tests when each is appropriate. The wrong answer is usually "enable plan mode globally" — plan mode for trivial work just wastes the user's time.

CI/CD integration

Headless usage: claude -p "<prompt>" --output-format json. Key flags:

• -p runs a single prompt non-interactively and exits.
• --output-format json returns structured output the CI step can parse.
• --permission-mode acceptEdits for read-only review jobs.
• Each PR review should be stateless — no shared session, no shared memory. Otherwise reviews leak context between unrelated PRs.

For automated code review the exam pattern is: two-pass review. Pass 1 finds candidate issues; pass 2 validates each candidate against the file and only posts confirmed issues. This dramatically reduces false positives.

<a id="domain-3"></a>

← Part 2 of 7: Agentic Architecture and Orchestration (27% of the exam) · All parts · Part 4 of 7: Prompt Engineering and Structured Output (20%) →