Frequently Confused Concepts — Claude Code Configuration (CCA-F Domain 3)

These five are the master cluster. They differ on two axes: nature (does Claude read it as guidance, or does the harness run it as enforcement?) and loading (always in context, on-demand, glob-scoped, or event-triggered?). CLAUDE.md is always-loaded guidance; rules are always-loaded or glob-scoped guidance; skills are on-demand guidance you or Claude invoke; slash commands are the explicit way to invoke a skill; hooks are event-triggered shell commands the harness executes.

As of 2026, Skills and custom slash commands are unified. A skill at .claude/skills/deploy/SKILL.md and a command file at .claude/commands/deploy.md both register /deploy. The difference is who triggers it: a skill can be auto-invoked when Claude decides its description matches the task, while typing /deploy invokes it explicitly. Frontmatter like disable-model-invocation makes a skill slash-only.

Do I want this ALWAYS in context, every task?
  -> CLAUDE.md  (or an unscoped rule, to keep it modular)

Only when working on CERTAIN files/paths?
  -> Path-scoped Rule  (.claude/rules/ with `paths:`)

A reusable PROCEDURE invoked on demand (by me or by Claude)?
  -> Skill  (SKILL.md, which also registers /name)

Must it happen MECHANICALLY, guaranteed, regardless of the model?
  -> Hook  (shell command on a lifecycle event)

Is it a hard BOUNDARY — never allow this action?
  -> Permission  (permissions.deny in settings)

All CLAUDE.md files are guidance, but they differ in scope and who shares them. User memory (~/.claude/CLAUDE.md) is personal and applies to every project on your machine. Project memory (./CLAUDE.md or ./.claude/CLAUDE.md) is committed to source control and shared with the team. Above these sits an optional managed policy file deployed by IT that no user setting can exclude. A gitignored `CLAUDE.local.md` holds personal, per-project notes.

Crucially, these files do not override each other — they are all concatenated into context. Load order runs broad to specific: managed policy, then user, then project, then more-specific directories. Files closer to your working directory are read last, so when instructions genuinely conflict, the model tends to weight the most specific, but the docs warn that direct contradictions are resolved arbitrarily — so avoid them.

Both scope guidance to part of a repo, but they scope by different keys. A directory CLAUDE.md is scoped by location: it loads when Claude reads files in that subdirectory. A path-scoped rule is scoped by glob pattern: it loads when Claude reads any file matching patterns like src/api/**/*.ts, no matter where that file physically lives relative to the rule file. A rule can therefore target **/*.test.ts across the whole tree; a directory CLAUDE.md cannot cross into a sibling folder.

Both are lazy: a directory CLAUDE.md and a path-scoped rule only enter context once Claude reads a matching file — triggered on read, not on write. A rule without a paths: field loads at launch with the same priority as .claude/CLAUDE.md. Rules also keep each concern in its own small file, which many teams prefer over one growing subdirectory CLAUDE.md.

This is the cluster the exam loves, because both can sound like "enforce a standard." But a rule is natural-language guidance the model reads and interprets — it usually complies, but it can reason its way to an exception. A hook is a shell command the harness runs at a lifecycle event; it executes program logic and its outcome does not depend on the model's judgment. Rules live in .claude/rules/*.md; hooks are configured in settings.json against events like PreToolUse, PostToolUse, and Stop.

Cost and determinism trade off. Rules cost context tokens (always-loaded ones especially) and offer flexibility. Hooks sit outside the context window, cost no tokens until they fire, and offer the highest determinism but the least nuance — a hook can't weigh whether an exception is reasonable, it just runs.

This pair distills the whole domain: deterministic enforcement vs discretionary instruction. CLAUDE.md is delivered to Claude as context after the system prompt — the docs are explicit that it is "context, not enforced configuration," with "no guarantee of strict compliance." A hook is a shell command the harness executes at a fixed lifecycle event, applied "regardless of what Claude decides." If your requirement can tolerate the model's discretion, CLAUDE.md; if it cannot, a hook.

The official memory docs make the routing explicit: for an instruction that "must run at a specific point, such as before every commit or after each file edit, write it as a hook instead." CLAUDE.md is for the standing context you'd otherwise re-explain — conventions, commands, architecture — where usually-followed is good enough.

These are three working postures, not config files. Direct execution is the default: Claude reads, edits, and runs commands immediately to make the change. Plan Mode is a read-only state — write and mutating tools are blocked — where Claude investigates and proposes a structured plan you approve before any file changes. Explore is read-only investigation/search: it sweeps the codebase to find and summarize what you need, without committing to a full implementation plan or making edits.

Plan Mode is entered with Shift+Tab (cycling through the permission modes) or by starting the session with a plan permission mode; in it, Read/Grep/Glob work while Edit, Write, and Bash mutations are blocked. Explore is best thought of as read-only reconnaissance — great for "where does X live?" or "how does this system fit together?" — whereas Plan Mode ends in an actionable, reviewable plan.