Skills

Every time you explain your team's coding standards to Claude, you are repeating yourself. Every PR review, you redescribe how you want feedback structured. Every commit message, you remind Claude of your preferred format. You can feel the friction. There is a name for what you are missing — and an obvious fix for how to stop writing it.

What a skill is

A skill is a markdown file that teaches Claude how to do something once, and Claude applies it automatically whenever the situation matches. No typing, no remembering, no repeating yourself — the instructions activate on demand.

A skill has two things Claude cares about: a description that tells Claude when to use it, and the body that tells Claude what to do when it does. When you ask Claude to "review this PR," Claude compares your request against the descriptions of all available skills, finds the one that matches — say, a "PR review standards" skill — and activates it. Everything inside that skill's body becomes relevant context for the task at hand.

The description field is the key to making skills work. It is how Claude decides whether this skill is the right one. Vague descriptions get ignored; precise descriptions get picked up reliably.

Where to put them

There are two locations, and the distinction mirrors CLAUDE.md:

Personal skills — ~/.claude/skills/. These follow you across every project. Put your personal preferences here: your commit message style, your documentation format, the way you like code explained.

Project skills — .claude/skills/ in the repo root. Check these into version control. Anyone who clones the repo gets them automatically. Team standards live here: code review checklists, brand guidelines, company-specific conventions, preferred fonts and colors for UI work.

Same rule as CLAUDE.md: team conventions go in the project, personal habits go in your home directory.

Skills vs CLAUDE.md vs slash commands

Claude Code has several ways to shape its behaviour. Skills, CLAUDE.md, and slash commands all look similar at first — and then they start to diverge sharply.

CLAUDE.md loads into every conversation. If you want Claude to always use TypeScript strict mode, that is a CLAUDE.md rule. It is in context from the first message of every session. Good for rules that apply universally; costly for rules that only matter sometimes.

Skills load on demand. Only the name and description of each skill sit in context permanently. The full body loads only when Claude matches your request to the skill. Your PR review checklist does not need to be in context when you are debugging — it loads when you actually ask for a review. This is a deliberate context efficiency: you can have fifty skills installed without any of them inflating your working memory until they are needed.

Slash commands require you to type them. They are manual. You have to remember the slash command exists and remember to invoke it. Skills do not care — Claude recognises the situation and applies them for you.

The rule of thumb: universal preferences go in CLAUDE.md, task-specific knowledge goes in a skill, and anything you want to invoke explicitly on demand becomes a slash command.

When to write a skill

Skills work best for specialised knowledge that applies to specific tasks. Good examples:

• Code review standards your team follows on every PR.
• Commit message formats your project enforces.
• Brand guidelines for UI work — colors, fonts, voice.
• Domain-specific conventions for a particular subsystem.

The heuristic that will serve you forever: if you find yourself explaining the same thing to Claude repeatedly, that is a skill waiting to be written. The friction of repetition is the signal. Stop re-explaining — write the skill once and let Claude pick it up automatically from then on.

Where this sits in the course

Skills are the third extension mechanism — and they exist largely because of context management. Loading only the name and description until matched is a direct answer to the problem MCP servers and heavy tool definitions create (which you will see in the next lesson). You get the benefit of rich instructions without paying for them on every prompt.

Want to go deeper? Check out the dedicated Introduction to Agent Skills course.