Claude Code Configuration & Workflows

3.1 CLAUDE.md hierarchy: project vs user

Claude Code reads project context from a file named CLAUDE.md, and it exists at two levels that the exam expects you to tell apart on sight:

Both files load into the same Claude Code session and their content is simply concatenated into context — there is no override semantics to memorise, just "shared team standard" goes in the repo, "my personal preference" goes in the home directory. CLAUDE.md also supports an @path/to/file import syntax, letting a short CLAUDE.md pull in longer reference documents without bloating the file itself:

# CLAUDE.md (repo root)

## Commands
- Build: npm run build
- Test: npm test
- Lint: npm run lint

## Architecture
See @docs/architecture.md for the service boundaries and data flow.
Never edit generated files under src/generated/.

## Style
Prefer named exports. Match existing test structure in fixtures/.

3.2 .claude/rules/ — path-scoped instructions

CLAUDE.md is blanket context — it loads into every session regardless of what Claude happens to be touching. When an instruction only matters for a subset of files, a blanket instruction is noise the rest of the time. .claude/rules/ solves this: each rule is a Markdown file with YAML frontmatter specifying a paths field (glob patterns, e.g. src/api/**/*.ts), and the instruction body only loads into context when Claude is working with a matching file. A rule with no paths field loads unconditionally, same as CLAUDE.md.

# .claude/rules/test-fixtures.md
---
paths:
  - "**/*.test.ts"
---
When editing or adding test files, always reuse the existing helpers in
fixtures/ (buildUser, buildOrder, mockClock) instead of constructing test
data inline. If a fixture you need doesn't exist yet, add it to
fixtures/ rather than duplicating setup logic in the test file.

This rule is invisible to Claude while it is editing src/api/orders.ts, and loads automatically the moment Claude opens or edits anything matching **/*.test.ts. That precision is the entire value proposition over a CLAUDE.md instruction: scope the instruction to where it is relevant, not to every session.

3.3 Skills and slash commands

Two related but distinct customization mechanisms live under .claude/, and the exam tests telling them apart:

Slash commands — .claude/commands/*.md

A custom slash command is a Markdown file under .claude/commands/, invoked explicitly by name as /command-name. It can take arguments via $ARGUMENTS, making it a reusable, parameterised prompt template a developer triggers on demand — nothing loads unless someone types the command.

# .claude/commands/fix-issue.md
Fetch GitHub issue $ARGUMENTS, understand the bug it describes, locate
the relevant code, and propose a fix. Do not open a PR — stop after
presenting the diff for review.

Agent Skills — packaged instructions Claude loads when relevant

A Skill is not manually invoked by name — Claude decides to load it when its description matches what the current task needs. Skill frontmatter carries three fields the exam likes to test against each other, because two of them sound like the same thing and are not: context: fork runs the skill in an isolated context (the same context-isolation idea as subagents in Domain 1, applied to a skill); allowed-tools pre-approves the listed tools so Claude can call them during that turn without a permission prompt — it does not restrict anything else, every other tool the session is permitted to use remains callable, just with its normal prompt; disallowed-toolsis the field that actually removes tools from the skill's available pool while it is active — that is the real restriction mechanism.

# .claude/skills/dependency-audit/SKILL.md
---
name: dependency-audit
description: Reviews dependency-update PRs for supply-chain risk —
  new transitive deps, license changes, suspicious postinstall scripts.
  Use when a PR modifies package.json or a lockfile.
context: fork
disallowed-tools: Bash, Write, Edit
---
Examine the diff to package.json and the lockfile. Flag new
dependencies, license changes, and any postinstall/prepare script
additions. You have no write access — report findings only.

disallowed-toolsis the real, declarative security boundary — it ties directly back to Domain 1's anti-pattern #6 (unrestricted tool access): a skill built to review code has no business holding Bash or Write, regardless of what the parent session is permitted to do. allowed-tools solves a different problem entirely (skipping approval friction for tools you already trust the skill to use) and confusing the two is a genuine, exam-tested trap.

3.4 Plan mode vs direct execution

Claude Code can work two ways: plan mode, where Claude proposes an approach and gets it explicitly approved before touching any files, or direct execution, where it goes straight to editing. Neither is universally correct — the exam rewards matching the mode to the task's blast radius and ambiguity.

3.5 Headless mode for CI/CD

Claude Code can run without any interactive terminal session at all, using the -p (print) flag. This is what makes it usable inside CI/CD: a pipeline step invokes Claude, Claude does its work and prints a result, and the process exits — no prompt is ever waiting on a human.

claude -p "review this diff for security issues" --output-format json

Paired with --output-format json (or stream-json for incremental output), the result comes back as a structured envelope instead of free-text stdout — conceptually containing the result text Claude produced, cost information for the run, and a session id identifying that invocation. A CI script parses this envelope directly; it never needs to regex-scrape a paragraph of prose looking for a verdict.

Session isolationmatters just as much as the flags: each CI invocation — each PR, each run — should start a fresh session in its own working directory. Reusing one long-lived session across multiple PRs risks one PR's diff, findings, or conversation history leaking into another's review.

3.6 Choosing the right invocation shape for CI

Put 3.5 together into the exam's favourite synthesis question: given a requirement like "review PRs and post structured findings a bot can parse," the correct combination is always the same shape:

• Headless -p — never interactive mode on a CI runner.
• --output-format json (or stream-json) — never the default free-text output parsed downstream with regular expressions.
• A fresh, isolated session per invocation — never one long-lived session shared across unrelated PRs.