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

6 Task Statements / Lessons

3.1 CLAUDE.md Hierarchy, Scoping, and Modular Organisation

Project-level .claude/CLAUDE.md (or root CLAUDE.md) overrides user-level (~/.claude/) which overrides global.
Modular organisation keeps conventions maintainable.

3.2 Custom Slash Commands and Skills

Unified Skills system:

• .claude/commands/foo.md → /foo
• .claude/skills/foo/SKILL.md (supports frontmatter: context: fork, allowed-tools, argument-hint)

Skills can be project-scoped (shared via git) or user-scoped (personal).

3.3 Path-Specific Rules for Conditional Convention Loading

Load different conventions based on file path or directory (e.g., stricter rules for /src/payments).

3.4 Plan Mode vs Direct Execution

When Claude Code should produce a plan first versus executing immediately.
Trade-offs of each mode for safety and speed.

3.5 Iterative Refinement Techniques

How to drive Claude Code through successive improvement cycles while preserving context and intent.

3.6 CI/CD Integration

Running Claude Code in pipelines (GitHub Actions claude-code-action, CLI flags such as --append-system-prompt, --allowedTools, --max-turns).

---

High-yield exam items: Correct location of team vs personal skills, meaning of context: fork, and CLAUDE.md precedence order.

CCAR-F Domain 3 · Task 3.1

What You Need to Know

A CLAUDE.md file is a Markdown file of instructions for Claude Code. Claude Code reads these files at three levels.

The Three-Level Hierarchy

Level	Location	Scope
User	~/.claude/CLAUDE.md	Personal only; not version-controlled
Project	.claude/CLAUDE.md or root CLAUDE.md	Shared via git; team standards
Directory	subdirectory CLAUDE.md	Package-specific conventions

Loading Order and Conflict Handling

All discovered files are concatenated into context rather than overriding each other. Load order is broadest → most specific, but reading last does not win a conflict. If two rules contradict, Claude may pick one arbitrarily.

For rules that must hold on every run (blocked tools, formatters, permissions), use settings.json or a hook — not CLAUDE.md.

Modular Organisation with @ path imports

# .claude/CLAUDE.md
Coding standards:
@./standards/naming-conventions.md
@./standards/error-handling.md

CLAUDE.local.md

Local-only overrides. Gitignored by convention. Appended after CLAUDE.md at the same level.

The .claude/rules/ Directory

Topic-specific rule files. Can include YAML frontmatter with path scoping (Task 3.3).

What Survives Compaction

Project-root CLAUDE.md comes back intact after /compact. Nested CLAUDE.md and path-scoped rules load on demand.

Diagnosing What Loaded

• Exam answer: /memory
• Current product: /context shows what loaded at launch under Memory files

Exam Traps

• New team member not receiving instructions → conventions in user-level instead of project-level
• Thinking /memory triggers configuration loading
• Assuming directory-level CLAUDE.md is best for cross-directory conventions

Practice Scenario

Developer A’s Claude Code follows team API naming conventions. Developer B (new) gets inconsistent naming. Same repo, same branch. Most likely root cause?

Build Exercise: Build a Multi-Level CLAUDE.md Configuration (30 min)

CCAR-F Domain 3 · Task 3.2

What You Need to Know

A skill is a named, reusable set of instructions that Claude Code loads on demand. You run it as a slash command (/deploy).

The Unified Skills System

Location	Structure	Creates
.claude/commands/deploy.md	Flat Markdown file	/deploy
.claude/skills/deploy/SKILL.md	Directory + SKILL.md entrypoint	/deploy (canonical, fuller-featured)

Skills path supports supporting files, auto-discovery, and wins on name conflict.

Two Scoping Levels

• Project (.claude/skills/ or .claude/commands/) — version-controlled, shared via git
• User (~/.claude/skills/ or ~/.claude/commands/) — personal, not shared

Skills Frontmatter (exam-tested options)

