Rules, skills, commands, subagents, MCP
Most people put everything in CLAUDE.md and wonder why the agent skips half of it. The file gets long, the model gets lazy, and the rules you actually cared about disappear into the noise.
The fix is knowing that Claude Code has five primitives, not one. Four are about guidance the agent reads. The fifth is about tools the agent can reach. Each has different rules about when it loads and what it costs.
The five primitives
| Primitive | Loaded | Cost | Use for |
|---|---|---|---|
| Rule | Always | Every turn | Must-follow rules |
| Skill | On demand | Only when triggered | Deep reference |
| Command | When typed | Per invocation | Repeatable workflows |
| Subagent | When delegated | Isolated context | Parallel or heavy work |
| MCP server | Connected at startup | Per tool call | External tools and data |
Rules: the always-on layer
Rules live in .claude/rules/. In my template that's six files: code style, JSDoc essentials, markdown, security, testing, USA English. They load on every turn, so they need to be short.
The test is simple. If forgetting it would produce code you'd reject in review, it's a rule. Everything else belongs elsewhere.
security.md is the cleanest example. Six bullets, no examples, no preamble. Don't commit secrets. Validate input at trust boundaries. Don't shell-interpolate untrusted strings. That's the whole file. It loads every turn because the cost of forgetting any one of them is too high.
Skills: the reference shelf
Skills are markdown files the agent loads only when the task matches. They can be long, because they only cost context when they fire.
The template has a humanizer skill that loads when I write prose, with detailed rules for cutting AI vocabulary. It has a jsdoc skill that loads when I write TypeScript, with the full tag taxonomy. Neither one costs anything until the task triggers it.
The trigger lives at the top of SKILL.md as a short description. The agent reads the description on every turn but only opens the body when the task matches. That's the whole trick.
Commands: workflows you type
Commands are skills you invoke by name with a slash. /code-review, /verify, /changeset. Same file format as a skill, different entry point.
Use them when you want the agent to do something specific on demand, and you don't want to retype the prompt every time. The /code-review command in the template is a good example. It knows the project's conventions, runs the right diff, and posts inline comments.
Subagents: isolated workers
Subagents are different. They run in their own context window. Use one when you want parallel work, or when the task would flood your main context with noise.
Explore is the canonical case. If I ask it to find every place we read from process.env, it reads dozens of files and reports back two lines. My context stays clean.
The anti-pattern is reaching for a subagent when two tool calls would do. Spawning costs latency and tokens. Don't pay it unless the work is genuinely big or parallel.
MCP servers: tools from outside
The first four primitives are about guidance. MCP servers are different. They run as separate processes and expose tools the agent can call, like GitHub, a database, a browser, or your design system.
You wire one up once in .mcp.json or your user config, and the tools it provides show up alongside the built-in ones. The template ships with the GitHub MCP server enabled because almost every project needs PR comments and issue reads.
The rule of thumb is the same as for subagents: don't add one until you actually need the capability. Each MCP server adds a tool list the agent has to keep in working memory.
A decision tree
Should every session enforce this? Rule.
Only when a specific task comes up? Skill.
Does the user trigger it explicitly? Command.
Does it need its own context window? Subagent.
Does it need to reach outside the repo? MCP server.
One feature, five touch points
Take "review this PR for security issues." It splits across all five primitives.
The security rule is always on, so the agent already knows not to log secrets or trust input from the network. The code-review skill loads when the task is a review, bringing the project's reviewing conventions. The /security-review command lets me trigger the workflow with a slash. The code-reviewer subagent runs in isolation for a second opinion that won't pollute my main context. And the GitHub MCP server posts the inline comments back on the PR when the review is done.
Five primitives, one feature, no overlap. Each piece earns its keep.
What's not in this taxonomy
Two more pieces sit on a different axis and are worth knowing about.
Hooks are shell commands the agent runs on events like SessionStart or Stop. They're deterministic, not guidance. The template uses a SessionStart hook to install dependencies so the agent never wastes a turn on pnpm install.
Output styles shape how the agent writes, not what it does. The template ships a house style with rules like "no em dashes, sentence-case headings, cut filler". A style is a thin wrapper that biases voice across everything else.
Try it
The template has the primitives populated with working examples. Clone it, open the folders side by side, and the taxonomy stops feeling abstract.