3.1–3.2 Core Components and the CLAUDE.md Hierarchy
3.1.1 The Five Core Component Types
Claude Code is Anthropic's agentic coding tool — it runs in the terminal (and inside IDEs and CI pipelines) and acts directly on a repository rather than just chatting about one. This domain is small, just 3.1% of the exam, but it's concrete: it tests whether you can actually operate the tool, starting with knowing its five core component types. Each one solves a different operational problem, and the exam consistently probes whether you can tell them apart rather than lumping them together as "ways to customize Claude Code."
Rules are standing, always-on conventions — coding style, do/don't rules — that Claude Code should follow continuously in a repo, often expressed inside CLAUDE.md. Skills are packaged, reusable capabilities defined by a SKILL.md file (instructions plus optional scripts or resources) that Claude loads automatically when it judges the current task relevant. Commands are slash commands — both built-in (/clear, /init, /help) and custom Markdown prompt files a developer authors under .claude/commands/. Agents are subagents with a focused role and a focused tool set that Claude Code can delegate a subtask to. And Agent Memory is persisted context — most visibly CLAUDE.md — that survives across turns and sessions so Claude doesn't have to be re-told the same project conventions every time.
| Component | What it is | How it's invoked |
|---|---|---|
| Rules | Standing conventions the repo should always follow, often in CLAUDE.md | Passive — always on, never explicitly called |
| Skills | Packaged capability defined by a SKILL.md (instructions + optional scripts/resources) | Implicit — loaded when Claude judges it relevant |
| Commands | Built-in (/clear, /init, /help) or custom Markdown files in .claude/commands/ | Explicit — invoked by name, e.g. /command-name |
| Agents | Subagents with a focused role and tool set | Delegated — the main agent hands off a subtask |
| Agent Memory | Persisted context, notably CLAUDE.md, across turns/sessions | Automatic — pulled into context every session |
Five component types, five different operational shapes. The exam rewards knowing which one fits a described need, not just recognizing the names.
The one idea to hold onto
CLAUDE.md is the primary, most visible instance of Agent Memory — not a separate mechanism sitting alongside it. If a question describes persisted, cross-session project context, it's pointing at Agent Memory, and CLAUDE.md is how that usually looks in practice.
3.1.2 Skills vs. Commands: The Invocation Discriminator
The pairing that trips people up most in this task statement is Skills vs. Commands, because both are authored as reusable, markdown-based instructions. The discriminator the exam actually tests is invocation, not authorship format: a Command is explicitly named and called — you type /command-name and it runs. A Skill is loaded implicitly, based on relevance — Claude decides, by reading the current task, that a packaged SKILL.md capability applies, and pulls it in without anyone typing its name.
- •A Command requires the developer (or Claude) to name it explicitly — nothing happens until /command-name is invoked.
- •A Skill requires no explicit invocation — Claude loads it automatically once it judges the task matches what the SKILL.md packages.
- •Both can bundle multi-step instructions and even scripts/resources — the difference is entirely about who decides when it fires, and how.
3.1.2 — Exam Trap
Exam trap: treating Skills and Commands as the same thing because both are markdown-authored and reusable. They're distinguished purely by invocation — implicit/relevance-based (Skill) vs. explicit/named (Command) — not by format or authoring effort.
3.1.3 Built-in vs. Custom Slash Commands
Within the Commands component type itself, there's a second distinction worth knowing cold: built-in vs. custom. Claude Code ships with built-ins for common actions — /clear resets the conversation context to keep it focused, /init bootstraps a starter CLAUDE.md by analyzing the existing codebase, and /help lists available commands. None of these require any setup; they exist the moment you open Claude Code.
Custom slash commands are different: a developer authors them as Markdown prompt files placed in .claude/commands/, each one encoding a repeated workflow — a prompt template — that would otherwise mean re-typing (or re-explaining) the same multi-line instruction every session. Once authored, a custom command is invoked exactly like a built-in one, by name. It is just as much a "slash command" as /clear or /init; the only difference is who authored it and where it lives, not the invocation mechanism.
- •Built-in: /clear (reset context), /init (bootstrap CLAUDE.md), /help (list commands) — no setup required.
- •Custom: Markdown prompt files under .claude/commands/, authored to encode a repeated workflow once.
- •Both are invoked the same way, by name — custom commands are not a lesser or different category of slash command.
3.1.3 — Key Concept
Anthropic's own operational guidance is to tighten a workflow "with custom commands and hooks rather than long, brittle prompts" — i.e., encode a repeated procedure once as a command instead of re-explaining it every session. This is the throughline connecting Commands back to the best-practice loop covered later in 3.4.
3.1.4 .claude/rules/ Instruction Files: Scope Comes From Frontmatter, Not Folders
CLAUDE.md is the always-on baseline covered in 3.2 -- it loads into every session, unconditionally. Rules instruction files are a distinct mechanism that adds a narrower layer on top of that baseline: they let a piece of guidance apply only where it's relevant, instead of loading into every session and diluting the file that's supposed to hold universal context. Rules files live in a project's .claude/rules/ directory, one Markdown file per rule (or per related group of rules), each carrying a YAML frontmatter block at the top.
Here is the fact worth knowing cold: a rules file's scope is controlled entirely by a paths glob declared in its YAML frontmatter -- not by which subdirectory of .claude/rules/ the file happens to live in. Placing a file at .claude/rules/database/transactions.md versus .claude/rules/transactions.md has zero effect on when it loads; only the paths field does that. Subdirectory organization under .claude/rules/ is purely cosmetic bookkeeping for humans browsing the folder -- it carries no scoping meaning to Claude Code itself.
---
paths:
- "src/db/**/*.sql"
---
All SQL in this module must include an explicit transaction boundary.3.1.4 -- Exam Trap
A rules file with no paths frontmatter at all loads unconditionally, at session start, with the same standing as CLAUDE.md -- omitting paths doesn't mean 'loads nowhere,' it means 'loads everywhere, always.' Don't assume a rules file's location inside .claude/rules/ determines its scope: only the paths field does. Broad, universal constraints belong in CLAUDE.md; narrow, path-specific guidance belongs in a rules file scoped with paths.
3.1.5 Plugin Marketplaces and Portable Path Variables
A plugin packages skills, hooks, subagents, and MCP server configs together as one installable unit. Rather than a teammate rebuilding your setup by hand, a plugin turns it into a versioned, auditable install -- one command, and the recipient ends up with an exact copy of what the author built. Plugins ship through a marketplace, a catalog of plugins someone has already assembled and shared. Anthropic's own marketplace is there automatically the moment Claude Code launches; a third-party one has to be added on purpose, usually hosted in a GitHub repo and registered with something like /plugin marketplace add <owner/repo>.
- •Managed marketplace allowlist -- a permission gate on which marketplace sources a user may add at all; it restricts, but doesn't register anything for them automatically.
- •extraKnownMarketplaces (managed settings) -- registers a marketplace on every user's behalf, so nobody has to manually run /plugin marketplace add.
- •Managed settings outrank user- and project-level settings in the configuration hierarchy, so anything pushed at the managed tier can't be overridden by an individual's local config.
A plugin that installs cleanly everywhere can still fail for everyone except its author. Picture a plugin's SKILL.md containing a command that points at /Users/alexmorgan/projects/deploy-utils/validate.sh. That absolute path exists on Alex's laptop and nowhere else -- installation succeeds for every teammate, because installation just copies files into place, but the moment anyone actually runs the skill, the script can't be found, because execution resolves that path against the machine it's running on. A quieter version of the same problem: a skill that silently depends on an environment variable the author happened to have set in their own shell profile, with the dependency never documented anywhere -- the skill runs fine right up to the step that needs it, then fails.
| Variable | Resolves to | Use for |
|---|---|---|
| $CLAUDE_PROJECT_DIR | The root of the project the session is running in | Scripts that live in the project itself, referenced relative to its root |
| ${CLAUDE_PLUGIN_ROOT} | The plugin's own installed location | Scripts bundled inside the plugin, so they resolve no matter whose machine installed it |
Replacing a hard-coded absolute path with one of these two variables is what makes a plugin's scripts resolve correctly regardless of who cloned the project or where the plugin landed.
3.1.5 -- Key Concept
A successful plugin install proves the package was assembled correctly -- it does not prove the plugin will run. Document every environment variable a plugin requires and validate it at install time, and test the install on a clean machine before distribution, so an absolute-path or missing-variable failure surfaces before it costs a teammate hours of debugging.
3.2.1 CLAUDE.md as Hierarchical Project Memory
CLAUDE.md is a special Markdown file that Claude Code automatically pulls into context as project memory — architecture notes, conventions, common commands, gotchas: the standing context Claude should have on every turn without being re-told. It is not a place to write executable rules or permissions; it's read by the model as context, which makes it probabilistic in effect rather than a hard enforcement mechanism (more on that distinction in 3.3).
What makes CLAUDE.md distinctive is that it's hierarchical, merged from four levels, broadest to most specific: enterprise/system (organization-wide policy, managed centrally), user (~/.claude/CLAUDE.md — one developer's personal defaults across all their projects), project (./CLAUDE.md, checked into the repo — shared team conventions for that codebase), and subdirectory (deeper CLAUDE.md files further into the tree, for guidance specific to that part of the code). More specific files layer on top of broader ones rather than replacing them — a subdirectory file refines what the project, user, and enterprise levels already established.
Broadest to most specific: enterprise, then user, then project, then subdirectory. Each level layers on top of the ones above it — nothing is discarded or overridden wholesale.
The one idea to hold onto
Because project-level CLAUDE.md is committed to version control, the whole team shares identical guidance — it is not each developer's personal preference file. That role belongs specifically to the user-level file at ~/.claude/CLAUDE.md, which never leaves an individual's machine.
3.2.2 Bootstrapping with /init, and the Line CLAUDE.md Never Crosses
You don't have to start a project-level CLAUDE.md from a blank page. Running /init in a repo analyzes the existing codebase and generates a starter CLAUDE.md automatically — Claude Code inspects the project's structure, conventions, and commands and writes an initial file a team can then refine, rather than everyone hand-drafting one from scratch.
The trap this task statement sets most often is conflating CLAUDE.md with settings.json. CLAUDE.md is memory and instructions loaded into the model's context — the model reads it and generally follows it, but that's a probabilistic influence, not a structural guarantee. Permissions, hooks, and tool allow/deny lists are executable configuration, and they live in settings.json, not CLAUDE.md, precisely because they need to be enforced outside the model's discretion. Lesson 3.3 covers settings.json in full; for now, the discriminator to hold onto is simply: CLAUDE.md is what Claude reads, settings.json is what constrains what Claude can do regardless of what it reads.
| CLAUDE.md | settings.json | |
|---|---|---|
| Nature | Context/memory loaded into the model's prompt | Executable configuration enforced outside the model |
| Contains | Conventions, architecture notes, commands, gotchas | Tool allow/deny lists, hooks, env vars, model choice, MCP servers |
| Bootstrapped by | /init, from the existing codebase | Authored directly by a developer/team |
Same repo, two different files, two different jobs — memory the model reads vs. configuration that constrains it regardless of what it reads.
3.2.2 — Exam Trap
Exam trap: an answer that suggests storing permission rules, hooks, or a tool allow/deny list inside CLAUDE.md. That's always wrong — CLAUDE.md cannot structurally block an action the way a settings.json rule or hook can, because CLAUDE.md is context the model reads, not configuration enforced independently of it.
Key Takeaways
- ✓The five core component types are Rules, Skills, Commands, Agents, and Agent Memory — each solving a distinct operational problem.
- ✓Rules are passive and always-on; Skills load implicitly on relevance; Commands are invoked explicitly by name; Agents are delegated focused-role subtasks; Agent Memory persists context across sessions.
- ✓The Skill vs. Command discriminator is invocation — implicit/relevance-based (Skill) vs. explicit/named (Command) — not authoring format.
- ✓Built-in slash commands (/clear, /init, /help) require no setup; custom slash commands are Markdown files a developer authors under .claude/commands/ — both are invoked identically, by name.
- ✓CLAUDE.md is hierarchical project memory merged from four levels — enterprise/system, user (~/.claude/CLAUDE.md), project (./CLAUDE.md), subdirectory — with more specific files layering on top of broader ones.
- ✓Project-level CLAUDE.md is committed to version control so a whole team shares the same guidance; /init bootstraps a starter CLAUDE.md by analyzing the existing codebase.
- ✓CLAUDE.md is memory/instructions loaded into context (probabilistic); permissions, hooks, and tool allow/deny rules belong in settings.json (executable), never in CLAUDE.md.
- ✓Rules files (.claude/rules/) add a narrower, path-scoped layer on top of CLAUDE.md; scope is controlled entirely by a paths glob in YAML frontmatter, not by which subdirectory the file sits in -- a rules file with no paths field loads unconditionally, exactly like CLAUDE.md
- ✓A plugin packages skills, hooks, subagents, and MCP server configs as a single install distributed through a marketplace; Anthropic's own marketplace is there by default, adding a third-party one requires /plugin marketplace add <owner/repo>, and managed settings (allowlist plus extraKnownMarketplaces) control how it rolls out org-wide
- ✓A plugin that installs successfully everywhere can still fail everywhere but the author's machine if it hard-codes an absolute path or an undocumented env var -- $CLAUDE_PROJECT_DIR and ${CLAUDE_PLUGIN_ROOT} are the portable fixes
Check Your Understanding
Test what you learned in this lesson.
Q1.A team wants Claude Code to automatically load a packaged set of instructions and scripts whenever a task matches what they cover, with no one typing a command name. Which component type fits?
Q2.What is the most accurate description of the relationship between CLAUDE.md and Agent Memory?
Q3.A developer wants the same coding conventions applied automatically for every member of a team working in a shared repository. Which is the correct mechanism?
Q4.Where should a rule blocking a specific tool from being used at all be enforced, and why?
Q5.A rules file sits at .claude/rules/database/transactions.md with no paths field in its frontmatter. When does it load?
Q6.A plugin's SKILL.md calls a script using the absolute path /Users/alexmorgan/projects/deploy-utils/validate.sh. It installs successfully for every teammate but fails the moment anyone else runs it. What is the correct fix?
Practice This Lesson