How to Use Claude Skills for Your Business - Turn a Repeated Job Into a Folder

What is a Claude Skill?

A Claude Skill is a folder of instructions that Claude picks up on its own when a request matches it. At minimum it is a single file named SKILL.md holding the instructions, a name, and a short description of when to use it. It can also carry templates, reference documents, and scripts. Claude keeps the name and description in view at all times, and pulls the full instructions in only when your request actually calls for them. In business terms, it is a written procedure your assistant applies without being reminded.

The reason this matters is that most owners are already doing this work manually and badly. You have a long prompt in a notes app that you paste in whenever you write a proposal. You re-explain your pricing rules every single time. A skill takes that recurring explanation and makes it permanent, so the standard is applied whether or not you remembered to paste it.

• The name and description are the routing layer. They decide when the skill fires, so they matter more than the body.
• The instructions are the body. This is the procedure itself, written as if you were briefing a competent new hire.
• Attached files are the raw material. Your proposal template, your tone rules, your service list, a script that formats an output.

Where do I add a skill?

In the Claude desktop app, in its settings, in the skills section. That is the default path and it should stay the default unless you have a specific reason to leave it. You turn skills on, add the ones you want, and from then on Claude reaches for them when a conversation calls for it. Skills also travel to Claude Code and to the API, because the folder format is the same everywhere.

People assume this is a developer job because the file has a .md extension and lives in a folder. It is not. SKILL.md is plain writing with a short header at the top. If you can write a one-page procedure for a new employee, you can write a skill, and the writing is the hard part rather than the setup. [How to use Claude Code for your business](/blog/how-to-use-claude-code-for-your-business) covers the same desktop-first principle for building software, and skills follow it exactly.

1. Open the desktop app settings and find the skills section, then enable skills if they are off.
2. Add a skill, either one that ships with the app or one you wrote yourself as a folder.
3. Start a normal conversation and make a request the skill should cover. Do not name the skill. You are testing whether the description routes correctly.
4. Check what it produced against the procedure you wrote. If it ignored a rule, the rule was probably buried in a paragraph rather than stated as a line.

What is the One-Job Rule?

The One-Job Rule is our scoping rule for skills: one skill covers one repeated job that produces one kind of output. If you cannot name the output in a single noun phrase, the skill is too wide and needs splitting. A skill called client-proposal works. A skill called sales works badly, because half the requests it fires on are not proposals and it drags irrelevant instructions into every one of them.

Wide skills fail in a specific and confusing way. They still fire, they still produce something, and the something is a blend of every rule in the file. You end up with an invoice that carries proposal language, or a support reply written in the tone of a sales email. Owners then conclude that skills do not work, when the actual problem is that they wrote one skill where they needed four.

Four narrow skills also compose. Claude can use more than one in a conversation, so a narrow refund-reply skill and a narrow brand-voice skill work together without either being rewritten. That composition is only possible when each skill has a clear edge, which is the practical argument for the rule.

What do I actually write inside SKILL.md?

Write the procedure the way you would brief a capable new hire on their first week. Concrete steps, the non-negotiable rules, the format of the finished thing, and the cases where they should stop and ask you. Vague encouragement does nothing. 'Be professional' is not an instruction. 'Never quote a price without listing what is excluded' is.

1. The trigger, restated in the body: when this procedure applies and when it does not.
2. The steps, in order, with the decisions spelled out rather than implied.
3. The hard rules, written one per line so none of them can hide inside a paragraph.
4. The output format, described exactly. Length, structure, and what a finished one looks like.
5. The stop conditions: what should make it hand the job back to you instead of guessing.

The fastest source of skill content is a procedure you have already written down. If your operating procedures exist, most of a skill is a copy edit rather than a blank page. [How to write standard operating procedures with AI](/blog/how-to-write-standard-operating-procedures-with-ai) covers getting those out of your head first, and it is the honest prerequisite for a business with nothing documented.

How are skills different from prompts, projects, and MCP connectors?

Skills carry procedure, connectors carry access, and projects carry context for one body of work. They are not competing choices and most businesses that use AI seriously end up with all three. Confusing them is what leads people to build the wrong thing and then blame the tool.

