20% of exam score
Claude Code Configuration & Workflows
Configuration-heavy. Know where files go.
Claude Code architecture, CLAUDE.md hierarchy, .claudeignore, skills, slash commands, subagents, hooks, and CI/CD integration.
Key insight
The CLAUDE.md hierarchy separates people who USE Claude Code from people who have CONFIGURED it for a team. User-level config lives only on your machine — new team members won't see it. Team standards belong in project-level config, checked into git.
The exam rewards
- Three config levels: user (~/.claude/CLAUDE.md, personal, not shared), project (./CLAUDE.md, version-controlled, shared via git), directory (subdirectory files, path-specific)
- Path-specific rules in .claude/rules/ with YAML glob frontmatter apply across the whole codebase — unlike directory-level CLAUDE.md which is location-bound
- Use plan mode for multi-file migrations, architectural decisions, or any task where the correct approach needs exploring before committing; use direct execution for clear single-file tasks
- The -p flag is mandatory for non-interactive CI/CD pipelines — without it, the pipeline job hangs waiting for input
- Skills with 'context: fork' run in isolated subagent context, keeping verbose output out of the main conversation
Common anti-patterns
- Putting team standards in user-level CLAUDE.md — new team members won't receive them
- Using directory-level CLAUDE.md when a rule needs to span many directories (use .claude/rules/ instead)
- Running Claude Code in CI without the -p flag
- Putting task-specific procedures in CLAUDE.md, or universal standards in skills