Features overview

How CLAUDE.md, output styles, skills, subagents, workflows, MCP, hooks and plugins fit together, when to reach for each, and what each costs in context.

Out of the box, Claude Code has a capable model and a solid set of built-in tools for files, search, shell and the web. That covers most coding. Everything on this page is the layer you add on top: features that teach Claude your project, connect it to other systems, and automate the things you are tired of asking for.

If you are new, start with a CLAUDE.md (see memory) and add the rest only when a real need shows up. The section Grow your setup gradually lists the signals to watch for.

Feature	What it is	Reach for it when	Example from my own setup
CLAUDE.md	Project instructions loaded into every session	Something should always be true	"Use pnpm. Migrations live in `db/migrations` and are never edited after merge."
Output style	Standing instructions on role, tone and response format	You want every answer shaped a certain way	The built-in Concise style while I am deep in a refactor
Skill	A Markdown file of knowledge or a workflow, loaded on demand	Reusable reference material or a repeatable task	`/ship-preview` that builds, deploys to a preview URL and posts the link
Code intelligence	A language server connection for symbol navigation and live diagnostics	Typed languages and large repos where grep is noisy	Jumping straight to an interface's implementations
MCP	A protocol for plugging in external tools and data	Claude needs to read from or act on another system	Querying a staging Postgres, reading tickets
Subagent	A worker with its own context window that returns a summary	Side work that would flood your conversation	"Read every controller and list the endpoints without auth"
Dynamic workflow	A script Claude writes that runs many subagents in the background	The job outgrows a few subagents, or you want findings cross-checked	A repo-wide audit with a second pass verifying each issue
Cross-session messaging	Claude passing a note from one of your sessions to another	Two sessions you are running need each other's findings	The API session warning the frontend session about a renamed field
Hook	A command, HTTP call, MCP tool call, prompt or subagent fired at a lifecycle event	Something must happen every time, without fail	Running the formatter after each edit
Artifact	A private, interactive web page published from a session	Output that reads better as a page than as terminal text	A live incident timeline

Two packaging pieces sit around all of this. A plugin bundles skills, hooks, subagents and MCP servers into one installable unit, with its skills namespaced (for example /acme-tools:review) so plugins do not collide. A marketplace is how you distribute plugins to a team or the public.

Of all these, skills are the most flexible. A skill can be pure reference ("our REST conventions"), an action you trigger with /name, something Claude loads automatically when the description matches, or a task that runs in an isolated subagent.

Grow your setup gradually

You do not need to configure everything on day one. Each feature has a trigger that tells you it is time:

You notice that...	So you add
Claude has got the same command or convention wrong twice	A line in CLAUDE.md
You keep asking for shorter answers, more explanation, or a fixed format	An output style
You type the same opening prompt to start a recurring task	A user-invocable skill
You have pasted the same multi-step playbook for the third time	A skill holding that playbook
You keep copying information out of a browser tab Claude cannot see	An MCP server for that system
Claude reads file after file hunting for where a symbol lives	A code intelligence plugin
A side investigation buries your conversation in output you will never reread	A subagent
You want something to happen automatically, every time	A hook
A second repository needs the same tooling	A plugin

The same signals tell you when to revise what you have. A correction you keep repeating in chat belongs in CLAUDE.md. A skill you keep patching by hand needs another draft.

Telling similar features apart

Skill or subagent?

A skill is content that gets loaded into a context. A subagent is a separate worker with its own context.

	Skill	Subagent
Nature	Instructions, knowledge or a workflow	An isolated worker
Main benefit	Reuse across sessions and projects	Keeps intermediate work out of your conversation
Effect on your context window	Adds to it	Runs in a separate window; only the summary comes back
Typical use	Style guides, checklists, `/deploy`	Wide searches, parallel investigations, specialist reviewers

Skills come in two flavours: reference skills that inform everything Claude does in a session, and action skills that tell it to do something specific. The two features combine nicely: a subagent can preload skills through its skills: field, and a skill can run itself in an isolated context with context: fork.

CLAUDE.md or skill?

	CLAUDE.md	Skill
Loaded	Automatically, every session	On demand
Can import other files with `@path`	Yes	Yes
Can be triggered as `/name`	No	Yes
Best for	Rules that always apply	Occasional reference, invocable workflows

My rule: if Claude should know it on every single task, it goes in CLAUDE.md. If it only matters for some tasks, it is a skill. Keep CLAUDE.md under about 200 lines, and when it grows, move reference material into skills or split it into .claude/rules/ files.

CLAUDE.md or output style?

CLAUDE.md says what is true about the project. An output style says how Claude should respond. Only one style is active at a time and you can switch whenever you like; CLAUDE.md stays loaded regardless. Neither is enforced: Claude treats both as instructions. If something has to happen every time, use a hook.

CLAUDE.md, rules or skills?

	CLAUDE.md	`.claude/rules/`	Skill
Loaded	Every session	Every session, or only when matching files are touched	When invoked or judged relevant
Scope	Whole project	Optionally limited to file paths	A particular task
Best for	Build commands, core conventions	Language- or folder-specific guidance	Reference docs, repeatable procedures

Rules with paths frontmatter are a great way to keep, say, your React conventions out of context while Claude is working on the Go backend. Memory explains the syntax.

Subagent or dynamic workflow?

