The two people who built agent skills at Anthropic stopped building a separate agent for every job. Not because agents failed, but because the agent sitting underneath had turned out to be far more general than they expected, so wrapping a new one around each task was work nobody needed to do. I'll walk through the shift they made, and then the four practices that decide whether the thing you build on top of it is actually worth keeping.
The stack already looks like the phone in your pocket
Your phone has a processor, an operating system, and the apps you open every day. A handful of very large companies build the first two, and you almost certainly never touch them. What you choose are the apps, and each one gives the same unchanged phone a specific new capability.
The AI stack is settling into the same shape. The model behaves like the processor. The agent runtime, the layer that reads files, writes code, calls tools and works through a task step by step, behaves like the operating system. Skills are the apps.
A skill is a folder of plain-language instructions plus whatever the job needs alongside them: the process to follow, the background context, any scripts, and examples of good output. Claude Code can already read your files, run tools and grind through a multi-step task. You don't rebuild any of that to get a presentation, a company research brief or a post written. You hand the same general-purpose agent the skill for that one job.
Which sounds tidy until you own a dozen of them and half quietly underperform. The four practices below are what separates a skill that earns its place from one that just sits in the folder.
Stop paying the assistant to re-solve solved problems
At Anthropic they kept watching Claude write essentially the same Python script every time it had to apply styling to a slide deck. Tokens spent recreating code that already existed, and because it was rebuilt from scratch on every run, the result drifted a little each time. Same job, slightly different deck.
The fix was to have Claude save that script inside the skill as, in their own words, a tool for its future self. The next styling run executes the version that was already proven to work.
Programmers have lived by this for decades under the name DRY, short for "don't repeat yourself": solve the problem once, keep the solution, reuse it. The same logic applies to an assistant, and almost nobody applies it, because code written inside a chat feels temporary.
So the next time your assistant produces a script whose output you genuinely like, don't leave it in the conversation to be lost when you open a new session. Tell it something close to this:
Save the script you just used into this skill's scripts folder. Update the skill instructions so future runs execute that file instead of rewriting it. Then run the skill again and verify the result.
You still have to test it, and the test is small. Run the same type of task twice. Compare the parts that matter to you. Confirm the skill is genuinely calling the saved file rather than quietly writing a fresh one. The prose and commentary around the output may still vary between runs, and that's fine. What changed is that the load-bearing part stopped being a new guess each time.
A description the assistant can't match is a skill you don't have
Think about a mechanic for a moment. He owns hundreds of tools and does not tip all of them onto the bench before changing a tire. He works out what the job is and picks up the three or four things it needs. Everything else stays in the box.
Skills behave the same way, through a mechanism Anthropic calls progressive disclosure. When the assistant starts a session it does not read the full instructions, examples and scripts for every skill you own. That would waste time and flood its working memory before you've even asked for anything. It reads only each skill's name and description, the few labelled lines at the top of the skill file. When your request matches one of those descriptions, only then does it open the full instructions, and the heavier reference files and scripts stay on disk until the task actually reaches them.
The payoff is that irrelevant instructions never enter the working context, which is what keeps a long session from bloating and going vague on you. The cost is that everything now rests on the description.
If one skill says "help with content" and another says "create marketing assets", the assistant is guessing. The two overlap, and neither one says when it should fire. A description that works names the job and the trigger together:
Creates LinkedIn carousels from a topic, a transcript or an outline. Use this when the user asks for a carousel, for carousel slides, or for a LinkedIn document post.
Now there is a job and a moment. Keep each skill pointed at one job, write the words a real person would actually use when asking for it, and make sure no two skills are competing for the same request.
You can have the assistant audit this for you. Ask it to review every skill description and, for each one, state what it does, when it should trigger, and where it overlaps with another skill. Then have it rewrite only the ambiguous ones, because rewriting descriptions that already work is how you break a working setup.
Then test each rewritten description against three prompts: an obvious request that should trigger it, a differently worded request that should still trigger it, and an unrelated request that must not. A skill the assistant cannot find is a skill you do not have.
Every correction is either written down or thrown away
Think about what happens when you correct your assistant and then close the chat. It used the wrong tone, or skipped a check, or formatted the output in a way you never want to see again. You told it, it fixed that one output, and then the session ended and the lesson went with it. Saying "fix it" repairs the artefact. The process stays exactly as broken as it was.
There is a better move, and it costs one extra prompt. When an agent tells you it cannot find a file you know exists, don't just hand over the path and move on. Make it backtrack: show you where it searched, work out why it missed, and then update the routing or the skill so the next run starts in the right place. You are spending thirty seconds to stop paying the same tax weekly.
Worth being precise about what a skill holds. Skills are not a recording of every conversation you've had, and they do not remember everything. They store procedural knowledge: how this particular job gets done. That distinction gives you a clean rule for where any given correction belongs.
- When the process itself was wrong, update the instructions in the skill file.
- When the output was competent but missing your voice, your brand or your examples, add a reference file.
- When the same mistake keeps coming back, write an explicit rule that forbids it.
Then rerun the same task and confirm the fix held. Over enough runs the skill turns into a living record of how you want that job done, which is a different and more durable asset than a well-phrased prompt.
One claim to handle carefully, because it gets oversold: no skill is model-proof. Nothing you write in a skill file will force a weaker model to perform like a stronger one, and different models read the same instructions differently. What travels is the process. Agent skills are an open format, so the same skills folder can run across compatible agent harnesses. Take a skill that matters to you and run it under a different agent. If the output falls apart, you've just found hidden assumptions, missing examples, or phrasing that only one model interprets the way you meant. Tighten those and test again.
The skill has to check its own work before it hands it over
The fourth practice is the one I'd install first if you only ever adopt one.
Here is the failure I see most often in otherwise sensible setups. You run the skill. It makes the thing, saves the file, and reports that it's done. You open the file and the formatting is broken, or the sources don't support the claims, or the copy is flat for the person it was written for. The AI did most of the job, and the remainder lands on your desk by hand, every single time.
But you already know how you would check that work. You do it manually on every run. So put the check inside the skill and let it close more of the gap itself.
- For a slide deck, have the skill render each slide as an image, look at the screenshots, fix anything cropped, unreadable or running off the edge, and render again.
- For a research report, make it open the primary sources, match each claim to the evidence, and delete anything it could not verify.
- For something subjective like an ad or a script, have a few personas review it as separate sub-agents and argue about it. A beginner reports where they got lost. A sceptical buyer reports what they don't believe. Someone from your actual audience reports where they'd click away.
You don't take every note from that review, and a skill that obediently applies all of it will produce something worse than the draft. What works is having the skill keep the issues that show up more than once, make the strongest revisions those point to, and run the review again.
And verification is not the assistant rereading its own draft and pronouncing it good. It needs evidence from outside that first draft: a screenshot, a test result, a primary source, a reference example of what good looks like, or those other perspectives. A model grading its own homework will pass it.
Here is an instruction you can drop into almost any skill you own:
Before returning anything, define the acceptance criteria for this output. Produce the first version, inspect it using the relevant verification method, fix every issue you find, then run another pass. Return the output only once it meets the criteria, with a short summary of what you checked. If something could not be verified, say exactly what remains.
Better still where the job allows it: set an objective success metric and let the agents keep working until they hit it.
What changes is the status of the first output. It stops being a deliverable and becomes an internal draft. Your first look should not be the agent's first look. It should be its fourth or fifth, after the obvious problems have already been found and fixed without your attention. You remain the final judge wherever taste, strategy or business judgement is involved, and you should. You just stop spending your working day catching things the AI was perfectly capable of catching itself.
What you end up owning
None of the above says agents are finished. It says the interesting work moved up a layer. You keep proven code instead of paying for it twice, you write descriptions precise enough that the right skill gets found without guessing, you put corrections where the next run will read them, and you let the work be checked before it reaches you.
That's how a general-purpose agent gets taught how you, specifically, work. It is also the part of your setup nobody else can copy, because it is made of your judgement.
If you want a starting point this week, open the skill you run most often and add the verification step to it. Of the four, it's the one that pays back on the very first run.