D7 · Claude Code - AI Cert Prep

This domain is roughly 2 of 53 items. It tests whether you know how Claude Code is configured and operated: the CLAUDE.md hierarchy, settings.json scopes and permissions, session management, slash commands, headless mode, hooks, MCP config and plan mode. The theme: behaviour comes from configuration files, and permissions/hooks – not prose – enforce control.

Learning objectives

By the end of this page you should be able to:

Identify Claude Code’s core components: Rules/CLAUDE.md, Skills, Commands, Agents/subagents, Agent Memory.
Explain the CLAUDE.md hierarchy and @path imports.
Configure settings.json scopes and permissions (allow/deny/ask).
Manage sessions (/compact, /clear, resume) and use slash commands.
Use headless (-p, --output-format) and streaming modes and permission modes.
Configure hooks, MCP, and plan mode.

7.1 Core components

Component	Where	Purpose
Rules / `CLAUDE.md`	Hierarchy of files	Persistent project/user instructions
Skills	`.claude/skills/<name>/SKILL.md`	Progressive, on-demand capabilities (name + description frontmatter)
Commands	`.claude/commands/*.md`	Custom slash commands with `$ARGUMENTS`
Agents / subagents	`.claude/agents/*.md`	Own system prompt, tool allowlist, model; isolated context
Agent Memory	`/memory`	Durable cross-session notes

7.2 CLAUDE.md hierarchy and imports

CLAUDE.md files are memory: persistent instructions Claude loads at session start. They compose from broad to narrow, with more-specific files layered on top of (not replacing) broader ones. Managed policy sits at the top and cannot be overridden.

What belongs where

Content	File	Reason
Org-wide security rules, forbidden tools	managed policy	Must not be overridable by any developer
Personal preferences (editor style, alias notes)	`~/.claude/CLAUDE.md`	Applies to you across all projects
Team coding standards, architecture, build/test commands	`./CLAUDE.md`	Checked in; single source of team truth
Module-specific conventions (e.g. API layer rules)	`./services/api/CLAUDE.md`	Loaded only when working in that subtree
Your local scratch notes, experimental instructions	`CLAUDE.local.md`	Git-ignored; never shared
Shared standards referenced from many places	separate file via `@path` import	Write once, import into project `CLAUDE.md`
Secrets, tokens, API keys	none of the above	Version-controlled; use `env` / a secret manager

Example project CLAUDE.md

Secrets never go in CLAUDE.md

CLAUDE.md is version-controlled and shared. Put secrets in environment variables or a secret manager and reference them by name. A leaked key in CLAUDE.md is an exfiltration incident.

7.3 settings.json scopes and permissions

settings.json controls behaviour (model, permissions, hooks, environment). Like memory, it composes across scopes, and managed policy cannot be overridden.

A checked-in project settings.json with permissions, hooks, and env:

permissions.allow runs the tool without prompting; ask prompts for confirmation; deny blocks outright.
deny beats allow. A tool matched by both is denied.
Rules are patterns, e.g. Bash(rm -rf:*) denies that command family while allowing other Bash.
Prefer deny-by-default for destructive commands; keep allow to the tools a task genuinely needs.

Exam signal

‘Enforce a rule / block a command / no one can override’ → permissions + managed policy, not a sentence in CLAUDE.md. Prose is guidance; permissions and hooks are enforcement.

7.4 Hooks

