Skip to content
Domain 3
3.1%

Quick Reference: Domain 3 — Claude Code

The Five Components, and Where Each Lives (3.1)

The guide names Rules, Skills, Commands, Agents and Agent Memory. Each one is a file you can open, and nearly every item in this domain is a placement question: given a stated need, which family and which scope.

ComponentWhat it isWhere it lives
RulesMarkdown constraints; a project rule loads at launch with the same priority as .claude/CLAUDE.md, and paths frontmatter scopes a rule to matching files. User rules load first, but neither set overrides the other, so Claude may follow either where they conflict.claude/rules/, ~/.claude/rules/, plus the permissions block in settings.json
SkillsA directory holding a SKILL.md; the body loads only when used, invoked by description match or as /skill-name. skillOverrides in settings changes its visibility without editing it.claude/skills/<name>/, ~/.claude/skills/<name>/, managed settings, plugins
CommandsBuilt-in slash commands running fixed CLI logic, bundled prompt-based skills such as /doctor, and custom commands, which have merged into skillsThe CLI itself; .claude/commands/<name>.md
AgentsSubagents with name and description required in frontmatter; each runs in its own context window and only its final result returns.claude/agents/, ~/.claude/agents/
Agent MemoryAuto memory, the notes Claude keeps for itself; the MEMORY.md index loads at the start of every conversation, capped at its first 200 lines or 25KB. autoMemoryEnabled: false in project settings turns it off for one repository~/.claude/projects/<project>/memory/

Collisions. A skill and a command file of the same name both create /name, and the skill wins. Across scopes, skill collisions resolve enterprise over personal over project, the exact inverse of settings precedence, and a favourite trap. Subagent names follow the settings direction instead: managed, then --agents JSON, then .claude/agents/, then ~/.claude/agents/, then plugins. Both invocable kinds take arguments through $ARGUMENTS, with $0 and $1 indexing positions zero-based, so $0 is the first argument.

Around the five (September 2026).

  • skillOverrides: user-invocable-only hides a skill from Claude but keeps /name working, name-only lists it without its description, off hides it everywhere. The /skills menu saves the choice to .claude/settings.local.json.
  • Subagent model: a definition's model, or one Claude passes at spawn time, outranks CLAUDE_CODE_SUBAGENT_MODEL. Add CLAUDE_CODE_SUBAGENT_MODEL_FORCE=1 to put every subagent on that model (needs v2.1.257 or later; forks and model: inherit skills still use the main model).
  • Subagent permissionMode: ignored while the main session is in acceptEdits, auto or bypassPermissions; the subagent takes the parent's mode. To stop a subagent editing in every mode, leave editing tools out of its tools list.
  • Plugins: skills, subagents, hooks and MCP servers packaged as one unit. A repository shares a private marketplace's plugin through extraKnownMarketplaces and enabledPlugins in its .claude/settings.json; the marketplace entry applies once a contributor trusts the folder. Managed settings carry the same two keys fleet-wide.
  • Output styles: .claude/output-styles/ or ~/.claude/output-styles/, chosen with outputStyle. On the full system prompt, a custom style drops Claude Code's software engineering instructions unless its frontmatter sets keep-coding-instructions: true; the shorter system prompt never carries them.

The line that settles most placement items: CLAUDE.md is what you write for Claude, auto memory is what Claude writes for itself. Both are context. Neither enforces anything.

CLAUDE.md Concatenates (3.1)

Four scopes, broadest first:

  1. Managed policy: /Library/Application Support/ClaudeCode/CLAUDE.md (macOS), /etc/claude-code/CLAUDE.md (Linux and WSL), C:\Program Files\ClaudeCode\CLAUDE.md (Windows). Deployed by IT, not excludable by individual settings.
  2. User: ~/.claude/CLAUDE.md, following you into every project.
  3. Project: ./CLAUDE.md or ./.claude/CLAUDE.md, shared through version control.
  4. Local: ./CLAUDE.local.md, personal and gitignored.