With subagents, Claude decides turn by turn what to run next. In a dynamic workflow, a script Claude has written decides, running many subagents in the background and returning one consolidated result. Use a subagent for a quick focused job (research a question, check a claim, review one file). Use a workflow for codebase-wide audits, big migrations or plans you want drafted from several angles and cross-checked. Ask for one in your prompt to start it.

Subagents that Claude named when spawning them can message each other. To move a finding between two of your own top-level sessions, ask Claude to send it with cross-session messaging. Agents compares every way of running more than one Claude at once.

MCP or skill?

MCP gives Claude the ability to reach a system, with the server handling connection and authentication. A skill gives it the know-how to use that ability well. They pair naturally: an MCP server for your data warehouse plus a skill that documents the schema, the expensive tables to avoid and your house query patterns.

Hook or skill?

	Hook	Skill
What runs	A shell command, HTTP request, MCP tool call, LLM prompt or subagent	Instructions Claude reads and applies
Triggered by	A lifecycle event such as `PreToolUse`, `PostToolUse` or `SessionStart`	You typing `/name`, or Claude matching the description
Reliability	Fires every time its event happens	Depends on Claude's interpretation
Context cost	None unless the hook returns output	Description every session, body when used
Best for	Formatting, linting, blocking dangerous commands, logging, notifications	Work that needs judgement, multi-step procedures, reference

The key lesson: guardrails belong in hooks. "Never touch .env" written in CLAUDE.md is a polite request. A PreToolUse hook that rejects edits to .env is enforcement. Remember too that hook output lands in context: a PostToolUse hook that runs your linter feeds the results back for Claude to read, while a /fix-lint skill would tell Claude how to deal with them.

How the same feature at different levels combines

Features can be defined for you personally, for a project, by a plugin, or by managed organisation policy. Nested CLAUDE.md files and per-package skills in a monorepo add more layers. Here is how conflicts resolve:

Feature	Combination rule
`CLAUDE.md`	Additive. Every level contributes. Files from the working directory upwards load at launch; files in subdirectories load when Claude works there. Claude reconciles conflicting instructions using judgement
Skills	One definition wins by name: managed, then user, then project. Plugin skills are namespaced, so they never clash
Subagents	One definition wins by name: managed, then CLI flag, then project, then user, then plugin
MCP servers	One definition wins by name: local, then project, then user
Hooks	Merged. Every registered hook fires for matching events, whatever its source

Combining features

Real setups mix these. A typical one of mine for a client web app:

CLAUDE.md with build, test and deploy commands plus a handful of non-negotiables.
A path-scoped rule for the frontend's component conventions.
An MCP server for the issue tracker.
A /release skill that drafts the changelog, bumps the version and opens the pull request.
A PostToolUse hook that runs the formatter.

Some proven pairings:

Pattern	How it works	Example
Skill with MCP	MCP supplies the connection, the skill supplies the expertise	A warehouse MCP server plus a skill describing the schema and safe query patterns
Skill with subagents	A skill fans work out to parallel workers	`/audit` launching separate security, performance and accessibility reviewers
CLAUDE.md with skills	Short always-on rules point to detailed on-demand guides	`CLAUDE.md` says "follow our API conventions"; a skill holds the full guide
Hook with MCP	A hook triggers an external action through an MCP tool	Posting to a chat channel whenever Claude edits payment code

What each feature costs in context

Everything you add takes up some of the context window. Too much does not just run out of space: it adds noise, so skills trigger less reliably and conventions get lost. Context window shows this visually.

Feature	Loads	What goes into context	Ongoing cost
CLAUDE.md	Session start	The full text of every applicable file	On every request
Output style	Session start and whenever you switch	The active style's instructions (nothing for Default)	On every request
Skills	Session start, then on use	Names and descriptions up front, full body when used	Low
MCP servers	Session start	Tool names and server instructions; full schemas on demand	Low until a tool is used
Code intelligence	After edits and on lookup	Diagnostics after edits, symbol locations when asked	Low, and often saves file reads
Subagents	When spawned	Their own fresh context (or the parent conversation, for a fork)	Kept out of your session
Hooks	When their event fires	Nothing, unless they return output	Zero by default

A few details worth knowing:

Skills. Claude picks skills by matching your task against descriptions, so vague or overlapping descriptions cause misfires. Name a skill with /name to force it. Setting disable-model-invocation: true hides a skill from Claude entirely until you invoke it, which is also what I do for anything with side effects. For skills you did not write, the skillOverrides setting achieves the same. Bundled skills such as /code-review, /batch and /debug work without setup; see commands.
Skills in subagents. Rather than loading on demand, skills listed in a subagent's skills field are preloaded in full when it starts. The subagent can still discover and invoke other project, user and plugin skills through the Skill tool.
MCP. Tool search is on by default, so idle tools are cheap. Use /mcp to check server status and /context all to see the token cost of each loaded tool. Remote servers reconnect automatically if they drop.
Code intelligence. The LSP tool does nothing until you install a plugin for your language.
Subagents. A new subagent gets its own system prompt (not Claude Code's), the full text of its preloaded skills, CLAUDE.md and git status, and whatever the lead agent tells it. The built-in Explore and Plan agents skip CLAUDE.md and git status, and a definition that sets omitClaudeMd skips the user, project and local CLAUDE.md files. A fork instead inherits the parent's conversation, system prompt and tools.
Hooks. They can fire on tool use, session start and end, prompt submission, permission requests, compaction and more. The hooks reference lists every event.

Tip: Run /doctor on a project with a checked-in CLAUDE.md that has grown too large and it will suggest what to trim.