Claude Skills: What They Are and How to Build Your First One

What is a Claude Skill?

A Skill is a packaged procedure. At its core it is a folder with a SKILL.md file that has a short description and the instructions for doing one kind of task well. It can also include supporting files, such as templates, reference material, or scripts. Claude reads the description to decide when a Skill applies and loads the full instructions only then.

Anthropic describes Skills in the Claude Code documentation as a way to package repeatable workflows that a team can share, with examples such as a pull-request review command or a staging deploy. The same idea applies well beyond code: a monthly report, a contract intake checklist, a brand-voice edit.

If you want the official definition and current mechanics, read the Skills documentation.

When should you build a Skill instead of a prompt or a Project?

Build a Skill when the work is a procedure with steps, not just context. Use a prompt for a one-off. Use a Project for standing context and reference material. Use a Skill for "here is exactly how we do this, every time."

The test is repetition plus consistency. If three people do the same task three slightly different ways, and you want the best way to win, you have a Skill candidate.

How do you structure a good SKILL.md?

A good SKILL.md has a precise description, a clear trigger, ordered steps, and a definition of done. The description matters most, because it is what tells Claude when the Skill applies.

---
name: weekly-status-report
description: Use when the user asks for the weekly project status report. Turns raw notes and ticket updates into the standard one-page report.
---

# Weekly status report

1. Ask for the notes and the reporting period if not provided.
2. Group updates under: Done, In progress, Blocked, Next week.
3. Flag any item with no owner or no date.
4. Keep the report to one page. Plain language, no jargon.
5. End with a list of decisions needed from leadership.

Definition of done: every item has an owner, and blocked items say what unblocks them. ```

Tips from practice:

• Write the description from the user’s point of view: when would someone ask for this?
• Number the steps. Ambiguity is the enemy.
• Include a definition of done so the output can be checked.
• Keep each Skill to one job. Split anything that grows an "also" clause.

How should teams share and govern Skills?

Treat Skills like small pieces of company process, because that is what they are. Someone should own each one, review changes, and retire it when the process changes.

A lightweight governance model:

1. Owner. Each Skill has a named maintainer.
2. Review. Changes are reviewed by a second person before they are shared.
3. Source review. If a Skill includes scripts, have someone who understands them read the code before it is used. Do not install Skills from sources you have not vetted.
4. Test cases. Keep two or three example inputs and the expected shape of output.
5. Registry. One list of approved Skills, with owner and last-reviewed date.

Skills are a natural focus of the advanced track in a training program, because they turn individual expertise into something the whole team can use.

What are good first Skills for a business team?

Start with a task that is frequent, boring, and clearly defined. Good first candidates include a meeting-notes-to-action-items conversion, a standard customer reply review, a document intake checklist, a weekly report, and a policy-to-plain-language rewrite.

Avoid starting with something judgment-heavy or high-stakes. A first Skill should build confidence, not test the limits of the technology. Once people see a Skill save them twenty minutes a week, they will bring you the next five candidates themselves.

For how Skills fit with Projects and connectors, see our guides on Claude Projects and Claude connectors and MCP.

Where do Claude Skills live and how are they invoked?

In Claude Code, a skill is a directory containing a SKILL.md file, and where you put the directory decides who gets it. Anthropic’s documentation lists these scopes:

You can invoke a skill directly by typing /skill-name, or Claude can load it automatically when its description matches the task. If names conflict, enterprise skills win over personal, and personal over project. The documentation also notes that personal skills in ~/.claude/skills/ are not available in Cowork or cloud sessions unless you enable them on your claude.ai account.

What can the SKILL.md frontmatter control?

All frontmatter fields are optional, but the description is recommended because Claude uses it to decide when to load the skill. Useful fields, per the documentation, include:

• name: the command name, defaulting to the directory name.
• description and when_to_use: what the skill does and when to use it.
• disable-model-invocation: set to true so only a person can trigger it. This is a good default for anything with side effects, such as a deploy.
• allowed-tools: tools Claude can use without approval while the skill runs.
• context: fork: run the skill in a subagent.
• paths: glob patterns limiting when Claude auto-loads the skill.

Outside Claude Code, such as skills uploaded on claude.ai, only a smaller set of fields is accepted, and other fields cause an error. The documentation recommends keeping SKILL.md under 500 lines and moving detailed reference material into supporting files that the skill points to.

For a business team, the practical rule is simple: put side-effect skills behind manual invocation, keep descriptions precise, and keep reference documents in separate files so the skill stays short.

What are good business skill examples to start with?

Strong first skills are repeatable, text-heavy, and easy to check:

1. Weekly status report. Ask for notes, group into done, in progress, blocked, next; flag items with no owner or date.
2. Meeting notes to actions. Extract decisions, owners, and due dates in a fixed table.
3. Customer reply review. Check a draft against tone, policy, and a never-promise list.
4. Policy plain-language rewrite. Convert a dense policy into a one-page summary, preserving required terms.
5. Document intake checklist. List what is missing from a submitted packet.

Share them through a reviewed library with an owner for each. When you are ready to move from single skills to role-level bundles, see Claude Cowork plugins.

Frequently asked questions

Product features, plans, and limits change often. This guide reflects the vendor documentation listed above as of November 2026. Check the vendor’s current documentation before you make purchasing or policy decisions. TechStack Consulting is an independent training firm and is not affiliated with Anthropic or OpenAI.