Hooks are deterministic shell or HTTP handlers that fire on lifecycle events. Unlike prose instructions, they always run and can block an action — the mechanism for enforcing critical business rules (anti-pattern #3 is enforcing rules in prose instead).

Event	Fires when	Typical use
`PreToolUse`	Before a tool runs	Validate/block a command; `exit 2` denies it
`PostToolUse`	After a tool runs	Auto-format, lint, run tests on edited files
`UserPromptSubmit`	User submits a prompt	Inject context; scan for secrets
`Stop`	Main agent finishes responding	Enforce completion checks
`SubagentStop`	A subagent finishes	Validate subagent output
`SessionStart`	Session begins	Load environment info, print reminders
`Notification`	Claude sends a notification	Route to Slack/paging
`PreCompact`	Before context compaction	Persist state that must survive compaction

Exit code 2 from a hook blocks the action (stderr is shown to Claude); other non-zero codes are non-blocking errors.

7.5 Skills vs slash commands vs subagents

Three ways to package reusable behaviour. The exam tests which one fits a scenario.

Dimension	Skill	Slash command	Subagent
File	`.claude/skills/<name>/SKILL.md`	`.claude/commands/<name>.md`	`.claude/agents/<name>.md`
Trigger	Model loads it on demand when relevant	User types `/<name>` explicitly	Delegated a task (auto or explicit)
Context	Progressive; loaded only when needed	Injected into current context	Isolated own context window
Own system prompt / model	No	No	Yes (own prompt, tools allowlist, model)
Best for	A capability Claude should reach for automatically	A repeatable prompt you invoke by hand	A specialised worker that needs isolation

Skill (.claude/skills/api-docs/SKILL.md):

Slash command with $ARGUMENTS (.claude/commands/fix-issue.md):

Invoke with /fix-issue 482 — $ARGUMENTS becomes 482.

Subagent (.claude/agents/reviewer.md):

Exam signal

‘Loads automatically when relevant / progressive disclosure’ → Skill. ‘A command the developer runs with an argument’ → slash command with $ARGUMENTS. ‘Needs its own context / narrow tools / different model / isolation’ → subagent.

7.6 Plan mode

Plan mode (enter with Shift+Tab, or --permission-mode plan headless) makes Claude explore read-only and produce a plan before it edits anything. It is the safe first step for large or risky changes: a migration, a cross-cutting refactor, or unfamiliar code. You review the plan, then approve execution.

The exam pairs plan mode with large automated migrations and risk reduction: explore → plan → approve → apply with tests.

7.7 Headless mode, streaming and permission modes

# One-shot, machine-readable output for CI
claude -p "Summarise the failing tests" --output-format json

# Streaming JSON events (parse incrementally)
claude -p "Refactor utils" --output-format stream-json --allowedTools "Read,Edit"

# Read-only review with a restricted toolset
claude -p "Review the staged diff for security issues; output JSON." \
  --output-format json \
  --allowedTools "Read,Grep" \
  --permission-mode plan

-p runs non-interactively; --output-format is json or stream-json; --allowedTools restricts the toolset; --permission-mode sets the gating behaviour.

--permission-mode (or permissionMode in the SDK):

Mode	Behaviour
`default`	Ask before non-allowlisted tools
`acceptEdits`	Auto-accept file edits, still gate other tools
`plan`	Read-only; explore and plan, no changes
`bypassPermissions`	Skip all prompts — dangerous; only in a trusted, sandboxed CI

Interactive Shift+Tab enters plan mode: read-only exploration, then a proposed plan you approve before any change. The headless equivalent is --permission-mode plan.

Exam signal

‘Run Claude Code in CI / non-interactively / machine-readable output’ → headless -p with --output-format json|stream-json and a restricted --allowedTools. ‘Explore safely before changing anything’ → plan mode. Never bypassPermissions outside a trusted sandbox.

7.8 Session commands and MCP configuration

Slash commands during an interactive session:

Command	Effect
`/compact`	Summarise the conversation server-side to free context (keeps narrative)
`/clear`	Reset the conversation entirely (fresh context)
`/init`	Bootstrap a `CLAUDE.md` for the current project
`/memory`	View/edit agent memory (`CLAUDE.md` files)
`/agents`	Manage subagents
`/hooks`	Manage hooks
`/mcp`	Manage/inspect MCP servers and auth
`/cost`	Show token and cost usage for the session

/compact summarises to preserve narrative; /clear throws context away — do not confuse them.

MCP config scopes

Add servers with claude mcp add <name> --scope <scope> -- <command> or by editing .mcp.json:

Scope	Stored in	Shared?
`local`	Your machine, current project only	No (personal, this project)
`project`	`.mcp.json` in the repo	Yes — checked in, team-wide vetted catalogue
`user`	Your user config	No — spans your projects, personal

Use project scope for a shared, vetted catalogue; inspect and authenticate with /mcp.

7.9 The permission model in depth: allow / ask / deny and precedence

Claude Code’s tool control is a small but heavily tested decision surface. Rules are patterns, they compose across scopes, and deny beats allow; managed policy sits above everything.

Decision	Meaning	Use for
`allow`	Run without prompting	Safe, frequently-used tools (Read, Grep, Glob)
`ask`	Prompt for confirmation	Medium-risk tools (Bash, WebFetch)
`deny`	Block outright (wins over `allow`)	Destructive command families, reading `.env`

Scenario	Correct configuration
Block `rm -rf` for everyone, non-overridably	`Bash(rm -rf:)` in `deny`, set via managed policy*
Auto-run read tools, confirm shell	`allow: [Read, Grep, Glob]`, `ask: [Bash]`
Never read the secrets file	`deny: [Read(./.env)]`
Personal-only experiment	`settings.local.json` (git-ignored)

Exam signal

‘No one can override this block’ → managed policy deny. ‘A tool is in both allow and deny’ → denied (deny beats allow). ‘Enforce a rule’ → permissions/hooks, never a CLAUDE.md sentence.

7.10 Composing memory and settings across scopes

CLAUDE.md (memory) and settings.json (behaviour) both compose broad→narrow, and both are topped by non-overridable managed policy. Knowing what belongs where is a frequent item.

Layer	`CLAUDE.md` (memory)	`settings.json` (behaviour)
Managed / enterprise	Org security rules, forbidden tools (non-overridable)	Managed permissions/hooks (non-overridable)
User (`~/.claude/`)	Personal preferences across all projects	Personal model/permission defaults
Project (`./`, `.claude/`)	Team standards, build/test commands (checked in)	Team baseline permissions, hooks, env (checked in)
Subdirectory / local	Module rules; `CLAUDE.local.md` (git-ignored)	`settings.local.json` (git-ignored)

Secrets never belong in either — use env vars / a secret manager.
@path imports pull shared files into any CLAUDE.md.
A subdirectory file layers on top of (does not replace) broader files when working in that subtree.

Local files are personal, not team policy

CLAUDE.local.md and settings.local.json are git-ignored and personal. Putting a rule you need the whole team to follow in a local file means nobody else gets it — use checked-in project files or managed policy.

7.11 Common misconceptions

Misconception	Reality	Why it matters on the exam
A `CLAUDE.md` sentence enforces a rule	Prose is guidance; enforcement is permissions/hooks	Anti-pattern #3 in Claude Code form
Project settings can override managed policy	Managed/enterprise policy is non-overridable	Precedence questions
`allow` wins if a tool is also denied	`deny` beats `allow`	Permission-resolution trap
`bypassPermissions` is fine for convenience	Only in a trusted, sandboxed CI; it removes safeguards	Safety trap
`/compact` and `/clear` are interchangeable	Compact summarises (keeps narrative); clear resets	Session-management trap
Secrets can live in `CLAUDE.md` as documentation	It is version-controlled; use env/secret manager	Secrets-hygiene trap
A slash command loads automatically	Slash commands are user-invoked; Skills load on demand	Skill vs command vs subagent
`CLAUDE.local.md` is a good place for team rules	It is git-ignored and personal	Scope trap

7.12 Scenario walkthrough: hardening a shared Claude Code setup for CI

Scenario. A team uses Claude Code both interactively and in CI. Security requires that rm -rf, git push --force, and reading .env are blocked for everyone and cannot be overridden by any developer. CI must run non-interactively, produce machine-readable output, and only read code (no edits). Developers keep asking to bypassPermissions in CI ‘to make it faster’, and one added never force-push to ./CLAUDE.md expecting it to be enforced. Design the configuration.

Expert reasoning trace.

Enforce the destructive-command blocks non-overridably. Put deny patterns (Bash(rm -rf:*), Bash(git push --force:*), Read(./.env)) in managed policy so no user/project/local file can override them; deny beats allow. The ./CLAUDE.md sentence is prose, not enforcement (anti-pattern #3) — it must be removed as a false sense of safety and replaced with the permission rule.
Configure CI correctly. Headless claude -p "..." --output-format json with an explicit --allowedTools "Read,Grep,Glob" and --permission-mode plan (read-only). This is machine-readable, non-interactive, and edit-free.
Reject bypassPermissions. It removes the very safeguards required and would let a compromised or injected step run destructive commands; allow it only inside a fully trusted, sandboxed automation — not the general CI here.
Put team rules in the right scope. Coding standards and build/test commands go in checked-in ./CLAUDE.md; the security blocks go in managed policy; personal experiments go in git-ignored CLAUDE.local.md/settings.local.json.
Reject the tempting alternatives. ‘Trust the CLAUDE.md rule’ — prose is not enforcement. ‘Use bypassPermissions for speed’ — removes safeguards. ‘Add the block only to project settings’ — a developer could override it locally, so it must be managed policy.

Correct decision. Managed-policy deny patterns for the destructive commands and .env; headless CI with --output-format json, a read-only --allowedTools allowlist, and --permission-mode plan; no bypassPermissions outside a trusted sandbox; team standards in checked-in CLAUDE.md, personal items in git-ignored local files.

Exam traps in this domain

Trap	Why it is wrong
Putting secrets in `CLAUDE.md`	It is version-controlled; use env/secret manager
Assuming project `CLAUDE.md` overrides managed policy	Managed/enterprise policy wins and is not overridable
Using `bypassPermissions` casually	Removes safeguards; only in trusted, sandboxed automation
Enforcing rules in `CLAUDE.md` prose instead of permissions/hooks	Prose is guidance, not enforcement (anti-pattern #3)
Expecting interactive prompts in CI	Use headless `-p` + `--output-format` + `--allowedTools`
Confusing `/compact` with `/clear`	Compact summarises and keeps narrative; clear resets
Loading a huge tool set instead of subagents	Overloads selection; use subagents + tool search
Forgetting `deny` beats `allow`	A tool in both lists is denied
Using a slash command where a Skill is needed	Skills load on demand; commands are user-invoked
Giving a subagent broad tools ‘just in case’	Violates least privilege; scope the allowlist
Putting a rule in `CLAUDE.local.md` for the whole team	It is git-ignored and personal; use checked-in/managed
Confusing `local` and `project` MCP scope	Only `project` (`.mcp.json`) is shared/checked in
Putting a non-overridable block only in project settings	A developer can override it locally; use managed policy
Assuming `allow` wins over `deny`	`deny` beats `allow`; resolution is deny > ask > allow
Enforcing a security rule via a `./CLAUDE.md` sentence	Prose is guidance; use a `deny` permission or hook (anti-pattern #3)
Using `bypassPermissions` in general CI for speed	Removes safeguards; only inside a fully trusted sandbox
Storing team standards in `settings.local.json`	It is git-ignored and personal; use checked-in project settings

Practice questions

Q1 · A team runs Claude Code in a CI pipeline and needs machine-readable results with no interactive prompts. Which invocation fits? (Select one)

A. claude interactive with plan mode. B. claude -p "..." --output-format json with an explicit --allowedTools allowlist. C. claude with bypassPermissions and no output format. D. Open Claude Desktop.

Answer: B. Headless -p with --output-format json and a tool allowlist is the CI pattern. Interactive plan mode (A) and Desktop (D) are not headless and cannot run unattended; bypassPermissions (C) removes safeguards and gives unstructured output CI cannot parse.

Q2 · A managed enterprise policy forbids the Bash tool, but a project `CLAUDE.md` says to use it and `settings.local.json` allows it. What happens? (Select one)

A. The project setting wins. B. The local setting wins. C. The managed policy wins and Bash remains denied. D. It is undefined.

Answer: C. Managed/enterprise policy sits at the top of precedence and cannot be overridden by user, project, or local config. Prose in CLAUDE.md (A) is not enforcement, and a local file (B) cannot override a managed deny; behaviour is well-defined, not undefined (D).

Q3 · A subdirectory `./services/api/CLAUDE.md` sets a rule that conflicts with the project-root `./CLAUDE.md` while you work in that subtree. Which applies, and why? (Select one)

A. The root file always wins because it is checked in first. B. The more specific subdirectory file layers on top for work in that subtree, while the root file still contributes; managed policy still overrides both. C. Neither applies; you must merge them manually. D. Only CLAUDE.local.md applies in subdirectories.

Answer: B. Memory composes broad-to-narrow: the subdirectory file adds module-specific context on top of the root standard, and managed policy remains non-overridable above both. The root does not simply win (A); files compose automatically rather than requiring a manual merge (C); CLAUDE.local.md is a personal git-ignored override, not the general mechanism (D).

Q4 · A team wants a destructive command family such as `rm -rf` to be blocked deterministically for everyone, and they also want the block enforced even if a developer tries to allow it. Which TWO steps achieve this? (Select two)

A. Add Bash(rm -rf:*) to permissions.deny in the checked-in .claude/settings.json. B. Write ‘never run rm -rf’ in ./CLAUDE.md. C. Enforce the deny through managed policy so it cannot be overridden. D. Add a PostToolUse hook to apologise after the command runs. E. Ask developers to be careful.

Answer: A and C. A deny pattern blocks the command family deterministically (deny beats allow), and putting it in managed policy makes it non-overridable. Prose in CLAUDE.md (B) is guidance, not enforcement; a PostToolUse hook (D) fires after the damage; asking developers (E) is not a control.

Q5 · You want Claude to automatically reach for a documented house style whenever it writes API reference docs, without the developer having to invoke anything. Which component fits? (Select one)

A. A slash command in .claude/commands/. B. A Skill (.claude/skills/api-docs/SKILL.md) with a name and description, loaded on demand. C. A subagent with its own model. D. A line in settings.local.json.

Answer: B. Skills load progressively and automatically when their description matches the task — exactly ‘reach for it when relevant’. A slash command (A) must be typed by the user; a subagent (C) is for isolated delegated work with its own context; a settings file (D) does not carry authored capability content.

Q6 · A developer wants `/fix-issue 482` to investigate and fix GitHub issue 482. How is the issue number passed into the command definition? (Select one)

A. It is read from an environment variable automatically. B. Via $ARGUMENTS in the .claude/commands/fix-issue.md file. C. Through the subagent’s tools allowlist. D. It cannot take arguments; commands are static.

Answer: B. Custom slash commands substitute the text after the command name into $ARGUMENTS. It is not an env var (A); the tools allowlist (C) governs subagent permissions, not command arguments; commands do accept arguments (D).

Q7 · A reviewer subagent should read and analyse code but must never modify files, and should use a stronger model for judgement. Which configuration is correct? (Select one)

A. tools: Read, Grep, Glob and model: claude-opus-5 in .claude/agents/reviewer.md. B. Give it all tools and rely on a prompt saying ‘do not edit’. C. Put it in .claude/commands/ with $ARGUMENTS. D. Set bypassPermissions so it runs without friction.

Answer: A. A subagent takes an explicit tools allowlist and its own model; restricting to read tools enforces the no-edit rule, and Opus 5 provides stronger judgement. A prompt-only rule (B) is not enforcement; a slash command (C) is not an isolated agent; bypassPermissions (D) removes the very safeguards you want.

Q8 · During a long session, context is nearly full but the developer wants to keep the working narrative and continue. Which command is appropriate, and how does it differ from the alternative? (Select one)

A. /clear, because it frees the most space. B. /compact, which summarises server-side while preserving the narrative; /clear would discard the conversation entirely. C. /init, to rebuild context. D. /memory, to erase old turns.

Answer: B. /compact summarises to free context while keeping continuity; /clear resets everything and loses the narrative. /init (C) bootstraps a CLAUDE.md; /memory (D) edits memory files, not the live transcript.

Q9 · A team wants a vetted set of MCP servers shared across the repo and checked into version control. Which scope should they use? (Select one)

A. local scope. B. user scope. C. project scope via .mcp.json, committed to the repo. D. There is no way to share MCP servers.

Answer: C. Project scope stores servers in .mcp.json in the repository, making a shared, vetted catalogue available team-wide. local (A) is personal to one machine/project; user (B) spans only your own projects; sharing is clearly possible (D).

Q10 · Before a large automated migration across many files, what is the safest first step in Claude Code? (Select one)

A. Apply all edits immediately, then review the diff. B. Use plan mode (Shift+Tab or --permission-mode plan) to explore read-only and produce a plan, then approve and apply with tests. C. Set bypassPermissions to move quickly. D. Delete the tests to avoid noise.

Answer: B. Plan mode explores without editing and yields a reviewable plan, reducing blast radius on large changes. Applying blindly (A), bypassing permissions (C), and removing tests (D) all increase risk.

Q11 · Which TWO practices correctly enforce a critical rule and manage tool access in Claude Code? (Select two)

A. A PreToolUse hook that exits with code 2 to block a forbidden command. B. A permissions.deny pattern for the forbidden command. C. A paragraph in CLAUDE.md describing the rule. D. tool_choice set in the prompt text. E. Trusting the model to remember the instruction.

Answer: A and B. A PreToolUse hook returning exit code 2 blocks the action deterministically, and a deny pattern refuses the tool outright — both are enforcement. Prose in CLAUDE.md (C) and reliance on memory (E) are guidance, not control; tool_choice (D) is an API parameter, not a Claude Code permission mechanism.

Q12 · A developer wants personal experimental instructions that must never be committed or shared with teammates. Where do they belong? (Select one)

A. ./CLAUDE.md. B. Managed policy. C. CLAUDE.local.md (git-ignored) or settings.local.json. D. .mcp.json.

Answer: C. CLAUDE.local.md and settings.local.json are git-ignored personal overrides — the right home for un-shared experiments. ./CLAUDE.md (A) is checked in and shared; managed policy (B) is org-wide and non-overridable; .mcp.json (D) configures MCP servers, not instructions.

Q13 · A tool matches both an `allow` and a `deny` pattern in the resolved settings. What happens? (Select one)

A. allow wins because it is listed first. B. deny wins; resolution is deny > ask > allow. C. The tool prompts the user every time. D. Behaviour is undefined.

Answer: B. deny beats allow in permission resolution. Ordering does not decide it (A); it is denied, not an ask prompt (C); and the behaviour is well-defined (D).

Q14 · Security needs `rm -rf` blocked for everyone with no developer able to override it. Where must the `deny` rule live? (Select one)

A. In each developer’s settings.local.json. B. In managed/enterprise policy, which is non-overridable and beats allow. C. In ./CLAUDE.md as a sentence. D. In a PostToolUse hook.

Answer: B. Only managed policy is non-overridable by user/project/local config. Local files (A) can be changed by the developer; a CLAUDE.md sentence (C) is prose, not enforcement; a PostToolUse hook (D) fires after the command runs.

Q15 · A CI job must run non-interactively, output machine-readable results, and never edit files. Which invocation fits BEST? (Select one)

A. claude interactive with plan mode. B. claude -p "..." --output-format json --allowedTools "Read,Grep,Glob" --permission-mode plan. C. claude -p "..." --permission-mode bypassPermissions. D. Claude Desktop with MCP.

Answer: B. Headless -p with JSON output, a read-only allowlist, and plan mode is non-interactive, machine-readable and edit-free. Interactive plan mode (A) and Desktop (D) are not headless; bypassPermissions (C) removes safeguards and does not guarantee read-only.

Q16 · A developer adds 'never force-push' to `./CLAUDE.md` and expects it to be enforced. Why is this insufficient, and what should they do? (Select one)

A. It is sufficient; CLAUDE.md rules are enforced. B. CLAUDE.md is guidance, not enforcement; add Bash(git push --force:*) to permissions.deny (ideally via managed policy) or a PreToolUse hook. C. Move the sentence to settings.local.json. D. Raise the model’s effort level.

Answer: B. Prose in CLAUDE.md is a suggestion (anti-pattern #3 in Claude Code form); a deny pattern or PreToolUse hook enforces it deterministically. It is not sufficient (A); a local file (C) is personal and not enforcement; effort (D) is irrelevant.

Q17 · During a long session context is nearly full but the developer must keep the working narrative. Which command fits, and how does it differ from the alternative? (Select one)

Answer: B. /compact summarises to free context while keeping continuity; /clear resets everything. /init (C) bootstraps a CLAUDE.md; /memory (D) edits memory files, not the live transcript.

Q18 · A team wants coding standards shared with everyone, but one developer needs a personal experimental instruction that must never be committed. Where does each belong? (Select one)

A. Both in ./CLAUDE.md. B. Standards in checked-in ./CLAUDE.md; the personal experiment in git-ignored CLAUDE.local.md. C. Both in settings.local.json. D. Both in managed policy.

Answer: B. Team standards go in the checked-in project file; personal, un-shared instructions go in the git-ignored local file. Putting the personal item in ./CLAUDE.md (A) shares it; local files (C) would hide the team standards from others; managed policy (D) is for non-overridable org rules, not personal experiments.

Key takeaways

Core components: Rules/CLAUDE.md, Skills, Commands, Agents/subagents, Agent Memory.
CLAUDE.md precedence composes broad→narrow: managed → user → project → subdirectory; CLAUDE.local.md is git-ignored; @path imports pull in shared files; secrets never belong here.
settings.json composes across the same scopes; permissions (allow/ask/deny) enforce tools deterministically; deny beats allow and managed policy is non-overridable.
Hooks (PreToolUse, PostToolUse, UserPromptSubmit, Stop, SubagentStop, SessionStart, Notification, PreCompact) are deterministic; exit code 2 blocks the action — the way to enforce critical rules instead of prose.
Skill = auto/progressive capability; slash command = user-invoked prompt with $ARGUMENTS; subagent = isolated context with its own prompt, tools allowlist and model.
Plan mode explores read-only and proposes a plan before edits — the safe first step for large/risky changes.
Headless -p + --output-format json|stream-json + --allowedTools + --permission-mode for CI; bypassPermissions only in a trusted sandbox.
Session commands: /compact (summarise, keep narrative) vs /clear (reset); /init, /memory, /agents, /hooks, /mcp, /cost. MCP scopes: local (personal), project (.mcp.json, shared/checked-in), user (your projects).
Permission resolution is deny > ask > allow, composing broad→narrow, with managed policy non-overridable — a non-overridable block must live in managed policy, not project or local settings.
Both CLAUDE.md and settings.json compose across the same scopes; team standards go in checked-in project files, personal items in git-ignored local files, and secrets in neither.
A rule you need enforced is a deny pattern or a hook, never a CLAUDE.md sentence (anti-pattern #3 in Claude Code form).