When to Use Claude Code Skills vs CLAUDE.md

When to use Claude Code skills instead of CLAUDE.md

Knowing when to use claude code skills rather than CLAUDE.md is one of the most reliably tested judgement calls in Domain 3, because the two mechanisms look interchangeable and are not. Both let you give Claude standing guidance. The difference is temporal: CLAUDE.md content is loaded at the start of every session and stays active for everything you do, while a skill body is loaded only at the moment it is invoked and is otherwise absent. That single distinction drives every correct answer on this knowledge point.

The trap is to reason about importance. People assume that critical instructions deserve to be in CLAUDE.md so Claude never forgets them, and that minor helpers can be skills. That instinct is wrong. A code-review checklist might be extremely important, but it is still task-specific: it should be present when you review and absent when you are writing a migration. Importance does not decide placement; frequency and scope do.

The decision rule

Reduce the choice to one question: should this content be active on every turn, or only when a particular task comes up?

• Always active, applies broadly → CLAUDE.md. Coding conventions, naming standards, the project tech stack, architectural rules, the commands to run tests. These are facts and standards Claude should honour on every edit, so paying to load them every session is exactly right.
• Active only for one kind of task → a skill. A release procedure, a code-review workflow, a database-migration runbook, a changelog generator. These are step-by-step procedures you reach for occasionally, so they should load on demand and stay out of context the rest of the time.

A useful tell from the documentation: when a section of CLAUDE.md has grown from a fact ("we use RESTful naming") into a procedure ("to cut a release, do these eight steps"), that section has outgrown CLAUDE.md and wants to become a skill. Facts belong in memory; procedures belong in skills.

Why the token economics matter

The reason this distinction is not merely stylistic is cost and focus. Every line in CLAUDE.md is re-loaded on every session and consumes context whether or not it is relevant to what you are doing today. Stuff a rarely-used release runbook in there and you pay for it on the hundred days you are not releasing, and you dilute the model attention with instructions that do not apply. Move it to a skill and it costs almost nothing until the day you actually cut a release, at which point you invoke it and the full procedure loads. The on-demand loading model of skills is the lever; matching content to it is the skill an architect must demonstrate.

A taxonomy you can sort on sight

The fastest way to internalise the rule is to practise classifying real configuration. Run each item through the fact-versus-procedure and always-versus-occasional tests, and the placement falls out.

• "We use British spelling in all user-facing copy." A universal standard that should apply to every edit, so it belongs in CLAUDE.md.
• "To publish a release, bump the version, regenerate the changelog, tag, and push." A multi-step procedure invoked occasionally, so it belongs in a skill.
• "Run the test suite with pnpm test." A standing fact Claude should know on any turn, so CLAUDE.md.
• "Walk a pull request through our nine-point accessibility review." A task-specific procedure, so a skill, ideally with a description so Claude can offer it when you start a review.
• "Our API responses always use this error envelope." A convention that shapes any endpoint you touch, so CLAUDE.md.

Notice the pattern: short, durable facts and standards gravitate to CLAUDE.md, while named, sequenced procedures gravitate to skills. When you can sort a list like this without hesitating, you have the knowledge point.

Where path-specific rules fit alongside the two

There is a third mechanism worth holding in view, because exam questions sometimes offer it as a tempting middle option: path-specific rules in .claude/rules/ with a glob in their frontmatter. These load automatically, but only when you touch files matching the pattern, which makes them ideal for conventions that are universal within a slice of the codebase but irrelevant elsewhere, such as test conventions that should apply across every *.test.tsx file but nowhere else. They are neither always-on like CLAUDE.md nor manually invoked like a typical skill; they are conditionally-on. For this knowledge point, the clean mental model is a spectrum: CLAUDE.md is always loaded, path-specific rules are loaded for matching files, and skills are loaded on demand. Recognising that a requirement is "applies to a file type, not the whole project" is what tells you the answer is a path rule rather than a bloated CLAUDE.md or an awkward skill.

Refactoring a CLAUDE.md that has outgrown itself

When a CLAUDE.md has accumulated procedures, the cleanup is mechanical once you accept the rule. Read the file top to bottom and label each block as a fact or a procedure. Leave the facts where they are. For each procedure, cut it into a new skill folder under .claude/skills/, give the SKILL.md a description that captures when it should run, and add disable-model-invocation: true to any procedure with side effects so Claude only runs it when a human asks. Commit the new skills so the team inherits them, and verify that CLAUDE.md is back to pure standards. The win is concrete and measurable: a lighter file loads on every session, the model stops applying task-specific instructions to unrelated work, and the procedures are still one slash away when you need them. This is the everyday shape of the skills-versus-CLAUDE.md judgement, and it is exactly the situation the exam dramatises.

Common misreadings to avoid

Two litmus tests you can apply instantly

When a scenario does not hand you an obvious label, two quick tests resolve almost every case. The first is the every-turn test: ask whether you would want this content active on a completely unrelated turn. If Claude is writing a database migration, should it still be holding your code-review rubric in mind? If the honest answer is no, the content is task-specific and belongs in a skill; if the answer is yes, it is a universal standard for CLAUDE.md. The second is the fact-or-procedure test: read the content and ask whether it states a fact ("we use snake_case for database columns") or describes a procedure ("to add a column, do these steps"). Facts and standards are CLAUDE.md material; named sequences of steps are skills.

These two tests usually agree, and when they do you can answer with confidence. On the rare occasion they seem to disagree, a standard that is also somewhat procedural, fall back to the cost question: would loading this on every session be a fair price for how often it is actually relevant? If you would resent paying that cost on the many days the content does not apply, it wants to be on demand, which means a skill. Training yourself to run these tests quickly is what turns this analyse-level knowledge point from a judgement call into a reflex, and it is exactly the reflex the exam is checking for when it shows you a misplacement and asks for the fix.

How this shows up on the exam

Domain 3 carries 20% of the weight, and TS 3.2 questions on this knowledge point are nearly always classification problems framed through Scenario 2 or Scenario 4: you are handed a piece of guidance and asked where it belongs, or shown a misplacement and asked to name the fix. The reliable wrong answers are a code-review workflow parked in CLAUDE.md and a set of coding standards buried in a skill. Anchor on the rule, universal and always-on goes in CLAUDE.md, task-specific and on-demand goes in a skill, and you can sort any example quickly. This analysis feeds directly into the broader command-and-skill design scenarios you will evaluate next.

Watch and learn

Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.

Official · Anthropic AcademyOpen full lesson in Academy

Skills vs. other Claude Code features

Why watch: Drawing the line between skills, commands, and CLAUDE.md is precisely the skills-versus-config distinction this KP defines.

More videos for this concept

Skills vs. other Claude Code features

Introduction to Agent Skills

What are skills?

Introduction to Agent Skills

claude.md vs Skills: Which One Actually Wins!

DIY Smart Code

Stop Confusing Skills and Subagents in Claude Code (Watch This)

TechWhistle