How to Become a Claude Architect
Chapter 4 / 77 min read

Part 4: Claude Code Configuration & Workflows

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:

LevelLocationApplies ToVersion ControlledShared With Team
User-level~/.claude/CLAUDE.mdOnly youNoNo
Project-level.claude/CLAUDE.md or root CLAUDE.mdEveryone on the projectYesYes
Directory-levelSubdirectory CLAUDE.md filesFiles in that directoryYesYes

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

  • @import syntax 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

LocationScopeShared
.claude/commands/Project-scopedYes (version controlled)
~/.claude/commands/PersonalNo
.claude/skills/ with SKILL.md filesOn-demand invocationYes

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

TypePurposeWhen It Loads
SkillsOn-demand, task-specific workflowsInvoked when needed
CLAUDE.mdAlways-loaded, universal standardsApplied 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

FeaturePath-Specific RulesDirectory-Level CLAUDE.md
Pattern matchingGlob patterns across entire codebaseOnly files in that one directory
Test conventions across 50+ directoriesSingle rule file with **/*.test.tsxWould need CLAUDE.md in every directory
Token efficiencyLoads only when editing matching filesAlways 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

  1. Plan mode for investigation and design
  2. Direct execution for implementing the planned approach

This hybrid is common in practice and tested on the exam.

Practice Scenario

Classify each task:

TaskModeReasoning
Restructure a monolith into microservicesPlan modeComplex, multiple valid approaches
Fix a null pointer exception in a single functionDirect executionClear scope, known approach
Migrate logging library across 30 filesPlan modeMulti-file, need to assess impact first

05 Iterative Refinement

Technique Hierarchy (Most Effective First)

  1. Concrete input/output examples (2-3 examples showing before/after) — beat prose descriptions every time
  2. Test-driven iteration — write tests first, share failures to guide improvement
  3. Interview pattern — have Claude ask questions before implementing (surfaces considerations you would miss)

Batch vs Sequence Feedback

ApproachWhen to Use
Single message (batch)Fixes interact with each other — changing one affects others
Sequential iterationIssues 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.json with environment variable expansion
  • A CI script using -p flag with JSON output

Test plan mode on a multi-file refactor and direct execution on a single bug fix. Experience the difference.