Lesson 0008 · Domain 3 (20%) · Claude Certified Architect — Foundations

Which mechanism? The six-way configuration decision

CLAUDE.md · .claude/rules/ · skills · commands · hooks · settings permissions. ~15 minutes.

Why you're here. A colleague's real scored report (679/1000, fail) breaks results down per objective. Two objectives came back at 0% — and they are the same objective twice: "Select the correct Claude Code configuration mechanism — CLAUDE.md, .claude/rules/ with glob patterns, Skills, hooks, or settings permissions — based on guidance type and when it should apply" and "Create and deploy custom slash commands in the correct project or user directory." Your own mock missed the same two (Q18 ×3). Lesson 0005 taught three of these six mechanisms — it has zero mention of hooks or permissions. This closes it.

0 · Two axes decide every one of these questions

Don't memorize six things. Memorize two questions, asked in order:

WHEN should this apply? Always · only for certain files · only when I ask · at the moment a tool runs
How binding is it — advice or guarantee? Can Claude reasonably decide not to follow it, or must it be impossible to violate?

Axis 2 is the one people fail. Everything in the first group (CLAUDE.md, rules, skills) is context — it shapes behavior probabilistically. Everything in the second (hooks, permissions) is enforcement — deterministic. The moment a question says "must", "guarantee", "prevent", "never", or names a compliance/policy rule, you have left the CLAUDE.md family entirely.

1 · The six mechanisms in one table

Mechanism	When it applies	Binding?	Reach for it when
`CLAUDE.md`	Always loaded	Advice	Universal standards that are relevant to every task in scope
`.claude/rules/*.md`	Always — or conditionally, with a `paths` glob in frontmatter	Advice	Topic-split of a bloated CLAUDE.md; or conventions tied to a file type spread across directories
`.claude/skills/` (`SKILL.md`)	On demand — only when invoked	Advice	A workflow with heavy context that is useless for other tasks
`.claude/commands/`	On demand — typed as `/name`	Advice	A repeatable prompt the team runs by name
Hooks	At tool-call time	Guarantee	Block a call, or transform its result, deterministically
Settings permissions	At tool-call time	Guarantee	Allow / deny / ask for a tool or path outright

2 · The decision tree

Must it be impossible to violate? (policy, compliance, "never", "guarantee")
├─ YES → is it a blanket allow/deny of a tool or path?
│         ├─ YES → settings permissions
│         └─ NO, it needs logic (thresholds, prerequisites, transforming results)
│                 → hook  · before the call = PreToolUse · after = PostToolUse
└─ NO, it's guidance → WHEN is it relevant?
          ├─ every task            → CLAUDE.md
          ├─ only certain files    → .claude/rules/ + paths glob
          └─ only when I ask for it
                    ├─ carries heavy context / verbose output → skill
                    └─ just a named repeatable prompt         → command

Exam tell: the question always tells you the answer in its own words. "Available to every developer when they clone" → project-scoped, in the repo. "Only useful when generating new endpoints" → on demand. "Must never happen" → enforcement. Underline those phrases before you read the options.

3 · What each one actually looks like

You are not asked to author these from memory. You are asked to recognise them — and that matters, because a favourite distractor is invented syntax. Your own mock offered .claude/config.json with a commands array and .claude/config.yaml mapping patterns to CLAUDE.md sections. Neither exists. Knowing the six real shapes is how you delete those options in one second.

CLAUDE.md — repo root, or ~/.claude/, or any subdirectory

Plain markdown. No frontmatter. Always loaded. ## Testing - Use vitest, not jest. - Every new endpoint needs a contract test. @import ./standards/api-conventions.md

.claude/rules/testing.md — YAML frontmatter is what makes it conditional

--- paths: ["**/*.test.tsx", "**/*.spec.ts"] --- Use `screen.getByRole`, never `getByTestId`. Mock at the network boundary with MSW.

The whole point: without paths it behaves like CLAUDE.md — always loaded. With paths it loads only when a matching file is in play. That one key is the difference between the two mechanisms.

.claude/skills/new-endpoint/SKILL.md — on demand only

--- name: new-endpoint description: Scaffold a new API endpoint following our exemplars. context: fork allowed-tools: Read, Write, Edit argument-hint: <resource-name> --- Here are three exemplar endpoints to follow: ...

.claude/commands/review.md — invoked by typing /review

Just the prompt text. The filename becomes the command name. Run our review checklist on the current diff: 1. Contract tests present? 2. Error paths handled?

.claude/settings.json → permissions — blanket allow / deny / ask

{ "permissions": { "allow": ["Bash(npm run test *)"], "deny": ["Read(./.env)", "Read(./secrets/**)"], "ask": ["Write(./src/**)"] } }

Shape to remember: ToolName(pattern) inside one of three arrays. And a rule worth knowing: permission rules merge across scopes — a deny from any settings file takes effect, and allow rules accumulate. Deny wins.

.claude/settings.json → hooks — enforcement with logic

{ "hooks": { "PreToolUse": [ { "matcher": "Bash", "hooks": [ { "type": "command", "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/gate.sh" } ] } ] } }

Shape to remember: event name → matcher (which tool) → a hooks array of handlers. The script blocks the call by exiting 2, or by returning "permissionDecision": "deny". Swap PreToolUse for PostToolUse and the same structure runs after the tool instead — see §5.

Where settings live, and who wins

