Skills — Your Power-Ups
Reusable packages Claude invokes on demand
CLAUDE.md gave Claude rules. A gives it a recipe. It's a small markdown file that encodes a task you want Claude to do the same way every time — structured diff review, file explainer, commit-message drafter, security audit. Once installed, Claude invokes it automatically whenever your intent matches.
After CLAUDE.md, this is the second-biggest multiplier in Claude Code. By the end of this chapter you'll have two skills in your repo — one we ship with the course, one you write yourself.
You'll have two skills installed in your repo: one we wrote for you (explains any file in plain English) and one you wrote yourself for a task you actually repeat. Both will auto-invoke when you ask for them by name.
Skills are recipes Claude invokes on its own
The magic of a skill isn't that you can call it. That would just be a function. The magic is that Claude decides when to call it based on what you said.
Every skill has a one-line description at the top of its file. When you start a session, Claude reads all those descriptions. When you type a request, it matches your words against them and silently fires the best match. You don't type /run-skill what-is-this; you just ask "what is this file?" and the skill fires.
That means the most important line in any skill isn't the logic — it's the description. Write it well and Claude finds it; write it vaguely and Claude never invokes it.
Every skill has three parts: where the file lives, a block at the top (that's metadata between --- lines), and the markdown body which acts like a mini system prompt for that task.
.claude/skills/<name>/SKILL.md
The directory name is the skill name. A file at .claude/skills/audit/SKILL.md becomes the skill audit.
YAML between --- lines at the top.
- description — what + when to invoke. Most important line.
- allowed-tools — security boundary.
Plain markdown instructions. Treat it like a mini system prompt: what to do, in what order, what format to return.
Short > long. Specific > vague. Concrete examples beat abstract rules.
We'll install a genuinely useful starter skill — what-is-this — that explains any file in plain English. Once it's in your repo, point it at code you don't fully understand.
Make the skills directory
Run this at the root of your repo:
mkdir -p .claude/skills/what-is-this
Drop the starter skill in
Create a new file at .claude/skills/what-is-this/SKILL.md and paste everything below. The filename must be exactly SKILL.md (Claude Code looks for that specific name).
--- description: Explain in plain language what a file does, intended for someone unfamiliar with the codebase. Invoke when the user asks "what is this" or "explain this file". allowed-tools: Read, Grep, Glob --- # What is this? When the user asks about a specific file, read it (and up to 3 of its most-imported dependencies if obvious), then answer in this exact structure — nothing else: ## Purpose One sentence. What the file is for, in plain language. ## Key pieces Up to 4 bullets naming the most important functions or exports and what they do. One sentence each. ## Where it fits One sentence on how it relates to the rest of the codebase. ## Rules - Avoid jargon. Pretend the reader is a new hire on day one. - Never paste long code blocks — summarise instead. - If the file is trivial (less than 30 lines of actual code), say so directly and skip the section structure. - If you had to guess because the file is empty or confusing, say that explicitly instead of pretending you understood.
Invoke it on any file
Start a Claude Code session and ask about any file. Claude will read every skill's description, match your intent, and invoke the skill automatically:
what is src/lib/cn.ts?
You should get a structured response with Purpose, Key pieces, and Where it fitssections — not Claude's default free-form prose. That's the skill working.
Now write one yourself. Pick something you genuinely type three or more times a week. Could be "rewrite this error message for an end user", "draft a commit message from the staged diff", "find all TODO comments grouped by file owner". If you repeat it, it's a skill.
Start with this scaffold
Create a new file at .claude/skills/<your-skill-name>/SKILL.md. Replace the angle-bracket placeholders. That's the whole thing.
--- description: <one-line description of what this skill does and when to invoke it — this is what Claude matches against user intent, so be specific> allowed-tools: Read, Grep --- # <skill name> <1–2 sentence summary of what this skill produces> ## Steps 1. <what to read / check first> 2. <what to produce> 3. <what format to return it in> ## Rules - <anything Claude must always do> - <anything Claude must never do>
Once saved, start a fresh Claude session and invoke it with phrasing that matches your description. Iterate on the description until it reliably triggers — that single line is 80% of writing a good skill.
Need ideas? These four are easy wins that ship real value on day one:
- summarize-diff — three bullets + a conventional-commit message from the current diff.
- pr-description— a PR body from the current branch's commits, using your team's template.
- rename-consistent — rename a symbol across the codebase, updating imports and tests, and report conflicts.
- readme-freshness — check if README commands still work against package.json scripts.
From recipes to frozen rituals
You now have two skills: one that auto-invokes on "what is this?", and one you wrote for a task you actually do. Every time Claude fires either one, you save the 30 seconds of typing and thinking you'd have done by hand — across a year, that adds up to hours.
Skills auto-invoke based on your words. Chapter 5 covers the opposite: , which you invoke explicitly by name (/review, /ship). They're the frozen rituals you pull out on purpose, not the helpers that appear when called.