A Claude skill is a folder of files describing how a task is done at your company. Claude loads it on its own when the task comes up, then applies your method instead of improvising its own. At minimum the folder holds a SKILL.md file: a short header saying what the skill does and when to use it, then your instructions in plain text.
Anthropic released the format in October 2025, in an engineering post presenting it as an onboarding guide for agents, then opened it as a standard in December 2025. This guide covers what a skill is, how Claude loads it and how to write your own. It also covers which ones to build first in a small or mid-sized company, and how to share them without creating a security risk.
What exactly is a Claude skill?
A Claude skill is a folder of instructions, scripts and resources that the agent discovers and loads on demand. The clearest comparison is a new colleague joining the team. On day one you do not repeat your procedures for every task. You wrote them once, and the person looks them up when needed.
The difference with a prompt comes down to one word, persistence. A prompt lives for one conversation, then vanishes. A skill lives in a folder. It can be reread, corrected, versioned in Git and shared across a whole team. That is what makes it usable inside a company, where a prompt stays a personal object.
On recurring tasks, a skill makes the prompt unnecessary. That is the shift I described in the end of the prompt. The useful unit of work becomes the method you documented once, and it serves every later request.
How Claude loads a skill, in three levels
Progressive disclosure is the mechanism that makes skills usable at scale. Claude does not read the whole folder at once. It reads what it needs, when it needs it, and the rest costs nothing.
- Level 1, the metadata. The name and description of every installed skill stay in memory permanently. Budget around 100 tokens per skill.
- Level 2, the SKILL.md body. It enters the context only when your request matches the description. Anthropic recommends keeping it under 5,000 tokens, roughly 500 lines.
- Level 3, the resources. Reference sheets, document templates and scripts stay on disk. A script that runs brings only its output into context, never its code.
The practical consequence matters more than the mechanism. You can install many skills without weighing down your conversations, because only the descriptions cost anything continuously. That is also why the description is the most important part of the file: on its own it decides whether the skill triggers.
Skills, MCP and RAG: the three building blocks of one agent
These three terms come up in every architecture discussion, almost always framed as a choice to settle. They are three building blocks of the same agent, answering three different questions. Go back to the new joiner image. The person needs your ways of working, access to the tools, and the company documentation.
| Building block | The question it answers | What it brings |
|---|---|---|
| Skills | How should the work be done? | Your method, written once, loaded when useful |
| MCP | What can the agent reach? | Standard access to email, CRM and ERP |
| RAG | What should the agent know? | The useful passages of your documents, cited in the answer |
These blocks fit together. A skill can state which tools to use and in which order. A document base can connect to the agent through an MCP server. The MCP protocol was launched by Anthropic before being adopted by OpenAI, Google and Microsoft, which makes it today's connection standard.
In the field, the method is almost always what is missing. The tools are connected, the documents are indexed, and the agent still answers beside the point. Nobody wrote down how to do the job. That is the first thing Tandem formalises with its clients, before adding a single connector.
How to create a Claude skill, step by step
Creating a Claude skill takes a text editor and a procedure you know by heart. No developer skills are required for the most useful cases. Here is the method in six steps.
- Pick the right task. Take the one you explain again twice a month, with a stable expected output and rules you can actually state.
- Create the folder. It carries the skill name, in lowercase with hyphens, for example tender-response.
- Write the header. Two required fields. The name is 64 characters at most, no capitals, and cannot contain "claude" or "anthropic". The description is 1,024 characters at most, and must say what the skill does and when to use it.
- Write the body. Your rules, your numbered steps, one example of input and output, and the edge cases that ruin the deliverable.
- Move the detail out. Long sheets go in references, templates in assets, code in scripts. Claude opens them only when needed.
- Test on real requests. Three to five cases, including one where the skill must stay out. That is the test that exposes an overly broad description.
These naming constraints and this folder layout are not specific to Claude. They come from the Agent Skills specification, which also defines the optional fields, including the licence and the pre-approved tools.
The house rule: on the second explanation, make it a skill
In workshops, the question that comes back rarely concerns writing the skill. It concerns timing. The rule Tandem applies fits in one sentence. The second time you explain the same task to Claude, stop and turn it into a skill. The first time, you are discovering the task. The second time, you are already paying twice for the same work.
I detailed the loading mechanism in my one-pager on Skills back in April 2026, when the format was still mostly known to technical teams. A year and a half later, it is the first deliverable our clients ask for.
Then comes the part nobody plans for, the extraction. We sit down with the teams, interview them and watch how they actually work. The process described in the internal wiki and the real process are rarely the same. The skill documents the second one, otherwise it produces a deliverable nobody recognises. That extraction work is the core of our Claude training.
Which skills to write first in a small or mid-sized company
The first skills that hold up share three traits. The task comes back at least weekly, its output format is stable, and someone can say what separates a good deliverable from a bad one. Here are the candidates Tandem meets most often, by function.
- Sales. Tender response following the buyer's specification, meeting notes written straight into the CRM fields, proposal in the house template.
- Finance. Monthly summary note, consistency check on an accounting export, payment reminder calibrated on invoice age.
- Human resources. Job advert in the company tone, interview grid by profile, answers to recurring candidate questions.
- Marketing. Content brief, style guide applied to an existing text, one message adapted per channel.
- Customer support. Qualification of an incoming request, template answer at the expected level of detail, escalation to the right team.
Anthropic publishes several company testimonials on its Skills product page. Yusuke Kaji, AI general manager at Rakuten, explains there that a management accounting task that used to take a full day now fits in an hour. Notion, Canva, Figma and Box describe the same usage, applied to their own products.
One scoping tip to finish. Start narrow, with skills covering a single task, and merge later when families appear. Three precisely named skills trigger better than one catch-all skill claiming to cover a whole department.
Where to find skills, and how to audit one before installing it
Four skills ship built in and produce clean PowerPoint, Excel, Word and PDF files. Anthropic publishes others as open source, and an ecosystem of third-party skills has grown around the standard. The caution reflex applies to every skill you did not write yourself.
The checks are known and documented by Anthropic: presence of scripts, network calls to external addresses, hardcoded credentials, file paths reaching outside the skill folder, and instructions asking Claude to hide an action. Organisations on an Enterprise licence can turn on automated scanning of uploaded skills, which blocks those that fail the check.
Sharing skills with the team, what works and what does not
This is the topic that surprises IT teams most, because sharing does not work the same way depending on where you use Claude. Three rules to know before launching a rollout.
- In the Claude app. Each person uploads their own skills. There is no centralised admin distribution, which makes sharing a manual job.
- Through the API. An uploaded skill becomes available to the whole workspace. The limit to remember is 20 skills per request.
- In Claude Code. Skills live in folders on the machine or in the project. Project skills are versioned with the code and reach the whole team through a single commit.
One last trap, skills do not sync between surfaces. A skill uploaded in the app shows up neither in the API nor in Claude Code. The workaround is simple: keep your skills in a reference Git repository, and pin a specific version in production rather than the latest available.
Past three or four shared skills, the question becomes organisational. Who writes, who reviews, who updates when the procedure changes. That is exactly the scope of AI governance, and the work looks like a product team's, with an owner per skill and a last review date.
Should you build your own Claude skills?
Yes, and it is probably the AI project with the best effort to result ratio available today. A useful skill takes an hour to write, costs nothing to host and makes every following conversation shorter. Above all it turns knowledge that lived in two people's heads into an asset the whole team uses.
The difficulty sits elsewhere. You have to write down a process nobody had formalised, with the people who run it. Start with one task, one team, one skill. If you already work on your files with Claude Cowork or with Claude Code, you have everything you need to write the first one this afternoon.
