Claude Code Core Components: Rules, Skills, Commands, Agents, Memory

The five building blocks

Claude Code is not a single monolithic assistant you configure with one file. It is assembled from a small set of named components, and the Claude Certified Developer - Foundations (CCDV-F) exam expects you to identify each one and say what it is for. There are five: Rules, Skills, Commands, Agents, and Agent Memory. Learn them as a set, because the exam questions at this level are recognition questions, they name a behaviour and ask which component provides it, or they name a component and ask what it does.

The unifying idea is that these five pieces compose. None of them is the whole system; each contributes one kind of customisation, and a well set up repository uses several of them together to shape how Claude Code operates in that specific codebase. Grasp the individual purpose of each block and the composition follows naturally.

Rules encode conventions

Rules are how you tell Claude Code the conventions of a project: the standards, preferences, and standing instructions it should follow while it works. A rule is not something you invoke on demand; it is context that is in force by default, steering behaviour across the whole session. When a team writes down that commit messages follow a particular format, or that a certain directory is off limits, those are rules. They are the encoded conventions that make the assistant behave like a member of that specific team rather than a generic tool.

Because rules are always-on guidance rather than a triggered action, they belong to the same family as the project's configuration. This is why they sit close to the CLAUDE.md and settings.json configuration that anchors a repository: rules are the conventions, and the configuration files are where much of that convention lives.

Skills package reusable procedures

A Skill packages a reusable procedure so Claude can carry it out consistently whenever it is relevant. Think of a Skill as a self-contained capability, the steps, context, and know-how for doing one kind of task well, bundled so it can be reused across sessions and shared across a team. When a repeated task has a right way to be done, capturing that method as a Skill means Claude does not have to be re-taught it every time.

The word to hold onto is procedure. A Skill is knowledge about how to do something, packaged to be drawn on. That is different from an action a user fires off by name, which is the very distinction the exam probes and the reason Skills and Commands are so easy to confuse. Skills also sit alongside other extension mechanisms in the Claude ecosystem, and the Skills versus MCPs comparison is worth studying once you can define a Skill cleanly on its own.

Commands are invokable slash actions

A Command is an invokable slash action: something a user triggers explicitly by typing its name, like /review or /deploy. Where a Rule is passive context and a Skill is a packaged procedure Claude may draw on, a Command is an action a person deliberately invokes. The trigger is the giveaway. A Command runs because someone called it; it is a named entry point into a repeatable prompt or workflow.

This is the single sharpest line in the whole knowledge point. A Skill is a procedure Claude can use when appropriate; a Command is an action a user invokes on purpose. Both package repeatable work, which is exactly why they blur together, but they differ in how they are activated. Keep "invoked by name" attached to Command and "packaged procedure Claude draws on" attached to Skill, and the most common exam trap on this topic disappears.

Agents are configured subagents

An Agent, in Claude Code's component vocabulary, is a configured subagent: a specialised assistant set up to handle a particular kind of work with its own instructions and focus. Rather than doing everything in one undifferentiated context, you can define agents that each own a slice of the problem, and Claude Code can delegate to them. This is the component that makes division of labour possible inside a single tool.

Because an agent runs with its own configuration and its own working context, agents are the mechanism behind context isolation through subagents: giving a focused task a clean context of its own instead of letting everything pile into one conversation. For this knowledge point you only need to identify what an Agent is, a configured subagent, but knowing why you would reach for one makes the definition stick.

Agent Memory persists durable context

Agent Memory is the component that persists durable context across a session, so useful facts and decisions are not lost as work proceeds. Without it, everything the assistant knows lives only in the immediate conversation; with it, there is a place for context that should survive and stay available. Memory is what lets Claude Code carry forward the things it has learned or been told, rather than starting cold each time attention moves on.

Hold the contrast with Rules clearly. Rules are conventions you author up front to steer behaviour; Agent Memory is durable context that accumulates and persists as the session runs. One is standing instruction, the other is retained state. Both provide context, but they are not the same component, and the exam can reward you for keeping them distinct.

How the components compose

The reason to learn these as a set is that they are designed to work together. A repository might carry Rules that fix its conventions, a handful of Skills that capture its recurring procedures, Commands that expose common workflows as one-line invocations, Agents that own specialised subtasks, and Agent Memory that holds the durable context all of that work depends on. No single component customises Claude Code; the composition does. That compositional view is what turns five definitions into a mental model you can reason with.

What the exam trips candidates on

The CCDV-F exam tests two specific confusions on this knowledge point, and both are easy to inoculate against once you know they are coming.

The first is confusing a Skill with a Command. A Skill is a packaged procedure Claude draws on; a Command is an action a user invokes by name. They feel interchangeable because both bundle repeatable work, but the activation model is different, and the exam will offer a definition of one under the label of the other. Anchor on the trigger: if it is invoked by name, it is a Command; if it is a reusable procedure Claude uses when appropriate, it is a Skill.

The second is assuming these components are global rather than scoped. It is tempting to imagine that a Rule or a Skill applies everywhere, but these components are scoped, typically to a project or a user. A convention set for one repository does not silently govern another. When a question implies a component applies universally, treat that universality as a red flag, scoping is the norm, not the exception.

Common misreadings to avoid

How it shows up on the exam

Domain 3, Claude Code, is a focused, lower-weighted domain, and this knowledge point sits at its foundation as a remember-level item under task statement 3.1. Questions here are recognition questions: they hand you a description of a behaviour and ask which of the five components provides it, or they name a component and ask for its purpose. You will not be asked to configure anything at this level, only to identify.

Get the five definitions crisp and the two traps memorised and you can answer these quickly. The distinctions that earn the marks are Skill versus Command, procedure versus invoked action, and scoped versus global. Once the components are solid, the next knowledge point builds on them by asking how you actually run Claude Code, through session management, headless mode, and custom slash commands, which is where the Commands you can now define get put to work.