Discovered files are concatenated into context, never overridden: a more specific file lands after a broader one rather than replacing it. Claude Code walks up the directory tree from the working directory, so a session launched in foo/bar/ reads foo/CLAUDE.md before foo/bar/CLAUDE.md, each CLAUDE.local.md after its sibling. Files in subdirectories below load on demand when Claude reads there.

  • @path/to/import pulls in content from anywhere in a CLAUDE.md. Relative paths resolve against the file containing the import, imports expand at launch, and recursion stops at a maximum depth of four hops. A path in backticks stays literal.
  • /init is repository initialisation: Claude analyses the codebase and writes a starting CLAUDE.md of build commands, test instructions and conventions. Where one already exists it suggests improvements rather than overwriting.
  • /context proves what actually loaded, under Memory files. /memory opens any of it for editing.
  • claudeMdExcludes (September 2026) skips CLAUDE.md and rules files by path or glob, from any settings file; managed policy files cannot be excluded. In .claude/settings.local.json it keeps another team's file out of your sessions only.
  • AGENTS.md (v2.1.277 or later) loads by default only when no CLAUDE.md, .claude/CLAUDE.md or CLAUDE.local.md exists in the working directory or above, so a personal CLAUDE.local.md switches it off. Project instructions set to claude-md-and-agents-md in /config loads both; Claude Code ignores that value in project and local settings files.

settings.json Overrides (3.1)

Settings run the other way, as a genuine precedence chain:

RankSourceNotes
1Managed settingsThe OS policy directory; cannot be overridden
2Command line argumentsTemporary session overrides
3.claude/settings.local.jsonPersonal per-project state, auto-gitignored
4.claude/settings.jsonThe team baseline, checked in
5~/.claude/settings.jsonApplies when nothing else specifies the setting

Local beats project beats user is the order items key on for a single value such as model, and the middle boundary is where candidates slip: being checked in confers no rank. List settings such as permissions.allow merge across files (September 2026), so a local file can add entries but never remove a shared one. To prompt for a command the team allows, add an ask rule: rules are checked deny, then ask, then allow. Claude Code auto-gitignores the local file by adding **/.claude/settings.local.json to your global git excludes file, which excludes it from version control and not from loading.

Settings carry permissions (allow, ask, deny, defaultMode, additionalDirectories), hooks wiring, env, model selection, and toggles such as autoMemoryEnabled.

Workspace trust (September 2026). A cloned repository cannot grant itself capability: the permissions.allow rules and additionalDirectories in its .claude/settings.json, and .mcp.json approvals such as enabledMcpjsonServers committed there, take effect only once someone accepts the trust dialog for that folder. Deny and ask rules apply regardless.

Status line. statusLine runs your script with session JSON on stdin and re-runs it on events such as a new assistant message, so it can go quiet while the main session sits idle; refreshInterval adds a timer. Key any cache on the input's session_id, not a process ID, which changes on every run.

The sentence items are built from, verbatim from the memory page: "Settings rules are enforced by the client regardless of what Claude decides to do. CLAUDE.md instructions shape Claude's behavior but are not a hard enforcement layer." When a stem says must never, the keyed answer is configuration, not prose.

Sessions, /clear and /compact (3.1)

Sessions save continuously as local JSONL transcripts at ~/.claude/projects/<project>/<session-id>.jsonl, so exiting loses nothing.

RouteWhat it reaches
claude --continue (-c)The most recent session in the current directory
claude --resumeThe interactive picker
claude --resume <name-or-id>That specific session
/resumeAnother conversation, from inside a running session
/branch, or --fork-session on a resumeA copy of the conversation as a new session, leaving the original intact

Sessions created by claude -p or the Agent SDK stay out of both the picker and a plain claude --continue (September 2026). They still resume by ID, and claude -p --continue includes them. A resumed session brings back the conversation and the model it was using. The permission mode is fussier (September 2026): it comes back only on a terminal resume by --continue, by ID or by a unique name without -p, and even then not for bypassPermissions or plan (among a few narrower cases), which fall back to the mode a new session would start in. The picker and /resume never restore it. claude -p --resume or -p --continue starts where a new -p run would, bar one narrow plan-mode case. Launch flags do not survive a resume either: pass --add-dir, --mcp-config, --settings, --plugin-dir or --fallback-model again, or move the setting into a settings file, which is re-read at every launch.