File	Scope	Shared?
`~/.claude/settings.json`	You, all projects	No
`.claude/settings.json`	This repo, everyone	Yes — committed
`.claude/settings.local.json`	You, this repo	No — gitignored
Managed policy	Whole org	Yes — IT-deployed, cannot be overridden

Same axis as everything else in Domain 3: ~/.claude/ is personal, .claude/ in the repo is the team's, .local.json is personal-but-per-repo. Managed policy sits above all of them.

4 · Advice vs guarantee — the line that decides half the questions

Verbatim from the guide (1.4): "When deterministic compliance is required (e.g., identity verification before financial operations), prompt instructions alone have a non-zero failure rate."

That sentence is the whole rule. CLAUDE.md is a prompt. A rule file is a prompt. A skill is a prompt. If the scenario's cost of one violation is unacceptable — money moved, data deleted, PII leaked, a commit to main — no amount of prompt wording is the right answer.

Anti-pattern: "Add a stronger instruction in CLAUDE.md, in bold / in caps / at the top". This distractor appears constantly and it is never right for a must-not-happen requirement. Escalating the emphasis of a probabilistic mechanism does not make it deterministic.

5 · PreToolUse vs PostToolUse — which one can actually stop something

This distinction was missing from every lesson in this workspace, and the exam scores an objective that names both hooks explicitly.

Hook	Fires	Can it block?	Its job
`PreToolUse`	Before the tool executes	Yes	Intercept an outgoing call and refuse it — policy gates, prerequisites, thresholds
`PostToolUse`	After the tool succeeds	No — it already ran	Transform / normalize the result before the model reads it; validate; log

The two canonical guide examples — learn them as a pair

Normalize before the model sees it → PostToolUse. Guide 1.5: "Implementing PostToolUse hooks to normalize heterogeneous data formats (Unix timestamps, ISO 8601, numeric status codes) from different MCP tools before the agent processes them."
Block a policy violation → interception before the call. Guide 1.5: "tool call interception hooks that block policy-violating actions (e.g., refunds exceeding $500) and redirect to alternative workflows." Guide 1.4: "blocking process_refund until get_customer has returned a verified customer ID."

Mnemonic: Pre = prevent. Post = process. If the requirement is "stop it happening", PostToolUse is structurally incapable — the action already completed.

Correction to your own study notes. The project CLAUDE.md in this repo lists only PostToolUse under Domain 1's key topics, and puts it right beside the blocking example ("block process_refund until get_customer returns a verified ID"). Those belong to different hooks. Blocking is PreToolUse's job. Don't carry that pairing into the exam.

6 · The three look-alike pairs that generate the distractors

a) Skill vs path-scoped rule — this is your Q18 miss

Both load context conditionally, so they feel interchangeable. They are not:

Path rule fires whenever you touch a matching file — for any reason.
Skill fires only when you invoke it — for a specific task.

Your Q18: exemplar endpoint implementations that help generate new endpoints but are useless for bug fixes or reviews in the same directory. You chose .claude/rules/api/. But a path rule would load those exemplars during every bug fix in that directory too — precisely the waste the question described. "Only useful for task X" → skill. "Applies to file type Y" → path rule.

b) `.claude/rules/` vs a subdirectory `CLAUDE.md`

Both scope guidance below the root. The deciding factor is whether the thing you're scoping to is a directory or a file type.

Conventions for one subtree (the mobile/ app) → subdirectory CLAUDE.md
Conventions for a file type scattered across the tree (every *.test.tsx, all Terraform) → .claude/rules/ with a paths glob

Also testable: nested CLAUDE.md files supplement their parents — they do not override them. "Each one overriding the parent" is always a wrong option.

c) Project vs user directory — the scope question

Goal	Location
Every developer gets it on `clone` / `pull`	`.claude/commands/` · `.claude/skills/` — in the repo, version-controlled
Just me; don't affect teammates	`~/.claude/commands/` · `~/.claude/skills/`
My own variant of a skill the team already has	`~/.claude/skills/` under a different name

Exam tell: the phrase "when they clone the repository" makes this a one-second question — it must be in the repo. ~/.claude/ anything is then wrong by definition, and so are invented files like .claude/config.json with a commands array.

7 · Skill frontmatter — the three fields worth knowing

Field	What it buys you
`context: fork`	Runs the skill in an isolated sub-agent context, so verbose output never pollutes the main conversation. For codebase analysis, exploratory brainstorming, anything noisy.
`allowed-tools`	Restricts tool access during the skill — e.g. no write operations, to prevent destructive actions.
`argument-hint`	Prompts the developer for required parameters when they invoke it bare.

Exam tell: "the analysis output floods the session / eats the context window" → context: fork. That is the same context-isolation idea as a subagent (Lesson 0003), applied to a skill.

Practice — read the constraint, then pick the mechanism

Primary source

Exam guide PDF (guides/, v1.0) — Task Statements 3.1 (CLAUDE.md hierarchy, @import, .claude/rules/), 3.2 (commands & skills, context: fork / allowed-tools / argument-hint), 3.3 (path-scoped rules), 1.4 (programmatic enforcement, non-zero failure rate), 1.5 (hook patterns: PostToolUse normalization vs tool-call interception). Read 2026-08-20.

Hook blocking semantics verified against live docs the same day (hooks reference): PreToolUse fires "before a tool call executes — can block it" (exit code 2, or permissionDecision: "deny"); PostToolUse fires "after a tool call succeeds" and cannot block, since the tool has already run.

Scored-report evidence: feedbacks-from-other/report-679-out-of-1000.png — the two 0% objectives this lesson targets.