---
description: "..."
context: fork          # run in isolated sub-agent; keep verbose output out of main conversation
allowed-tools:         # exam: "restricts"; current product: pre-approves
  - Read
  - Grep
argument-hint: "..."   # exam: prompts for required parameters; current: autocomplete hint
---

Skills vs CLAUDE.md

	CLAUDE.md / rules	Skills
Load	Every session	On demand (explicit or auto-match)
Purpose	Always-on standards	Task-specific workflows
Context cost	Always present	Only when invoked

Exam Traps

• Creating a flat .md file directly inside .claude/skills/
• Placing a team-shared command in a user-scoped path
• Thinking skills behave like CLAUDE.md for always-on guidance
• Leaving a verbose skill to run inline (use context: fork)
• Putting task-specific workflows in CLAUDE.md

Practice Scenario

Team wants a /review command for everyone who clones the repo. One developer also wants a personal /brainstorm skill with verbose output that does not clutter the main conversation. Where should each go and what configuration does the skill need?

Build Exercise: Create Custom Commands and Skills (30 min)

CCAR-F Domain 3 · Task 3.3

What You Need to Know

Path-specific rules load conventions only when you edit files matching their glob patterns. They solve what neither root CLAUDE.md nor directory-level CLAUDE.md handles well: one file type scattered across many directories.

How Path-Specific Rules Work

Rule files live in .claude/rules/. Each starts with YAML frontmatter:

---
paths: ["terraform/**/*"]
---
# Terraform Conventions
- Use snake_case for all resource names
- Tag every resource with environment and team labels

Why Not Directory-Level CLAUDE.md?

Test files across 50+ directories would need a CLAUDE.md in each → massive duplication and drift.

Why Not Root CLAUDE.md?

Root CLAUDE.md loads in every session. Terraform conventions would consume tokens while editing React components.

Key Concept: Path-scoped rules are more token-efficient because they load only when you edit matching files.

When to Use Each Approach

Scenario	Best approach
Universal team standards	Root CLAUDE.md
Conventions for one package directory	Directory-level CLAUDE.md
Conventions for a file type across many directories	Path-specific rules with globs
Task-specific workflows on demand	Skills

Exam Traps

• Choosing directory-level CLAUDE.md for cross-directory conventions
• Placing file-type-specific conventions in root CLAUDE.md
• Confusing skills with path-specific rules for automatic convention application

Practice Scenario

Test files co-located with source files throughout 50+ directories. Team wants the same conventions for every test, loaded only when a test file is being worked on, with nothing to invoke. Most maintainable approach?

Build Exercise: Configure Path-Specific Rules with Glob Patterns (30 min)

CCAR-F Domain 3 · Task 3.4

What You Need to Know

Claude Code has two main modes:

• Plan mode: reads the codebase, analyses dependencies, proposes an approach — does not modify files until you approve.
• Direct execution: makes changes straight away.

When to Use Plan Mode

• Large-scale changes / restructuring
• Multiple valid approaches exist
• Architectural decisions required
• Multi-file modifications
• Codebase exploration needed

How to enter: claude --permission-mode plan, Shift+Tab, or prefix with /plan.

When to Use Direct Execution

• Well-scoped change (single-file bug with clear stack trace)
• Correct approach already known
• Limited scope (one function, one file)

Key Concept: The decision is about ambiguity, not difficulty. A difficult but well-defined bug fix is direct execution. A seemingly simple feature with multiple approaches is plan mode.

The Explore Subagent

Keeps verbose discovery output out of the main conversation. Runs exploration in isolation and returns summaries.

Hybrid Approach: Plan Then Execute

1. Plan phase → explore, evaluate, design strategy
2. Execute phase → implement the planned approach file by file

Decision Framework

Task	Mode
Architectural restructuring	Plan
Library migration (many files)	Plan then execute
Multiple valid approaches	Plan
Single-file bug with clear stack trace	Direct
Known fix, known location	Direct