Inside a session: /clear starts an empty context for unrelated work, and the old conversation stays on disk and resumable. /compact [instructions] replaces history with a summary so the same task continues. /context shows what is eating the window. Treating the two as interchangeable ways to free space is the standing trap: only one of them keeps the task alive.

Headless and Streaming (3.1)

claude -p (--print) is the non-interactive mechanism: prompt in, result out, piped stdin up to 10MB, exit 0 on success and non-zero on failure so scripts can branch. It starts in Manual on every plan, so scripted runs declare their own autonomy.

NeedFlags
Plain text back--output-format text (the default)
One machine-readable payload--output-format json, carrying result, session_id, cost and usage
Events as the run progresses--output-format stream-json, newline-delimited, carrying a system/init event of session metadata and ending with a result message
Token deltasstream-json plus --verbose and --include-partial-messages
Schema-conforming output--output-format json with --json-schema, read back from structured_output
Subagent text and thinking in the stream--forward-subagent-text; file each message by parent_tool_use_id, where null marks the main conversation
Autonomy for the run--permission-mode, --allowedTools (permission-rule syntax)
A scripted follow-up--continue, or --resume <session-id> captured from the JSON payload

Dated current-state note (September 2026): --bare skips auto-discovery of hooks, skills, custom commands, subagents, installed plugins, MCP servers, auto memory and CLAUDE.md. The docs recommend it for scripted and SDK calls and expect it to become the default for -p. A bare run gets what it needs by flag, such as --agents or --mcp-config. A -p run never shows the trust dialog. In a folder nobody has trusted, it ignores the project's permissions.allow rules with a stderr warning, yet without --bare it still runs the hooks in the project's settings files and connects its .mcp.json servers. Allow rules off, hooks and servers on. For a checkout you did not write, --bare or --setting-sources user keeps both out, and the allowlist goes on the command line with --allowedTools.

Invented near-miss flags are the standing distractor here: --headless, --stream and --auto do not exist.

The Permission-Mode Axis (3.1)

The guide's auto-mode feature. Config values are exact, and near-misses are the distractors:

ModeRuns without asking
default (Manual in the CLI, alias manual)Reads only
acceptEditsFile edits and the common filesystem commands mkdir, touch, rm, rmdir, mv, cp and sed, for paths inside the working directory
planReads and exploration; edits stay blocked until you approve the plan
autoWhatever a second model, the classifier, approves in your place
dontAskOnly pre-approved tools and the read-only set; anything that would have prompted is denied
bypassPermissionsEverything, for isolated containers and VMs only; --dangerously-skip-permissions is its flag form

Two rules outlive every mode: deny rules block even under bypassPermissions, and allow rules have no effect there.

Shift+Tab cycles modes mid-session and permissions.defaultMode sets where sessions start, with two exceptions in .claude/settings.json and .claude/settings.local.json. An auto value there does not take effect, and Claude Code falls back to the built-in default. Nor does bypassPermissions, which starts the session in Manual. Dated current-state note (September 2026): from Claude Code v2.1.283, interactive terminal and VS Code sessions start in auto mode on every plan and provider, while claude -p starts in Manual on every plan. A managed defaultMode only sets the starting point, and people can still switch to auto. disableAutoMode set to "disable" in managed settings takes it out of reach.

The Bash sandbox (September 2026) is a separate layer: the mode decides whether Claude asks, and the sandbox has the operating system limit what a command and its child processes can reach. sandbox.filesystem.allowWrite opens one extra writable path, such as a build cache, which the docs prefer to exempting the tool through excludedCommands. sandbox.allowUnsandboxedCommands: false closes the escape hatch in which Claude retries a blocked command outside the sandbox.

The judgement items reward: raise autonomy in proportion to isolation and reversibility. acceptEdits for edits you will read in a diff, plan before touching code you do not know, dontAsk with an explicit allowlist for CI, auto for an unattended run whose commands cannot be listed in advance, bypassPermissions only where the whole environment is disposable.