Claude Code Configuration & Workflows

20% of exam

Configure CLAUDE.md hierarchies, create custom skills and commands, apply path-specific rules, choose plan mode vs direct execution, use iterative refinement, and integrate Claude Code into CI/CD.

6

task statements

10

concepts

36

practice questions

Domain Mastery

0%
See full Exam Guide
ts-3.1

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

CLAUDE.md configuration hierarchy, scoping levels, @import modularity, and .claude/rules/ organization.

Knowledge of

  • 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

Skills in

  • 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)
  • Using the /memory command to verify which memory files are loaded and diagnose inconsistent behavior across sessions

Concepts

ts-3.2

Create and configure custom slash commands and skills

Project-scoped commands, skill frontmatter configuration, context isolation, and personal customization.

Knowledge of

  • 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

Skills in

  • 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)

Concepts

ts-3.3

Apply path-specific rules for conditional convention loading

Glob-pattern rules in .claude/rules/ for conditional, file-type-specific convention loading.

Knowledge of

  • .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)

Skills in

  • 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

Concepts

ts-3.4

Determine when to use plan mode vs direct execution

Choosing between plan mode for exploration and direct execution for well-scoped changes.

Knowledge of

  • 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

Skills in

  • 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)

Concepts

ts-3.5

Apply iterative refinement techniques for progressive improvement

Using concrete examples, test-driven iteration, interview patterns, and batched feedback for progressive improvement.

Knowledge of

  • Concrete input/output examples as the most effective way to communicate expected transformations when prose descriptions are interpreted inconsistently
  • 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)

Skills in

  • 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

Concepts

ts-3.6

Integrate Claude Code into CI/CD pipelines

Non-interactive mode, structured output, session isolation, and CI-specific CLAUDE.md context.

Knowledge of

  • 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

Skills in

  • 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
  • Documenting testing standards, valuable test criteria, and available fixtures in CLAUDE.md to improve test generation quality and reduce low-value test output

Concepts