Exam Traps

• Defaulting to direct execution for multi-file architectural changes
• Using plan mode for a single-file bug with clear stack trace
• Doing verbose discovery in the main conversation
• Starting direct and switching to plan only when complexity emerges

Practice Scenario

Three tasks: (1) restructure monolith into microservices, (2) fix null pointer in single function with clear stack trace, (3) migrate logging library across 30 files. Which mode for each?

Build Exercise: Practice Plan Mode vs Direct Execution Decision-Making (45 min)

CCAR-F Domain 3 · Task 3.5

What You Need to Know

Iterative refinement steers Claude Code towards the right result over several rounds. Five techniques:

Technique Hierarchy

Priority	Technique	Best for
1	Concrete input/output examples	Inconsistent interpretation of a known transformation
2	Test-driven iteration	Complex transformations with many edge cases
3	Interview pattern	Unfamiliar domains (Claude asks questions first)
—	Batch feedback	Multiple issues that interact with each other
—	Sequential feedback	Multiple independent issues

Key Concept: Interview pattern is for unfamiliar domains (surface missed considerations). Concrete examples are for when you know the exact transformation but the model interprets it inconsistently. Do not confuse the two.

Batch vs Sequential

• Batch (one message) when fixes interact
• Sequential when issues are independent

Switching From Prose to Examples

1. Observe inconsistency
2. Switch to 2–3 concrete before/after pairs
3. Verify generalisation on a new case
4. Add edge-case examples if needed

Exam Traps

• Refining prose when the model interprets inconsistently (switch to examples)
• Sending interacting fixes one message at a time
• Using the interview pattern when you already know the exact transformation

Practice Scenario

Developer describes a transformation in prose. Claude Code interprets it differently each time. Developer knows precisely what the finished code should look like. What technique first?

Build Exercise: Practice Iterative Refinement Techniques (30 min)

CCAR-F Domain 3 · Task 3.6

What You Need to Know

In CI/CD, Claude Code runs headless (no keyboard). Key patterns:

The -p Flag: Non-Interactive Mode

# WRONG — hangs in CI
claude "Analyse this pull request for security issues"

# CORRECT
claude -p "Analyse this pull request for security issues"

Key Concept: For CLI calls in CI, use claude -p. Logs showing Claude waiting for input mean the flag is missing.

Structured Output for CI

claude -p \
  --output-format json \
  --json-schema '{"type":"object","properties":{"findings":{"type":"array",...}}}' \
  "Review this PR for security issues"

Extract with jq '.structured_output'.

Session Context Isolation

Generate code in one session; review in a separate independent session. A review in the same session is biased by the reasoning that produced the code.

Incremental Review Context

Include prior findings and ask for only new or still-unaddressed issues. Prevents duplicate comments that erode trust.

CLAUDE.md for CI Context

CI reads project CLAUDE.md the same way interactive sessions do. Use it for testing standards, fixtures, review criteria, coverage targets.

Key CLI Flags for Headless Runs

Flag	Effect
-p / --print	Non-interactive
--output-format json	Machine-parseable envelope
--json-schema	Schema-validated structured output
--append-system-prompt	Add rules without replacing default prompt
--allowedTools	Tools that run without permission prompt
--max-turns	Cap agentic turns
--bare	Skip auto-discovery of hooks, skills, MCP, CLAUDE.md

GitHub Actions

anthropics/claude-code-action@v1 runs Claude Code non-interactively. Pass CLI flags via claude_args. With a prompt it runs in automation mode; without, it waits for @claude mentions.

Exam Traps

• Running without -p in CI (hangs)
• Reviewing generated code in the same session that produced it
• Re-reporting all previous findings on every push
• Putting secrets as literals in workflow files

Practice Scenario / Build Exercise

Configure a CI review job with -p, structured JSON output, session isolation, and incremental context.