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

3.1 CLAUDE.md hierarchy, scoping, modular organization

Knowledge:
- Hierarchy: user-level (~/.claude/CLAUDE.md), project-level (.claude/CLAUDE.md or root CLAUDE.md), directory-level (subdirectory CLAUDE.md)
- User-level settings apply only to that user — not shared via version control to teammates
- @import syntax to reference external files, keeping CLAUDE.md modular
- .claude/rules/ directory as alternative to a monolithic CLAUDE.md, for topic-specific rule files

Skills:
- Diagnose hierarchy issues: new team member missing instructions because they're in user-level config, not project-level — Sample Q pattern
- @import to selectively include relevant standards files per package (maintainer domain knowledge)
- Split large CLAUDE.md into .claude/rules/testing.md, api-conventions.md, deployment.md, etc.
- /memory command to verify which memory files are loaded / diagnose inconsistent behavior across sessions

3.2 Custom slash commands and skills

Knowledge:
- Project-scoped commands: .claude/commands/ (shared via VCS) vs. user-scoped: ~/.claude/commands/ (personal)
- Skills live in .claude/skills/ with SKILL.md supporting frontmatter: context: fork, allowed-tools, argument-hint
- context: fork runs the skill in an isolated sub-agent context — prevents polluting the main conversation
- Personal skill variants in ~/.claude/skills/ with different names to avoid affecting teammates

Skills:
- Project-scoped commands in .claude/commands/ for team-wide availability via VCS — Sample Q4's answer
- context: fork to isolate verbose/exploratory skill output (codebase analysis, brainstorming) from main session
- allowed-tools in skill frontmatter to restrict tool access (e.g., limit to file-write only, to prevent destructive actions)
- argument-hint to prompt for required params when a skill is invoked without arguments
- Skills (on-demand, task-specific) vs. CLAUDE.md (always-loaded universal standards) — know when to use which

3.3 Path-specific rules for conditional convention loading

Knowledge:
- .claude/rules/ files use YAML frontmatter paths: field with glob patterns for conditional activation
- Path-scoped rules load only when editing matching files → less irrelevant context/tokens
- Glob-pattern rules > directory-level CLAUDE.md for conventions spanning multiple directories (e.g., test files scattered everywhere)

Skills:
- Create .claude/rules/ files with paths: ["terraform/**/*"]-style scoping
- Use glob patterns to apply conventions by file type regardless of directory (**/*.test.tsx)
- Choose path-specific rules over subdirectory CLAUDE.md when conventions cut across the codebase — Sample Q6's answer

3.4 Plan mode vs. direct execution

Knowledge:
- Plan mode: complex tasks — large-scale changes, multiple valid approaches, architectural decisions, multi-file mods
- Direct execution: simple, well-scoped changes (single validation check in one function)
- Plan mode enables safe exploration/design before committing, avoiding costly rework
- Explore subagent: isolates verbose discovery output, returns summaries to preserve main context

Skills:
- Plan mode for: microservice restructuring, library migrations touching 45+ files, choosing between infra approaches — Sample Q5's answer
- Direct execution for: single-file bug fix with clear stack trace, adding a date-validation conditional
- Explore subagent during verbose discovery phases to avoid context exhaustion
- Combine: plan mode to investigate, direct execution to implement the planned approach

3.5 Iterative refinement techniques

Knowledge:
- Concrete input/output examples > prose when descriptions get interpreted inconsistently
- Test-driven iteration: write tests first, iterate by sharing failures
- Interview pattern: have Claude ask clarifying questions before implementing, to surface unanticipated considerations
- Single message with ALL issues when they interact; sequential fixes when issues are independent

Skills:
- 2-3 concrete I/O examples to fix inconsistent transformation results
- Write test suites (behavior, edge cases, perf) before implementation; iterate on failures
- Interview pattern to surface design considerations (cache invalidation, failure modes) in unfamiliar domains
- Specific test cases w/ example input/expected output to fix edge cases (e.g., null handling in migrations)
- Bundle interacting issues into one detailed message; iterate sequentially for independent ones

3.6 Integrating Claude Code into CI/CD

Knowledge:
- -p / --print flag = non-interactive mode for pipelines (prevents hangs waiting on stdin) — Sample Q10's answer
- --output-format json + --json-schema for machine-parseable structured findings
- CLAUDE.md provides project context (testing standards, fixture conventions, review criteria) to CI-invoked runs
- Session context isolation: the same session that generated code is worse at reviewing its own changes vs. an independent instance

Skills:
- Run with -p to avoid interactive-input hangs
- --output-format json + --json-schema → machine-parseable output for auto-posting inline PR comments
- Include prior review findings in context on re-runs; instruct Claude to report only new/unaddressed issues (avoid duplicate comments)
- Provide existing test files in context so generation avoids duplicating covered scenarios
- Document testing standards/criteria/fixtures in CLAUDE.md to improve generation quality, reduce low-value tests

Discussion Prompts / Things to Drill