Claude Skills: the workflow layer most engineers skip
You opened Claude Code this morning and typed the same context you typed yesterday: stack rules, error handling, review preferences, and what not to touch. By lunch, you had repeated a version of that preamble four more times.
That preamble is the real cost of AI coding right now, and it is the cost most engineers refuse to fix.
Skills are not a feature; they are a workflow shift
A Skill is unglamorous in the extreme. A markdown file with YAML frontmatter — a name, a description, a few hundred words of instructions, sometimes a reference file or a script — that Claude reads when it decides the Skill is relevant to what you are asking. The mechanism is a folder. The decision is the model's. That is the whole thing.
What is interesting is not the mechanism. It is what the mechanism replaces.
Before Skills, your options for "make Claude reliably do X" were: paste the instructions in every chat, stuff them into a CLAUDE.md that loads for every task whether relevant or not, build a custom sub-agent, or hope. With Skills the instructions only show up when needed. The model decides when. You do not pollute every chat with rules for the one task that needs them.
The Learn with Me AI walkthrough frames the unlock as "stop carrying context manually." GenAI Unplugged's piece on Claude Code as a second brain goes further and treats the Skills folder as the durable memory the chat window cannot be. Both are right, and neither goes far enough — the real shift is that the standard for how a task gets done leaves your head and becomes a file your team can edit.
The math is not subtle
If you run PR reviews twice a day, and the instructions to get a useful review take 200 words of context — which patterns matter, what to flag, what to ignore, what your linter already handles — that is roughly 73,000 words of duplicated context per year per developer. A 400-word Skill kills it.
But the duplication is not the interesting cost. The interesting cost is drift. Two reviews you ran in your head three months apart will not look the same. The standard exists in whoever happened to do the review last time. New team members inherit nothing. With a Skill the standard is in the file. It does not depend on you remembering to apply it.
The closest analogue is going from "we have a style guide" to "we have a linter." Same intent. Wildly different leverage.
A concrete example
Here is one I use, simplified:
---
name: pr-review
description: Use when reviewing a pull request, doing code review, or auditing changed code. NOT for writing new code.
---
Start with `git diff main...HEAD`. Then:
1. Flag anything that touches the auth boundary. We had two regressions there.
2. Flag any new `any` or `unknown` types in TS. We don't allow them.
3. Don't comment on style — Biome handles it.
4. Don't compliment. Just say what's wrong.
5. If you can't see a test for changed business logic, ask why.
Output as a numbered list. One line per issue. File:line reference.Ninety words. Edited maybe ten times. It captures things I would otherwise have to remember to say. When I ask Claude to review a PR, the description triggers the Skill, the rules apply, the review comes back in the shape I want.
Notice what is actually in the file. A description tight enough that the model picks the right moment. Concrete rules, not philosophy. A reason for at least one rule — that auth regression — so the model can extrapolate when it hits an edge case. An output format. That is the whole art of Skill-writing.
Where engineers get this wrong
Two failures, repeated.
Treating Skills as prompts. A prompt answers a one-off question. A Skill describes a recurring task. If you find yourself writing a Skill that is really a one-time instruction, paste it into the chat and move on. Skills earn their keep on repetition; without it they are clutter.
Designing Skills before the workflow exists. The right order is: do the task three or four times manually, notice what you keep saying out loud, then extract the Skill. Engineers who try to write a "complete" Skill upfront produce 2,000-word documents the model cannot follow and they cannot maintain. The good Skills are observations, not designs.
The third failure is sprawl. Twenty Skills with overlapping triggers are worse than five tight ones. The model gets confused about which to load; you get confused about which to edit. Treat the Skill folder like any other code — delete aggressively, refactor when triggers collide, name things so the system scales past forty entries.
The chaining payoff
Skills become genuinely interesting when they compose.
A find-flaky-test Skill that returns a list of suspects. A bisect-test Skill that takes a suspect and runs git bisect against a known-good ref. A write-test-fix Skill that takes the bisect output and drafts a fix. Each one is small. Each one is independently useful. Stack them and the model walks the whole chain — sometimes in a single command — because each Skill knows enough about its neighbours that the handoff makes sense.
This is the workflow layer. Not "better prompts." Not "more agents." A graph of small, named, reusable units of work, with the model choosing which one to invoke from context. The closest analogy is Unix pipes with a model on top deciding which command to run.
You will recognise the shift the first time you describe a job in one sentence and the chain handles it without you stepping in.
A prediction you can disagree with
In twelve months, the engineers shipping fastest will not have the best prompts. They will have a personal library of 15–30 Skills — version-controlled, shared with their team, edited weekly. The Skills will be boring to read. Most will sit under 200 words. None will feel clever. The leverage will come from the fact that the same tasks get done the same way every time, without anyone having to think about it.
The engineers who fall behind will not be the ones avoiding AI. They will be the ones using AI well but treating every interaction as a one-off. They will keep typing the same preambles, hitting the same edge cases, missing the same regressions — because nothing they did yesterday makes them faster today.
The plausible counter is that the next model generation makes Skills redundant. Memory gets good enough that the model remembers your conventions across sessions and the explicit file becomes a museum piece. I do not think this happens in twelve months. The model can remember; what it cannot do is read your mind about which conventions matter for this task versus the one you did last Tuesday. That decision belongs in a Skill description for the foreseeable future.
What to do this week
Do not write a Skill yet. Open a scratch file. The next three times you type a preamble to Claude that feels familiar, paste it into the file. After the third repetition, look at what you wrote, condense it to 200 words, give it a name and a one-line description, save it as a Skill.
The friction is not technical. It is that "writing a Skill" sounds like a Friday-afternoon project and "typing the preamble again" sounds like Tuesday-morning work. It is the opposite. The Tuesday-morning work is the one that does not compound.
Sources I drew from: