Skip to content

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

3.1 Configuring CLAUDE.md with Hierarchy, Scope, and Modular Organization

Key knowledge:

  • CLAUDE.md hierarchy: user (~/.claude/CLAUDE.md), project (.claude/CLAUDE.md or root CLAUDE.md), and directory-level (CLAUDE.md in subdirectories)
  • User-level settings apply only to one user and are not shared via VCS
  • @path syntax for referencing external files (e.g., @./standards/coding-style.md) to modularize CLAUDE.md
  • The .claude/rules/ directory for topic-focused rule files instead of a monolithic CLAUDE.md

Key skills:

  • Diagnose hierarchy issues (a new team member misses instructions because they are user-level instead of project-level)
  • Use @path (e.g., @./standards/testing.md) to selectively include standards in each package’s CLAUDE.md
  • Split large CLAUDE.md into multiple .claude/rules/ files (testing.md, api-conventions.md, deployment.md)

3.2 Creating and Configuring Custom Slash Commands and Skills

Key knowledge:

  • Project commands in .claude/commands/ (shared via VCS) vs user commands in ~/.claude/commands/
  • Skills in .claude/skills/ with SKILL.md frontmatter: context: fork, allowed-tools, argument-hint
  • context: fork runs the skill in an isolated subagent context so it does not pollute the main session
  • Personal skill variants can live in ~/.claude/skills/ under different names

Key skills:

  • Store project slash commands in .claude/commands/ so the whole team gets them
  • Use context: fork to isolate skills with verbose output
  • Use allowed-tools to restrict what tools a skill can use
  • Use argument-hint to prompt developers for required parameters

3.3 Using Path-specific Rules for Conditional Convention Loading

Key knowledge:

  • .claude/rules/ files can include YAML frontmatter paths to activate rules based on glob patterns
  • Path-scoped rules load only when editing matching files, saving context and tokens
  • Glob-based path rules can be preferable to directory-level CLAUDE.md when conventions apply across many directories (e.g., tests)

Key skills:

  • Create .claude/rules/ files with paths: ["terraform/**/*"] to load only when working on matching files
  • Use glob patterns (**/*.test.tsx) to apply conventions by file type regardless of location
  • Prefer path-specific rules over directory-level CLAUDE.md when conventions span the codebase

3.4 Deciding When to Use Planning Mode vs Direct Execution

Key knowledge:

  • Planning mode: for complex tasks with large changes, multiple viable approaches, and architectural decisions
  • Direct execution: for simple, well-understood changes (e.g., adding a single validation)
  • Planning mode enables safe exploration of the codebase before making changes
  • Explore subagent isolates verbose discovery output

Key skills:

  • Use planning mode for tasks with architectural consequences (microservices, migrations touching 45+ files)
  • Use direct execution for fixes with a clear stack trace and a single file
  • Use Explore subagent to prevent context-window exhaustion in multi-phase tasks
  • Combine approaches: plan for discovery, then execute for implementation

3.5 Iterative Refinement for Progressive Improvement

Key knowledge:

  • Concrete input/output examples are the most effective way to communicate expectations
  • Test-driven iteration: write tests first, then iterate based on failures
  • The “interview” pattern: Claude asks questions to surface non-obvious design considerations
  • When to provide all issues in one message (interdependent) vs sequentially (independent)

Key skills:

  • Provide 2–3 concrete input/output examples to clarify transformation requirements
  • Build test sets with expected behavior, edge cases, and performance requirements before implementation
  • Use the interview pattern to surface design aspects (cache invalidation, failure modes)
  • Provide concrete test cases with sample inputs and expected outputs for edge cases

3.6 Integrating Claude Code into CI/CD Pipelines

Key knowledge:

  • The -p (or --print) flag for non-interactive mode in automated pipelines
  • --output-format json and --json-schema for structured output in CI
  • CLAUDE.md provides project context (testing standards, review criteria) for CI-triggered Claude Code
  • Session context isolation: the same session that generated code is less effective at reviewing it than an independent instance

Key skills:

  • Run Claude Code in CI with -p to avoid hanging on interactive input
  • Use --output-format json + --json-schema for structured results (e.g., inline PR comments)
  • Include prior review results when re-running after new commits (report only new/unfixed issues)
  • Document testing standards and available fixtures in CLAUDE.md to improve test generation quality
  • Include existing test files in context when generating new tests to avoid duplication and keep style consistent