Which mechanism? The config decision, in one pass.

1 · The procedure — two questions, asked in order

Don't recall six mechanisms. Recall two questions. The second one is the one you got wrong.

1. When should this apply? Always · only for certain files · only when I ask · at the moment a tool runs.
2. Is it advice or a guarantee? Can Claude reasonably decide not to follow it — or must it be impossible to violate?

Everything in the first family — CLAUDE.md, .claude/rules/, skills, commands — is context: it shapes behaviour probabilistically. Everything in the second — hooks, settings permissions — is enforcement: deterministic, applied by the client. The moment a question says must, guarantee, prevent, never, or names a compliance rule, you have left the CLAUDE.md family entirely.

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, transforms)
│                 └─ hook   ·  before the call = PreToolUse
│                           ·  after the call  = 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 ... skill
                    └─ a named repeatable prompt  command

2 · The six mechanisms

Recognition matters more than authoring: a favourite distractor is invented syntax (.claude/config.json with a commands array, .claude/config.yaml). Neither exists.

Load order and scope

Broadest scope first, most specific last — this is load order, not precedence (see §3):

Two more facts worth holding: user-level rules load before project rules, and a rule without a paths field loads unconditionally — that single key is the whole difference between a rule file and CLAUDE.md.

3 · Five sentences that decide questions

Verbatim from the official memory docs. Q34 was written directly against the first three — the question's correct answer quoted them. Read these until they're reflexive.

Also verified, and useful if compaction comes up: project-root CLAUDE.md survives /compact — Claude re-reads it from disk and re-injects it. Instructions that vanish after compaction were conversation-only, or in a nested/path-scoped file that hasn't re-matched yet.

4 · Hooks — scoped to what's actually tested

The live docs list roughly 26 hook events. The exam guide's appendix names exactly one: hooks (PostToolUse, tool call interception). Spend your time accordingly.

Beyond the guide, but on your mock

These cost you Q20 here and Q50 on the 08-24 run. Worth ten minutes of recognition, not memorisation.

The shapes, for recognition

// settings.json → permissions          // blanket allow / deny / ask
{ "permissions": {
    "allow": ["Bash(npm run test *)"],
    "deny":  ["Read(./.env)"],
    "ask":   ["Write(./src/**)"] } }
// ToolName(pattern) in one of three arrays. Deny wins across scopes.

// settings.json → hooks                 // enforcement with logic
{ "hooks": {
    "PreToolUse": [
      { "matcher": "Bash",
        "hooks": [ { "type": "command", "command": "./.claude/hooks/gate.sh" } ] } ] } }
// event → matcher → handlers array.

5 · The three look-alike pairs

These generate most D3 distractors. Each turns on a single question.

a) Skill vs path-scoped rule — why does it load?

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

Exemplar endpoints that help generate new endpoints but are dead weight during a bug fix in the same directory → skill. A path rule would load them on every bug fix too. "Only useful for task X" → skill. "Applies to file type Y" → path rule.

b) .claude/rules/ vs a subdirectory CLAUDE.md — directory or 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.

Nested CLAUDE.md files supplement their parents. "Each one overrides the parent" is always wrong.

c) Project vs user directory — who needs it?

• Everyone gets it on clone → .claude/commands/, .claude/skills/ — in the repo.
• Just me → ~/.claude/commands/, ~/.claude/skills/.
• My variant of a team skill → ~/.claude/skills/ under a different name.

The phrase "when they clone the repository" makes this a one-second question — anything under ~/.claude/ is wrong by definition.

Skill frontmatter — the three fields

6 · CI/CD (3.6) — where Q47 lived

The rest of 3.6, compressed:

• -p / --print — non-interactive mode. Missing it makes the pipeline hang, not produce weak output.
• --output-format json + --json-schema — machine-parseable findings for inline PR comments.
• CLAUDE.md is the CI context mechanism — testing standards, fixture conventions, review criteria.
• Re-running reviews: include prior findings, instruct Claude to report only new or still-unaddressed issues.

7 · Plan mode, direct execution, Explore

Q29 (flagged, correct): the split between the last two is understanding vs deciding. "Explain this pipeline before we refactor it" is discovery → Explore subagent. Plan mode also explores, but it runs in the main conversation and drives toward a change plan.

8 · Your five D3 misses, one line each

If you read nothing else again, read this.

Four of these five reduce to one habit: before choosing a mechanism, name the failure. Was the instruction unclear (Q26), unenforceable (Q34), mistimed (Q51), misattributed to a tool (Q20), or biased by shared context (Q47)? The failure names the mechanism. Choosing the mechanism first is how you got these wrong.

9 · Phrase → answer

The question tells you the answer in its own words. Underline the constraint phrase before reading the options.