Domains D3

Claude Code Configuration & Workflows

D3 is 20% of CCAR-F — about 12 of the 60 items — across 6 published task statements, roughly 2 items per statement.

Weight
20%
Expected items
12/60
Task statements
6
Scenarios reaching it
3/6
Named anti-patterns
0
Items in bank
26

Scenarios that reach D3

3 of the 6 published scenarios name D3 as a primary domain, and any exam presents 4 of the 6.

  • S2 Code Generation with Claude Code

    Claude Code for generation, refactoring, debugging, and documentation, integrated into the development workflow with custom slash commands and CLAUDE.md configuration, including when to use plan mode versus direct execution.

    D3 — this domain D5 spans 35% of the blueprint
  • S4 Developer Productivity with Claude

    An Agent SDK productivity agent helping engineers explore unfamiliar codebases, understand legacy systems, generate boilerplate, and automate repetitive tasks, using the built-in tools (Read, Write, Bash, Grep, Glob) and integrating MCP servers.

    D1 D2 D3 — this domain spans 65% of the blueprint
  • S5 Claude Code for Continuous Integration

    Claude Code inside a CI/CD pipeline running automated code reviews, generating test cases, and providing pull-request feedback, with prompts designed to be actionable and to minimize false positives.

    D3 — this domain D4 spans 40% of the blueprint

All 6 scenarios →