The pairing that produces the biggest change is a skill plus a connector. The connector fetches the real deal history, the skill decides how the proposal gets written. Neither is much use alone for that job. [How to connect Claude to your business tools with MCP](/blog/how-to-connect-claude-to-your-business-tools-with-mcp) covers the access half, including where to draw the line on write permissions before you connect anything live.

Which skills should a small business build first?

Build a skill for the job you explain most often. That is the whole selection rule, and it beats every list of impressive ideas. The candidate is whatever you find yourself re-describing to an assistant, a contractor, or a new hire, because the cost of re-explaining is exactly what a skill removes.

Notice what is missing from that list: anything that fires without a person reading the result. A skill helps when you are in a conversation applying judgment. A job that must run on Tuesday at 9am with nobody present is an automation, and the right home for it is a workflow tool rather than a chat window.

What is the Skill Shelf?

The Skill Shelf is our rule for keeping a small set of skills that stay true. Every skill on the shelf has a named owner, a written purpose in one line, and a date it was last checked. Anything that fails those three comes off the shelf. The rule exists because skills rot quietly: your prices change, your process changes, and the file keeps confidently applying last year's version.

1. One line of purpose per skill. If nobody can state it, remove the skill rather than debating it.
2. A named owner, even in a business of one. Ownership is what makes a review happen.
3. A last-checked date inside the file. Review when the underlying process changes, not on a calendar reminder.
4. A hard cap you choose in advance. Most small businesses are well served by fewer than ten skills they trust.
5. Delete rather than deprecate. A skill left installed will keep firing regardless of what you meant.

The failure mode to design against is a stale skill applied confidently to a customer-facing document. It looks correct, because it is well formatted and matches the house style. It is simply wrong about a rule you changed in March. [How to stop AI hallucinations in your business](/blog/how-to-stop-ai-hallucinations-in-your-business) covers the verification habits that catch that class of error before a client does.

How do I test a new skill before I trust it?

Test routing and output separately, because they fail for different reasons. Routing failure means the skill did not fire when it should have, which is a description problem. Output failure means it fired and got the procedure wrong, which is a body problem. Diagnosing the wrong one wastes an afternoon rewriting a file that was fine.

1. Make five real requests worded the way you naturally word them, without naming the skill. Count how many fired.
2. Make one request the skill should not touch, and confirm it stays out of the way.
3. Check the output against your hard rules one at a time. Any rule it broke is a rule that needs its own line.
4. Hand it to one other person and watch them use it without coaching. Their wording will expose gaps yours never will.
5. Run it against a job you already finished by hand, and compare. You know the right answer, which is the only way to grade it honestly.

Once a skill passes, the next constraint is human rather than technical. A skill only helps the people who know it exists and trust it. [How to train your team to use AI](/blog/how-to-train-your-team-to-use-ai) covers getting a written procedure actually adopted, which is where most of these efforts stall.

What goes wrong with skills in practice?

The common failures are boring and all preventable. None of them are about the technology being immature. They are about scope, wording, and maintenance, which are the same three things that break a written procedure handed to a person.

• The description is a label rather than a trigger, so the skill sits there never firing.
• The skill covers a department instead of a job, so every output is a blend of unrelated rules.
• The rules are buried in prose. Anything that must always happen belongs on its own line.
• Nobody owns it, so it drifts out of date and quietly starts producing wrong but confident work.
• Twenty skills exist and three are trusted. Volume is not the win here, and unused skills add noise to routing.

There is also a scoping error in the other direction: writing a skill for something that should be software. If the job runs the same way every time with no judgment in it, you may want a small internal tool instead. [How to build an internal tool with Claude Code instead of buying software](/blog/how-to-build-an-internal-tool-with-claude-code-instead-of-buying-software) covers where that line sits.

Write one skill this week

Pick the job you explain most often, write it as one page of steps and hard rules, save it as SKILL.md, and add it in the desktop app. Then use it for a week on real work and fix the two things it gets wrong. One trusted skill beats ten installed ones, and the writing you do for the first is most of the writing you need for the next four. Our [guides](/guides) and [tools](/tools) pages cover the wider setup around it.