Skills vs Rules vs Commands: Which AI Tool When?

Claude Code gives you three ways to teach the agent something. They overlap. Picking the wrong one turns clean instructions into prompt soup.

Developer toolkit with neatly organized instruments representing structured AI workflow tools

Updated 16 June 2026 How we review →

By Rob16 June 2026 · 5 min read

Quick answer

Claude Code (Anthropic's CLI coding agent) gives you three ways to teach the agent something. Skills are markdown files the model loads when relevant - lazy-loading instructions for context-window efficiency. Rules (typically in CLAUDE.md or the global system prompt) always fire - the hard guardrails that apply across every session. Commands are typed shortcuts (e.g. /release) you invoke when you want something specific to run. Decision tree: if a guideline must apply EVERY session use a Rule (don't commit .env, never use em-dashes), if the guideline applies only WHEN doing X use a Skill (deploying a Cloudflare site, generating a hotel page), if you want to TRIGGER a workflow on demand use a Command. Use the wrong one and you either burn context window on rarely-needed instructions or fail to enforce guidelines that mattered.

Claude Code's instruction surface has three layers - Skills, Rules, and Commands - and the difference between them looks subtle until you've used them wrong for a few weeks. The fix is a clear mental model for what each one is for.

What is a Skill?

Lazy-loaded instructions for specific situations.

A Skill is a markdown file under .claude/skills/ (per-project) or ~/.claude/skills/ (user-wide) that Claude Code loads on demand when its name or description matches what the user is doing. The full spec is in the official Claude Code documentation.

Skills win when the instructions are long, specific, and only relevant some of the time. Examples that work well: 'how to deploy a Cloudflare Pages site', 'how to generate a hotel page from the scrape pipeline', 'how to run the daily SEO maintenance routine'. Each could be 5-10 pages of detailed steps. Loading all of them into every session would waste the context budget; loading 'deploy a Cloudflare Pages site' only when the user mentions deploying is the lazy-load that makes long skills practical.

What is a Rule?

Always-on guardrails that don't ask permission.

A Rule (the hard policy lines that always apply) lives in CLAUDE.md at the project root, in your global system prompt, or in a similar always-loaded location. Rules cost context every session, so they're for guidelines that matter every session.

Examples worth Rule treatment: 'never commit .env or credential files', 'never push to git without explicit user permission', 'always run tests before claiming a fix is complete', 'use British English for content on UK-targeted sites'. Each is short, each applies broadly, each prevents a costly mistake if missed.

The opposite of a Rule is an instruction that's only relevant in one workflow - that should be a Skill. Don't put 'how to deploy' in CLAUDE.md; you're paying for that context every session even when you're never going to deploy.

What is a Command?

User-triggered shortcuts to specific workflows.

A Command is something you type (the /name prefix) to trigger a workflow on demand. /release, /deploy, /seo-audit - each one runs a defined sequence of steps without you re-explaining the workflow every time.

Commands and Skills overlap in obvious ways - both can encapsulate a multi-step workflow. The split: Commands are TRIGGERED by you typing them; Skills are LOADED automatically when the model decides they're relevant. If the workflow is something you want explicit control over invoking ('don't run the deploy unless I say so'), make it a Command. If it's something the model should reach for when context warrants ('apply the dog-friendly-hotel page format when generating a hotel review'), make it a Skill.

Many workflows benefit from both - a Skill that documents how to do X, plus a Command that triggers running X with explicit user intent.

Bottom line

Three layers, three purposes.

Most working Claude Code setups end up with: CLAUDE.md as a thin file holding 5-15 hard rules (never commit X, always do Y, use British English), a Skills directory with 10-30 markdown files covering the repeatable workflows, and a handful of Commands for the workflows that should only fire on explicit intent.

The mistake most people make on day one is dumping everything into CLAUDE.md because it's the only file the docs introduce up front. The mistake some people make a few months in is putting genuinely-always-needed guardrails into Skills because 'Skills are the new thing'. The decision tree above keeps both errors away.

Q01When should I use a Skill instead of a Rule?

When the instruction is only relevant to specific workflows (deploying, generating particular content types, running specific audits) and would waste context window if loaded every session. Rules are for guidelines that apply every session - guardrails, project conventions, language choices. Skills are for situation-specific knowledge.

Q02Can a Skill and a Command do the same thing?

Yes - and many workflows benefit from both. A Command (/deploy) gives explicit user-triggered invocation; a Skill (deploy.md) documents the workflow so the model knows how to do it whether you typed the command or just described the task. The split is about WHO triggers - the user via typing, or the model via context inference.

Q03What's the maximum size of CLAUDE.md before it becomes a problem?

There's no hard cap, but if CLAUDE.md is over 300 lines you've probably mixed Rules and Skills. Audit: does this instruction apply to literally every session? If yes, keep it; if no, move it to a Skill. Most healthy projects sit at 50-150 lines of CLAUDE.md plus 10-30 Skills.

Q04Do Skills work in regular Claude.ai (not Claude Code)?

Yes - Anthropic shipped Skills in Claude.ai in 2026 alongside the Claude Code CLI. The mechanics are similar (lazy-loaded markdown, triggered by context match) though the discovery surface differs. The decision tree in this post applies in both environments.