Claude Code Configuration & Workflows (20%)

What the exam tests: whether you put instructions, commands, skills and rules in the right file at the right scope, choose plan mode or direct execution sensibly, iterate with examples and tests, and run Claude Code unattended in CI. About 12 of 60 items, many of them "where does this file go?" questions.

4.1 CLAUDE.md hierarchy (Task 3.1)

CLAUDE.md is the always-loaded instruction file. It exists at three levels:

Figure 5. The three CLAUDE.md levels and who sees them

Level Location Shared with the team?

User ~/.claude/CLAUDE.md No. Only on your machine

Project CLAUDE.md at the repo root, or .claude/CLAUDE.md Yes, through version control Directory CLAUDE.md inside a subdirectory Yes; applies when working in that directory The classic exam diagnosis: a new team member is not getting the team's conventions because they were written in someone's user-level file. Move them to the project file. Keep CLAUDE.md modular:

@import pulls another file in, so each package's CLAUDE.md can include only the standards that apply to it, for example @docs/standards/api.md.

• 1. User ~/.claude/CLAUDE.md: only on your machine, not shared
• 2. Project

repo root CLAUDE.md or .claude/CLAUDE.md: shared through

version control

• 3. Directory

CLAUDE.md in a subdirectory: shared; applies when working

there

More specific

.claude/rules/ holds topic files such as testing.md, api-conventions.md and deployment.md instead of one huge CLAUDE.md.

/memory shows which memory files are loaded. Use it when behaviour differs between sessions or people.

4.2 Slash commands and skills (Task 3.2)

Thing Project scope (shared) User scope (personal)

Slash commands .claude/commands/ ~/.claude/commands/

Skills .claude/skills/<name>/SKILL.md ~/.claude/skills/<name>/SKILL.md A team /review command belongs in .claude/commands/ in the repo, so everyone gets it on clone or pull. There is no commands array in a config file; that is a distractor in the official sample.

Skills carry YAML frontmatter. Three fields are named in the guide:

---

name: codebase-audit

description: Map a service's modules and dependencies and report hotspots.

• context: fork
• allowed-tools: Read, Grep, Glob
• argument-hint: <service-directory>
• ---

Steps and conventions for the audit go here.

context: fork runs the skill in an isolated subagent context and returns only its result, so verbose analysis or brainstorming does not flood the main conversation.

allowed-tools limits what the skill may use, for example read-only tools for an audit. argument-hint tells the developer what argument to supply when they invoke the skill without one.

To customise a team skill for yourself, copy it to ~/.claude/skills/ under a different name so teammates are unaffected. Choose CLAUDE.md for universal, always-on standards and a skill for task-specific workflows invoked on demand.

4.3 Path-specific rules (Task 3.3)

A rule file in .claude/rules/ can declare paths in its frontmatter. It then loads only when Claude works on matching files, which saves context and keeps irrelevant rules out. ---

paths: ["**/*.test.tsx", "**/*.test.ts"]

---

Tests use React Testing Library, never Enzyme. One behaviour per test.

This beats a subdirectory CLAUDE.md whenever the files are scattered: test files living next to their components everywhere cannot be covered by one directory. In the official sample, globscoped rules win over one big CLAUDE.md (relies on inference), skills (need invoking), and perdirectory files (directory-bound).

4.4 Plan mode or direct execution (Task 3.4)

Use plan mode when Use direct execution when

The change spans many files (the guide cites 45+) The change is small and clearly scoped There are several valid approaches A single-file bug fix with a clear stack trace Architectural decisions are involved, such as service boundaries Adding one validation check or date conditional Rework would be costly if the approach is wrong The approach is obvious Plan mode lets Claude explore and design without changing anything. A common pattern is plan first, then switch to direct execution to implement the agreed plan. If the task statement already says the work is complex, do not pick "start directly and switch if it gets hard". The Explore subagent handles verbose discovery in its own context and returns a summary, protecting the main conversation from exhaustion during long, multi-phase tasks.

4.5 Iterative refinement (Task 3.5)

• Technique Use when
• 2 or 3 concrete input/output
• examples

Prose descriptions of a transformation are interpreted inconsistently Tests first, then share failures You can specify behaviour, edge cases and performance as tests Interview pattern The domain is unfamiliar; have Claude ask you questions (cache invalidation, failure modes) before it builds