All 6 task statements

  1. 3.1

    Configure CLAUDE.md files with appropriate hierarchy, scoping, and modular organization

    4 items

    What the guide expects you to know

    • The CLAUDE.md configuration hierarchy: user-level (~/.claude/CLAUDE.md), project-level (.claude/CLAUDE.md or root CLAUDE.md), and directory-level (subdirectory CLAUDE.md files)
    • That user-level settings apply only to that user—instructions in ~/.claude/CLAUDE.md are not shared with teammates via version control
    • The @import syntax for referencing external files to keep CLAUDE.md modular (e.g., importing specific standards files relevant to each package)
    • .claude/rules/ directory for organizing topic-specific rule files as an alternative to a monolithic CLAUDE.md
    • Diagnosing configuration hierarchy issues (e.g., a new team member not receiving instructions because they're in user-level rather than project-level configuration)
    • Using @import to selectively include relevant standards files in each package's CLAUDE.md based on maintainer domain knowledge
    • Splitting large CLAUDE.md files into focused topic-specific files in .claude/rules/ (e.g., testing.md, api-conventions.md, deployment.md) Claude Certification Program Exam guide
    • Using the /memory command to verify which memory files are loaded and diagnose inconsistent behavior across sessions
  2. 3.2

    Create and configure custom slash commands and skills

    4 items

    What the guide expects you to know

    • Project-scoped commands in .claude/commands/ (shared via version control) vs user-scoped commands in ~/.claude/commands/ (personal)
    • Skills in .claude/skills/ with SKILL.md files that support frontmatter configuration including context: fork, allowed-tools, and argument-hint
    • The context: fork frontmatter option for running skills in an isolated sub-agent context, preventing skill outputs from polluting the main conversation
    • Personal skill customization: creating personal variants in ~/.claude/skills/ with different names to avoid affecting teammates
    • Creating project-scoped slash commands in .claude/commands/ for team-wide availability via version control
    • Using context: fork to isolate skills that produce verbose output (e.g., codebase analysis) or exploratory context (e.g., brainstorming alternatives) from the main session
    • Configuring allowed-tools in skill frontmatter to restrict tool access during skill execution (e.g., limiting to file write operations to prevent destructive actions)
    • Using argument-hint frontmatter to prompt developers for required parameters when they invoke the skill without arguments
    • Choosing between skills (on-demand invocation for task-specific workflows) and CLAUDE.md (always-loaded universal standards)
  3. 3.3

    Apply path-specific rules for conditional convention loading

    4 items

    What the guide expects you to know

    • .claude/rules/ files with YAML frontmatter paths fields containing glob patterns for conditional rule activation
    • How path-scoped rules load only when editing matching files, reducing irrelevant context and token usage
    • The advantage of glob-pattern rules over directory-level CLAUDE.md files for conventions that span multiple directories (e.g., test files spread throughout a codebase) Claude Certification Program Exam guide
    • Creating .claude/rules/ files with YAML frontmatter path scoping (e.g., paths: ["terraform/**/*"]) so rules load only when editing matching files
    • Using glob patterns in path-specific rules to apply conventions to files by type regardless of directory location (e.g., **/*.test.tsx for all test files)
    • Choosing path-specific rules over subdirectory CLAUDE.md files when conventions must apply to files spread across the codebase
  4. 3.4

    Determine when to use plan mode vs direct execution

    4 items

    What the guide expects you to know

    • Plan mode is designed for complex tasks involving large-scale changes, multiple valid approaches, architectural decisions, and multi-file modifications
    • Direct execution is appropriate for simple, well-scoped changes (e.g., adding a single validation check to one function)
    • Plan mode enables safe codebase exploration and design before committing to changes, preventing costly rework
    • The Explore subagent for isolating verbose discovery output and returning summaries to preserve main conversation context
    • Selecting plan mode for tasks with architectural implications (e.g., microservice restructuring, library migrations affecting 45+ files, choosing between integration approaches with different infrastructure requirements)
    • Selecting direct execution for well-understood changes with clear scope (e.g., a single-file bug fix with a clear stack trace, adding a date validation conditional)
    • Using the Explore subagent for verbose discovery phases to prevent context window exhaustion during multi-phase tasks
    • Combining plan mode for investigation with direct execution for implementation (e.g., planning a library migration, then executing the planned approach)
  5. 3.5

    Apply iterative refinement techniques for progressive improvement

    5 items

    What the guide expects you to know

    • Concrete input/output examples as the most effective way to communicate expected transformations when prose descriptions are interpreted inconsistently Claude Certification Program Exam guide
    • Test-driven iteration: writing test suites first, then iterating by sharing test failures to guide progressive improvement
    • The interview pattern: having Claude ask questions to surface considerations the developer may not have anticipated before implementing
    • When to provide all issues in a single message (interacting problems) versus fixing them sequentially (independent problems)
    • Providing 2-3 concrete input/output examples to clarify transformation requirements when natural language descriptions produce inconsistent results
    • Writing test suites covering expected behavior, edge cases, and performance requirements before implementation, then iterating by sharing test failures
    • Using the interview pattern to surface design considerations (e.g., cache invalidation strategies, failure modes) before implementing solutions in unfamiliar domains
    • Providing specific test cases with example input and expected output to fix edge case handling (e.g., null values in migration scripts)
    • Addressing multiple interacting issues in a single detailed message when fixes interact, versus sequential iteration for independent issues
  6. 3.6

    Integrate Claude Code into CI/CD pipelines

    5 items

    What the guide expects you to know

    • The -p (or --print) flag for running Claude Code in non-interactive mode in automated pipelines
    • --output-format json and --json-schema CLI flags for enforcing structured output in CI contexts
    • CLAUDE.md as the mechanism for providing project context (testing standards, fixture conventions, review criteria) to CI-invoked Claude Code
    • Session context isolation: why the same Claude session that generated code is less effective at reviewing its own changes compared to an independent review instance
    • Running Claude Code in CI with the -p flag to prevent interactive input hangs
    • Using --output-format json with --json-schema to produce machine-parseable structured findings for automated posting as inline PR comments
    • Including prior review findings in context when re-running reviews after new commits, instructing Claude to report only new or still-unaddressed issues to avoid duplicate comments
    • Providing existing test files in context so test generation avoids suggesting duplicate scenarios already covered by the test suite Claude Certification Program Exam guide
    • Documenting testing standards, valuable test criteria, and available fixtures in CLAUDE.md to improve test generation quality and reduce low-value test output