This domain separates people who use Claude Code from people who have configured it for a team. It is the most configuration-heavy domain. You either know where the files go and what the options do, or you do not.
01 The CLAUDE.md Hierarchy
Three levels, each with different scope and visibility:
| Level | Location | Applies To | Version Controlled | Shared With Team |
|---|---|---|---|---|
| User-level | ~/.claude/CLAUDE.md | Only you | No | No |
| Project-level | .claude/CLAUDE.md or root CLAUDE.md | Everyone on the project | Yes | Yes |
| Directory-level | Subdirectory CLAUDE.md files | Files in that directory | Yes | Yes |
The Exam's Favourite Trap
A new team member is not receiving instructions. Developer A's Claude Code follows API naming conventions perfectly. Developer B (who joined last week) gets inconsistent naming.
Root cause: the instructions are in Developer A's user-level config (~/.claude/CLAUDE.md), not project-level config. User-level config is not version-controlled and not shared via git. New team members cloning the repo do NOT get these instructions.
Fix: move team-wide standards to project-level config (.claude/CLAUDE.md).
Modular Organisation
@importsyntax to reference external files from CLAUDE.md (import relevant standards per package).claude/rules/directory for topic-specific rule files (testing.md,api-conventions.md,deployment.md) as an alternative to one massive file
Use /memory command to verify which memory files are loaded. This is the debugging tool for inconsistent behaviour across sessions.
02 Custom Slash Commands and Skills
Directory Structure
| Location | Scope | Shared |
|---|---|---|
.claude/commands/ | Project-scoped | Yes (version controlled) |
~/.claude/commands/ | Personal | No |
.claude/skills/ with SKILL.md files | On-demand invocation | Yes |
Skill Frontmatter Options
---
context: fork # Runs in isolated sub-agent context
allowed-tools: # Restricts available tools
- Read
- Grep
argument-hint: "Provide the file path to review"
---context: fork— runs in isolated sub-agent context. Verbose output stays contained. Main conversation stays clean. Use for codebase analysis, brainstorming, anything noisy.allowed-tools— prevents destructive actions during skill execution.argument-hint— prompts the developer for required parameters when invoked without arguments.
The Key Distinction
| Type | Purpose | When It Loads |
|---|---|---|
| Skills | On-demand, task-specific workflows | Invoked when needed |
| CLAUDE.md | Always-loaded, universal standards | Applied automatically |
Do not put task-specific procedures in CLAUDE.md. Do not put universal standards in skills.
Personal Skill Customisation
Create personal variants in ~/.claude/skills/ with different names. Avoids affecting teammates while allowing personal workflow customisation.
03 Path-Specific Rules
The .claude/rules/ directory supports files with YAML frontmatter:
---
paths: ["**/*.test.tsx"]
---
All test files must use the `describe/it` pattern.
Mock external services, never databases.
Each test file must have at least one integration test.Rules only load when editing files matching the glob pattern.
Why This Beats Directory-Level CLAUDE.md
| Feature | Path-Specific Rules | Directory-Level CLAUDE.md |
|---|---|---|
| Pattern matching | Glob patterns across entire codebase | Only files in that one directory |
| Test conventions across 50+ directories | Single rule file with **/*.test.tsx | Would need CLAUDE.md in every directory |
| Token efficiency | Loads only when editing matching files | Always loaded for that directory |
Practice Scenario
A codebase has test files co-located with source files throughout 50+ directories. The team wants all tests to follow the same conventions. Answer: path-specific rules with glob patterns. Not CLAUDE.md in every directory. Not a single root CLAUDE.md (wastes tokens on non-test files). Not skills (wrong mechanism for always-on standards).
04 Plan Mode vs Direct Execution
The Decision Framework
Use plan mode when:
- Complex tasks involving large-scale changes
- Multiple valid approaches exist
- Architectural decisions required
- Multi-file modifications (e.g., library migration across 45+ files)
- Need to explore before changing
Use direct execution when:
- Well-understood changes with clear, limited scope
- Single-file bug fix with clear stack trace
- Adding a date validation conditional
- The correct approach is already known
The Explore Subagent
Isolates verbose discovery output from the main conversation. Returns summaries to preserve main conversation context. Use during multi-phase tasks to prevent context window exhaustion.
The Combination Pattern
- Plan mode for investigation and design
- Direct execution for implementing the planned approach
This hybrid is common in practice and tested on the exam.
Practice Scenario
Classify each task:
| Task | Mode | Reasoning |
|---|---|---|
| Restructure a monolith into microservices | Plan mode | Complex, multiple valid approaches |
| Fix a null pointer exception in a single function | Direct execution | Clear scope, known approach |
| Migrate logging library across 30 files | Plan mode | Multi-file, need to assess impact first |
05 Iterative Refinement
Technique Hierarchy (Most Effective First)
- Concrete input/output examples (2-3 examples showing before/after) — beat prose descriptions every time
- Test-driven iteration — write tests first, share failures to guide improvement
- Interview pattern — have Claude ask questions before implementing (surfaces considerations you would miss)
Batch vs Sequence Feedback
| Approach | When to Use |
|---|---|
| Single message (batch) | Fixes interact with each other — changing one affects others |
| Sequential iteration | Issues are independent — fixing one does not affect others |
Practice Scenario
A developer describes a code transformation in prose. Claude Code interprets it differently each time. Fix: switch to concrete input/output examples. Show 2-3 examples of the expected transformation. The model generalises from examples more reliably than from descriptions.
06 CI/CD Integration
The -p Flag
Runs Claude Code in non-interactive mode (print mode). Without it, the CI job hangs waiting for interactive input.
# Wrong — hangs indefinitely
claude "Analyse this PR"
# Correct — runs non-interactively
claude -p "Analyse this PR"This is tested directly on the exam. Memorise it.
Structured CI Output
claude -p --output-format json --json-schema schema.json "Review this PR"Produces machine-parseable structured findings. Automated systems can post findings as inline PR comments.
Session Context Isolation
The same Claude session that generated code is less effective at reviewing its own changes. It retains reasoning context that makes it less likely to question its decisions. Use an independent review instance for code review.
Incremental Review Context
When re-running reviews after new commits:
- Include prior review findings in context
- Instruct Claude to report ONLY new or still-unaddressed issues
- Prevents duplicate comments that erode developer trust
CLAUDE.md for CI
Document testing standards, valuable test criteria, and available fixtures. CI-invoked Claude Code uses this to generate high-quality tests. Without it, test generation produces low-value boilerplate.
07 What to Build
Set up a project with:
- CLAUDE.md hierarchy (project-level + directory-level)
.claude/rules/with glob patterns for test files and API files- A custom skill with
context: fork - An MCP server in
.mcp.jsonwith environment variable expansion - A CI script using
-pflag with JSON output
Test plan mode on a multi-file refactor and direct execution on a single bug fix. Experience the difference.