Specific failing test cases One edge case is wrong, such as nulls in a migration script All issues in one message The problems interact, so fixing one changes another One issue at a time The problems are independent

4.6 Claude Code in CI/CD (Task 3.6)

claude -p "Review this PR for security issues. Report only new findings." \ --output-format json \

--json-schema "$(cat review-schema.json)"

-p / --print runs non-interactively: it prints the result and exits. Without it the job hangs waiting for input. CLAUDE_HEADLESS and --batch do not exist.

--output-format json with --json-schema produces findings a script can parse and post as inline PR comments.

CLAUDE CODE CONFIGURATION & WORKFLOWS (20%)

CLAUDE.md supplies CI context: testing standards, fixture conventions, what counts as a valuable test, review criteria.

Review with a fresh instance. The session that wrote the code keeps its reasoning and is less likely to question itself.

Re-runs after new commits: include the previous findings and ask only for new or still-unaddressed issues, to avoid duplicate comments. Test generation: include the existing tests so Claude does not propose cases already covered.

Worked examples

Worked example 4.A: The new hire who gets different answers

Situation. Priya joined last week. When she asks Claude Code to add an endpoint, it uses Express-style callbacks and Jest. Everyone else gets async/await handlers and Vitest. Investigation. Run /memory in both sessions. A senior engineer's session shows ~/.claude/ CLAUDE.md with 60 lines of team conventions. Priya's shows only the short root CLAUDE.md. Diagnosis. The conventions live at user level, which is personal and not in version control. Fix. Move team conventions into the project CLAUDE.md (or .claude/rules/ files) and commit them. Leave only genuinely personal preferences, such as "explain diffs briefly", in the user file.

Worked example 4.B: Breaking up a 1,800-line CLAUDE.md

Situation. A monorepo's root CLAUDE.md covers frontend, API, data pipelines, Terraform, testing and release. Claude follows some parts and misses others, and each session starts with a large context load.

Fix. Keep the root file short and universal; move the rest into focused files. CLAUDE.md # 40 lines: repo map, build commands, universal rules

.claude/rules/testing.md # paths: ["**/*.test.*", "**/*.spec.*"] .claude/rules/api.md # paths: ["services/api/**/*"]

• .claude/rules/terraform.md # paths: ["infra/**/*.tf"]
• .claude/rules/release.md # no paths: always loaded, short
• packages/web/CLAUDE.md # @../../docs/standards/react.md

Path-scoped rules load only when Claude touches matching files, so the Terraform rules do not occupy context during a React change. The package-level CLAUDE.md uses @import to pull in exactly the standards its maintainers chose.

Worked example 4.C: Command, skill or CLAUDE.md?

Need Put it in Why

"Always use pnpm" Project CLAUDE.md Universal, always relevant

A /review checklist anyone can run .claude/commands/review.md Shared, invoked on demand

• Need Put it in Why
• A multi-step "release notes" workflow with
• scripts and templates

.claude/skills/releasenotes/SKILL.mdTask-specific, bundled resources, loaded only when used

A noisy whole-repo dependency audit Skill with context: fork Keeps verbose output out of the main session

• A read-only security scan Skill with allowed-tools:
• Read, Grep, Glob
• Cannot modify files

Your personal variant of the team review ~/.claude/skills/reviewmine/Different name, does not affect teammates

API conventions for files under services/

api/

.claude/rules/api.md with paths

• Loads automatically for matching files
• Worked example 4.D: A forked, read-only audit skill
• ---
• name: dependency-audit

description: Audit a package's dependencies for outdated, duplicated or risky packages. Use when asked to review dependencies or before a major upgrade.

context: fork

allowed-tools: Read, Grep, Glob, Bash(npm ls:*), Bash(npm outdated:*)

argument-hint: <package-path>

---

• 1. Read package.json at the given path.
• 2. Run npm ls and npm outdated for that package.
• 3. Report: outdated majors, duplicate versions, packages with no release in 2 years.
• 4. Return a table and at most 5 recommendations. Do not edit files.

