Glossary — Learn Claude Code

A

AGENTS.md: A convention used by other coding harnesses for project-level instructions. Claude Code reads CLAUDE.md, not AGENTS.md; bridge the two with an @AGENTS.md import inside CLAUDE.md, or a symlink on platforms that support one. See Rules.
allowed-tools: A skill or subagent frontmatter field that restricts which tools the invocation may use. On a skill, the grant clears at the end of your next message rather than persisting for the session, and it is not gated by workspace trust: a project skill can grant itself broad access even in an untrusted folder. See Skills.
auto memory: A background feature, on by default, that writes what Claude Code learns about a project or user into ~/.claude/projects/<project>/memory/ as a MEMORY.md index plus topic files. Subagents do not inherit it, except forks. Toggle with /memory or autoMemoryEnabled: false.

C

example plugin: The plugin this series builds one directory at a time. Each module ships one subdirectory (skills/, agents/, hooks/hooks.json, and so on), and the final module packages the whole thing behind .claude-plugin/plugin.json and validates it with claude plugin validate --strict.
.claude-plugin/: The one directory inside a plugin reserved for plugin.json. Every other component (skills/, agents/, hooks/, and the rest) lives at the plugin root, not inside this folder. See the plugin layout table.
CLAUDE.md: The file Claude Code reads at every level from the filesystem root down to your working directory. Unlike settings, memory files never override each other: every discovered file concatenates into context, in root-to-cwd order, with CLAUDE.local.md appended last in each directory. See Rules.
command (legacy): A flat file in .claude/commands/<name>.md, invoked by its file name. Commands still work but the docs describe them as merged into skills: a skill directory supports supporting files and more frontmatter, so new work should use .claude/skills/<name>/SKILL.md instead. See Your first command.

E

effort: A frontmatter field on skills and subagents, one of low | medium | high | xhigh | max, that sets how much reasoning budget the invocation gets. Available at ${CLAUDE_EFFORT} for substitution inside a skill body.
exit code 2: The hook exit code that blocks a tool call through the code alone, for most events. Exit 0 with no output is not approval; it is no decision, and the normal permission flow continues. Exit 1 does not block by itself. Claude Code reads JSON on stdout at every exit code, not only 0, so a hook that exits 1 while also printing a valid JSON decision still has that decision take effect. WorktreeCreate is the one event where any non-zero exit blocks, and PermissionRequest ignores exit 2 entirely, deciding only through the JSON decision field. See the hook decision table and Hooks.

H

handler: One executable step inside a hook's matcher group. Five types exist: command, http, mcp_tool, prompt, and the experimental agent. All handlers matched by an event run in parallel. See Hooks.
hook: A deterministic script or call that Claude Code runs at a defined point in its lifecycle, configured under the hooks key in a settings file or a plugin's hooks/hooks.json. Three levels of nesting: event, matcher group, handlers. See Hooks.
hook event: One of 31 documented points in the session lifecycle (PreToolUse, Stop, SessionStart, and so on) that a hook can attach to. Not every event can block: only a subset, including PreToolUse, UserPromptSubmit, and Stop, honor exit 2.

I

if filter: An optional hook field holding exactly one permission rule, evaluated only on the five tool-related events (PreToolUse, PostToolUse, PostToolUseFailure, PermissionRequest, PermissionDenied). On any other event, a hook with if set never runs: it is not silently ignored, it is fully suppressed. The filter also fails open: an unparseable Bash command still runs the hook. It has no &&, ||, or list syntax, and it is not a substitute for the permission system.

M

managed settings: Organization-controlled configuration written by an administrator, loaded from a fixed OS path outside any project. It wins over every other settings file, including command-line flags, and a managed permission rule can never be overridden by a lower level. See Settings and themes.
marketplace: A .claude-plugin/marketplace.json manifest listing installable plugins by name and source. Adding a marketplace with claude plugin marketplace add makes its plugins available to /plugin install; it does not enable them.
matcher: The pattern a hook's matcher group uses to decide which tool calls it applies to. *, an empty string, or omitting it matches everything. A string built only from letters, digits, _, -, spaces, commas, and | is an exact match or an exact-match list; anything else is treated as an unanchored JavaScript regular expression.
MCP: Model Context Protocol: the open, vendor-neutral standard Claude Code uses to connect to external tool servers, declared in .mcp.json. It is the one surface the docs describe as portable across harnesses. See MCP.
MCP resource: Content an MCP server exposes for reference, addressed as @server:protocol://resource/path (for example @github:issue://123) and attached to a prompt with @ autocomplete. Distinct from an MCP tool, which the model calls rather than attaches.
MCP server: A process or endpoint speaking MCP, configured with a type of stdio, http, sse (deprecated), or ws. Scopes are local (this project, not shared), project (.mcp.json, checked into version control), and user (every project). See MCP.
mcp__server__tool: The runtime name of an MCP tool: server name and tool name joined by double underscores, for example mcp__github__list_issues. This is the form to use in permission rules, a skill's allowed-tools, a subagent's tools list, and hook matchers. A plugin-supplied server's tools carry an extra plugin_<plugin-name>_ segment.

