Anthropic published something rare in June: an honest account of how their own engineers use Claude skills. Not a product pitch. A field report. They run hundreds of skills internally, they catalogued the lot, and they wrote up what works. The post is Lessons from building Claude Code: How we use skills by Thariq Shihipar. We read it so you can get the useful bits in five minutes.
If the word "skill" is new to you: a skill is a set of instructions and resources you hand to Claude so it does a specific job your way, every time. Think of it as a written procedure for a very fast new hire.
A skill is a folder, not a memo
The first correction Anthropic makes is one we see constantly with clients. People treat skills as a single page of instructions. They are actually folders. They can hold scripts, templates, reference files, and example outputs. The instruction file points to the rest, and Claude opens what it needs when it needs it.
That changes how you build them. Your invoice skill does not need every rule crammed into one document. It needs a short instruction file, your invoice template sitting next to it, and a reference file with the awkward client-specific terms. Claude reads the detail only when the detail matters.
The skills that check the work beat the skills that do the work
Anthropic sorted their internal skills into nine categories. Most are engineering-flavoured: library references, code scaffolding, deployment routines, incident runbooks, infrastructure maintenance, data queries, code review, workflow automation, and verification.
Here is the finding that matters. Of all nine, verification skills produced the most measurable improvement in output quality. Not the skills that draft things. The skills that check things. Anthropic reckons it is worth an engineer spending a full week just making their verification skills excellent.
Translate that out of engineering and into a normal business. Everyone builds the "doer" skill first. Draft the proposal. Write the email. Generate the report. Almost nobody builds the checker. Does this proposal use current pricing? Does this email match the payment terms we actually agreed with this client? Does this report include the figure the board always asks for? A checker skill is a pass or fail list run against the output before it goes anywhere near a human. It is dull to build and it is where the quality lives.
The gotchas section is the whole point
Anthropic's bluntest advice: the highest-signal content in any skill is the gotchas section. Claude already knows how to write, code, and format. A skill that restates the obvious adds words without adding value. What Claude cannot know is your business. The client who pays on 60 days despite the contract saying 30. The supplier whose product codes changed last year but whose old codes still float around your files. The report that must never go out on a Friday because the numbers refresh Saturday morning.
These are the things that trip up a new employee in month one. They are exactly what trips up an Ai system on day one. A good way to extract them is to have Claude interview you. One question at a time, aimed at surfacing the rules you follow without noticing you follow them.
Start with a few lines and grow it
The pattern Anthropic describes for their best skills: they began as a few lines and a single gotcha, then improved because someone kept adding to them each time Claude hit a new edge case. Skills are grown, not built.
That is the practical instruction for a small business. Do not spend a fortnight architecting a skills library. Write the short version of one procedure today. Run it. When it gets something wrong, add the correction to the skill rather than fixing the output by hand. Six weeks later you have a procedure document that is better than anything in your staff handbook, and it executes itself.
Two more habits worth stealing. First, keep skills single-purpose. Anthropic found that skills trying to do several jobs at once confuse the system. One skill, one job. Second, when a rule applies across several workflows, split it into its own skill and have the others reference it. Your pricing rules should live in one place, used by your proposal skill, your invoice skill, and your renewals skill. Change the price once, everything downstream follows.
The honest caveat
The fastest way to waste money here is automating a task Ai does badly. Before you build anything, run the task manually with Claude a few times. If the raw output is poor, a skill will produce polished versions of poor. Skills sharpen what already works. They do not rescue what does not.
That is the whole post, really. No magic. Written procedures, checked outputs, and captured exceptions. The same things that make a good operations manual, applied to a tool that reads at machine speed. Just a tool. A very good one, used properly.
WebAi.Scot builds operational Ai systems for small and medium businesses. If you want the procedures in your head turned into skills that run themselves, talk to us.