context: fork means the long npm ls output stays in the forked context and only the table returns. allowed-tools limits Bash to two read-only commands. argument-hint prompts for the package path if the developer runs the skill bare. (Bash patterns in allowed-tools follow Claude Code's permission rule syntax; check the current docs for exact forms.) Worked example 4.E: Plan mode decisions

Task Mode Reasoning

Fix TypeError at cart.ts:88, stack trace attached Direct One file, clear cause Add isValidDate check to the signup form Direct Small, well scoped Migrate from Moment.js to date-fns across 52 files Plan, then direct Many files, needs an approach and an order

• Choose between WebSockets and server-sent
• events for notifications
• Plan Competing designs with different in‐
• frastructure

Split the monolith's billing module into a service Plan Architecture and boundaries Understand an unfamiliar legacy module before

• changing it
• Plan, with the Explore
• subagent
• Discovery is verbose; keep the main
• context clean

A useful heuristic: if you would want to review a design document before a human colleague started, use plan mode.

CLAUDE CODE CONFIGURATION & WORKFLOWS (20%)

Worked example 4.F: Iterating to the right transformation

Situation. You ask Claude to convert log lines to JSON. Three runs give three different field names and timestamp formats.

Fix. Replace the paragraph with examples.

Input: 2026-10-12 14:03:22 WARN [payments] retry 2/5 order=ORD-11821 Output: {"ts": "2026-10-12T14:03:22Z", "level": "warn", "service": "payments", "message": "retry 2/5", "order_id": "ORD-11821"}

Input: 2026-10-12 14:03:25 ERROR [auth] token expired user=u_448 Output: {"ts": "2026-10-12T14:03:25Z", "level": "error", "service": "auth", "message": "token expired", "user_id": "u_448"}

Then move to test-driven iteration: write tests for the edge cases (missing service tag, multi-line stack traces, null user), run them, and paste the failures back. When two failures interact, for example timezone handling and multi-line joins, send both in one message so Claude fixes them together.

gh pr view ${{ github.event.number }} --json comments > prior.json claude -p "Review pr.diff using the criteria in CLAUDE.md. \

prior.json holds earlier bot findings: report only new or unaddressed issues." \ --output-format json --json-schema "$(cat .github/review-schema.json)" \ > findings.json

python scripts/post_inline_comments.py findings.json

What each piece does for the exam: -p prevents the hang; the schema flags make findings.json parseable; CLAUDE.md carries the review criteria; prior.json prevents duplicate comments; and this job runs in a fresh session, independent of whatever session wrote the code. Anthropic also publishes a ready-made Claude Code GitHub Action; the exam tests the underlying flags rather than any one CI product.

Deep dive: what CLAUDE.md should say for CI test generation

Test generation in CI improves sharply when CLAUDE.md documents what a good test is in this codebase. A useful section:

## Testing standards

- Framework: Vitest. Factories in tests/factories; never hand-build User or Order objects. - Valuable tests: branch coverage of business rules, error paths, boundary values. - Low-value tests (do not write): getters/setters, snapshot tests of static markup, tests that only assert a mock was called.

- Fixtures: tests/fixtures/payments/*.json for gateway responses.

- Before proposing tests, read the existing *.test.ts next to the file and do not duplicate cases.

This addresses three guide skills at once: documenting standards and fixtures, reducing lowvalue output, and avoiding duplicates of existing tests.

Deep dive: settings and permissions in brief

The exam's Claude Code questions centre on CLAUDE.md, rules, commands, skills, MCP scope and CLI flags. Settings files are adjacent knowledge worth having. As of October 2026, Claude Code reads settings from managed policy (set by an organisation), ~/.claude/settings.json (user), .claude/settings.json (project, committed) and .claude/settings.local.json (project, personal, not committed). Permission rules there allow, ask about or deny specific tools and commands, and hooks for Claude Code itself are configured there too. Where the same setting appears at several levels, the more specific and the managed levels take precedence; check the current documentation for the exact order before relying on it.

Common traps

Putting team instructions or commands in ~/.claude/.

Using a subdirectory CLAUDE.md for conventions that apply to files spread across the repo.

Starting a 45-file migration in direct execution.

Letting the generating session review its own output.

Inventing flags. If an option sounds plausible but you have never seen it (--batch, CLAUDE_HEADLESS), it is probably the distractor.

Check yourself

Where does a skill go if every developer should get it from the repo?

Which frontmatter field keeps a verbose skill from polluting the main conversation?

CLAUDE CODE CONFIGURATION & WORKFLOWS (20%)

Your CI job hangs at "waiting for input". What is the fix?

Terraform conventions should load only when editing files under terraform/. What do you create?