Claude skills for business come down to one practical question: can you roll one out to a team? A skill is a folder holding an instruction file, plus optional scripts and resources, that Claude loads by itself when the task calls for it [S-054]. The answer depends entirely on where you put it.
This is for an owner or team lead deciding whether this is infrastructure or a party trick. The product name is Agent Skills; in running text it is a skill. What the surrounding tooling does is covered in Claude Code for business.
What are Claude skills?
Folders on a filesystem. Anthropic describes them as modular capabilities that extend Claude, where each skill packages instructions, metadata and optional resources such as scripts and templates that Claude uses automatically when relevant [S-054]. In practice:
- a folder, named for what it does
- one
SKILL.mdfile with YAML frontmatter - two required fields:
nameanddescription[S-058] nameat most 64 characters, lowercase letters, numbers and hyphens, and not containing the words anthropic or claude [S-058]descriptionnon-empty and at most 1,024 characters [S-058]- optionally extra markdown files, reference material and scripts in the same folder
No installer, no plan to upgrade to, no storefront. A folder of text somebody in your company wrote.
What can a skill do that a prompt cannot?
Persist. The documentation draws the line clearly: a prompt is a conversation-level instruction for a one-off task, while a skill loads on demand so you do not have to repeat the same guidance across conversations [S-055].
For a company that is the entire value. How your quotes are built, which fields belong in a report, what a handover has to pass before it ships: that knowledge currently lives in two people’s heads and gets re-explained every time. A skill turns it into a file. A file can be reviewed, corrected and handed over. A prompt buried in someone’s history cannot.
WeAdapt runs this way. The pipeline that writes this knowledge base is made of skills, and the studio that produces social posts does the same: one folder per step, holding the method, the rules and the checks. Not a demonstration, just how the work runs.
When does Claude use a skill?
He decides, from one field. The description is what Claude matches your request against when determining whether to trigger the skill, so it has to state both what the skill does and when to use it [S-057].
More rides on that than it looks. A vague description means the skill stays quiet when you need it, or fires when you do not. The authoring guidance is specific about the fix: write the description in third person, because it is injected into the system prompt and an inconsistent point of view causes discovery problems [S-063].
So the field you are most likely to rush is the field that decides whether the skill ever runs. Put the trigger in it, not just the subject.
What does a skill cost in context?
Almost nothing until it fires. That is why you can install dozens, and it is the part no article covers. Skills load in levels [S-056]:
| Level | Loaded when | Context cost | Contents |
|---|---|---|---|
| 1 Metadata | always, at startup | about 100 tokens per skill | name and description from the frontmatter |
| 2 Instructions | when the skill is triggered | under 5k tokens | the body of SKILL.md |
| 3 Resources and code | as needed | nothing until accessed | bundled files; scripts return only their output |
Until a skill is triggered, only its name and description occupy context, which is precisely what makes installing many of them free [S-057]. A script Claude executes contributes only its output to the context, never its own code [S-056].
The consequence for a business is that you do not have to pick which three methods to write down. You can write them all down and let the task choose. The real constraint sits inside SKILL.md: the guidance is to keep that body under 500 lines and split longer material into separate files [S-063].
Does a skill work the same everywhere?
No, and this is the question that decides whether you can roll one out. A skill behaves differently in claude.ai, on the Claude API and in Claude Code. Surface is the word the documentation uses for those environments.
| claude.ai | Claude API | Claude Code | |
|---|---|---|---|
| Who can access it | the individual user only, each team member uploads separately [S-060] | workspace-wide, all workspace members [S-060] | personal in ~/.claude/skills/ or per project in .claude/skills/ [S-060] |
| Central management | no centralised admin management, no org-wide distribution [S-060] | through the workspace [S-060] | through the project, so through your repository [S-060] |
| Syncs across surfaces | no, upload separately per surface [S-059] | no [S-059] | no, separate from both [S-059] |
| Network access | depends on user or admin settings [S-061] | none, and no package installation at runtime [S-061] | the same access as any other program on that machine [S-061] |
| Pre-built document skills | yes [S-064] | yes [S-064] | no [S-064] |
Read the third row twice. Custom skills do not sync across surfaces: what you upload to claude.ai has to be uploaded to the API separately, what you uploaded through the API is not available in claude.ai, and Claude Code skills are filesystem-based and separate from both [S-059].
That lands straight on the rollout question. In claude.ai the answer is: only if every team member uploads it, and an administrator cannot do it for them [S-060]. In Claude Code the answer is yes, by putting the folder in your repository, where it goes through the same review as the rest of your code. That difference is the decision, not a detail.
What a skill is not
Not a model, not an integration, not an agent. A skill does not change what Claude can know, only how it approaches your work. Access to your systems is a separate layer, and that is what MCP covers: the open standard for connections between data sources and AI tools [S-001], explained in what is MCP.
One line to keep: a skill is method, MCP is access. You often need both and they solve different problems. In Claude Code a third layer joins them, where skills package repeatable workflows a team can share [S-048].
How safe is someone else’s skill?
Treat it like software you install. That framing is the documentation’s, not ours: use skills only from trusted sources, because a skill gives Claude new capabilities through instructions and code, and a malicious skill can direct Claude to invoke tools or execute code in ways that do not match its stated purpose [S-062].
So the working agreement is simple and rarely made: somebody reads the skill before it goes into use. All the files, not just SKILL.md, because scripts and resources count too [S-062]. In a repository that is a pull request. In claude.ai it is an agreement, because there is no admin layer in between [S-060].
Skills that fetch data from external URLs deserve extra scrutiny, since fetched content can carry instructions of its own [S-062]. For a first in-house skill that rarely applies: start from a method you already have written down somewhere.
Frequently asked questions
Can we manage skills centrally for the whole team? Not in claude.ai. Custom skills there belong to the individual user, have to be uploaded per team member, and cannot be centrally managed or distributed org-wide [S-060]. Through the API they are workspace-wide, and in Claude Code you share them through the project, so through your repository [S-060].
Does a skill uploaded to claude.ai also work on the API? Not automatically. Custom skills do not sync across surfaces, so you upload them separately for each environment where you want them [S-059]. Plan for that in your maintenance process, otherwise two versions of the same method end up living side by side.
How many skills can we install? Many. Until a skill is triggered, only its name and description occupy context, roughly 100 tokens each [S-056, S-057]. The limit is not the count but the quality of each description, since that is what decides whether Claude picks the right skill.
Can a skill reach our own systems? Not by itself, and it depends on the surface. On the Claude API a skill has no network access and cannot install packages at runtime [S-061]. In Claude Code it has the same access as any other program on that machine [S-061]. Connecting systems is MCP’s job, not a skill’s.
Want to know which method in your company is worth capturing as a skill, and who maintains it afterwards? That is what a training or workshop delivers, or book a call. Work that earns its own entry point sometimes grows into a custom AI tool; what WeAdapt builds and hands over is in the FAQ.