O

output style: A file in output-styles/ that modifies the system prompt rather than appending a user message. It takes effect only after /clear or a new session, does not apply to subagents except forks, and across nested project directories the definition closest to your working directory wins. See Shaping the model.

P

permission mode

The session-wide setting that decides how much Claude Code asks before acting: default (read-only, called Manual in the UI), acceptEdits, plan, auto (a classifier reviews actions instead of you), dontAsk (auto-denies anything not pre-approved), and bypassPermissions (skips prompts, including protected-path writes). See Permissions and sandbox.

permission rule

One entry in permissions.allow, ask, or deny, written as Tool or Tool(specifier). Rules evaluate deny, then ask, then allow, first match wins, and specificity never matters: a broad deny beats a narrower allow. A bare tool name in a deny rule removes the tool from Claude's context entirely, rather than merely blocking calls to it.

precedence

Which definition wins when two sources define the same name. This is not one rule: it differs, and sometimes inverts, per surface.

Precedence order per surface
Surface	Highest to lowest
Skills	enterprise > personal > project
Subagents	managed > `--agents` > project > user > plugin
Settings	managed > CLI > project-local > shared project > user

The pair that trips people

Skills and subagents invert against each other. For skills, your personal definition beats the project's. For subagents, the project's definition beats yours. Generalizing from one surface to the other produces a bug that both surfaces will load without complaint about.

See the full precedence table, which also covers settings and CLAUDE.md.

progressive disclosure

The economics behind a skill's two-part loading: its description stays in context for the whole session so Claude can decide when to reach for it, while the body of SKILL.md and any supporting files load only when the skill is actually invoked. See Skills.

protected path

A directory or file (.git, .claude, shell startup files, .mcp.json, and others) whose writes are never auto-approved by an allow rule, in any mode except bypassPermissions. The check runs before allow rules are even read, so a permission rule cannot pre-clear it.

R

.claude/rules/: A directory of markdown files, discovered recursively, that load with the same priority as a project's CLAUDE.md. The only supported frontmatter field is paths, a list of globs scoping when the rule loads; without it, a rule loads unconditionally at launch. See Rules.

S

sandbox: The built-in isolation layer for Bash and PowerShell commands: Seatbelt on macOS, bubblewrap plus socat on Linux and WSL2. By default it allows writes to the working directory and the session temp dir, and reads almost the entire filesystem except explicitly denied paths. It is not a substitute for a container: the docs are explicit that bypassPermissions depends on whatever isolation boundary you choose. See Permissions and sandbox.
settings precedence: The five-level order settings files resolve in: managed, then command-line arguments, then project-local (.claude/settings.local.json), then shared project (.claude/settings.json), then user (~/.claude/settings.json). List-valued keys such as permissions.allow merge across levels rather than one replacing another; a few whole-value keys like fallbackModel are exceptions. See the precedence table.
skill: A directory under .claude/skills/<name>/ (or ~/.claude/skills/, or a plugin's skills/) containing a SKILL.md and optionally supporting files or scripts. Skills are the current, merged form of both slash commands and reusable capabilities: the docs state outright that custom commands have been merged into skills. See Skills.
SKILL.md: The required file inside a skill directory. Every frontmatter field is optional; only description is recommended, since that is what tells Claude when to use the skill. The directory name, not the frontmatter name field, determines what you type to invoke a personal or project skill.
subagent: A separately configured agent, defined in a markdown file under .claude/agents/, with its own system prompt, tool allowlist, and model. It runs in an isolated context window and does not inherit the main session's conversation history, output style, or auto memory. name and description are the only required fields. See Subagents.
system prompt: The instruction block set once at the start of a conversation, distinct from a user message. Output styles modify it directly; --append-system-prompt adds to it from the command line. Understanding this split is the point of Shaping the model.

T

theme: A named color scheme for the CLI interface, selected with the theme setting. Custom themes live at ~/.claude/themes/<slug>.json, with three optional fields (name, base, overrides) and hot reload; an invalid token is ignored rather than breaking the theme. See Settings and themes.
tool search: The mechanism that keeps large MCP tool catalogs out of context by default: only tool names and server instructions load at session start, and full schemas fetch on demand. Controlled with ENABLE_TOOL_SEARCH; a server can opt out of deferral with alwaysLoad: true.

W

workspace trust: The one-time dialog a project asks you to accept before its permissions.allow rules and additionalDirectories take effect. deny and ask rules apply immediately regardless of trust. Trust is keyed to the git repository root, and a headless -p run never sees the dialog at all. See Permissions and sandbox.