How to build Claude Skills for work

Building a Claude Skill is trivially easy. Building one that does the work well repeatably, and that you can keep making better as you and your team leans on it more, is a different problem entirely.

The fastest way to learn how to build a skill: open Claude, tell the built-in skill-creator what you want it to do, and let it build a first draft. Give it more instructions about how you do the work, what you want the output to be like, and the tools it needs. Refine the task by running your work through it and learning from the outputs.

You can build a working Skill before you can finish reading this article. Once you have one ready, you can go deeper into the details to improve it and understand how to share Skills across your team.

What is a Claude Skill?

Skills are a feature in Claude that lets you teach it how to handle specific tasks using your team's processes, preferences, and expertise. You describe the job once, and Claude does it that way every time after that. You improve the Skill over time by using it and learning from how it works.

Anthropic's framing for building one is "like putting together an onboarding guide for a new hire."

The same skills can also guide your AI agents. An agent handling a product update can use a skill to follow your reporting process, alongside connectors that give it access to the source data.

Building and testing the skill yourself helps you work out the instructions before using them in a more automated workflow. To reuse it in a custom agent, make sure that agent has access to the skill, its supporting files, and the required tools. 

A Skill is made up of instructions and supporting resources are packaged in a folder containing:

• SKILL.md (required): The main instruction file. It starts with YAML frontmatter containing the Skill's name and description, followed by the steps Claude should follow.
• Scripts (optional): Executable code for tasks such as processing data or validating output.
• References (optional): Supporting documentation Claude can consult, such as workflow rules or API guidance.
• Assets (optional): Templates, fonts, and other files used to produce the finished work.

Claude uses progressive disclosure to load these components as needed. The name and description help it identify relevant Skills; the full instructions load when a Skill is invoked. Supporting files are accessed when the task calls for them, keeping background documentation from filling every conversation.

Anthropic's own complete guide to building Skills covers the full technical checklist, and its public Skills repository is worth browsing for real examples that follow the pattern.

Skills need connectors and MCP to reach your tools 

If the task depends on Asana, Slack, or a CRM, start by checking Claude's existing connectors. For a ready-made connector, you can select the service and authorize access, subject to your organization's settings.

These connectors use the Model Context Protocol (MCP), the standard behind Claude's connections to external tools and data. The integration is already built, so you don't need to set up an MCP server yourself. If the available connectors don't cover your system or workflow, you can add a custom connector using an MCP server supplied by a vendor or built by your team.

The connector provides access to data and actions. The Skill tells Claude which sources to use, what order to follow, and how to handle the results.

Check the required tools and permissions before writing the workflow. Include instructions for unavailable connections or missing access: identify the gap and stop the affected step. A report built from half the required sources should say so.

Write a description that’s easy to trigger 

Claude finds Skills the way a person finds a specialist on a team: by reading a short description of what they do and when to ask for them. That description is the entire discovery mechanism – at startup, Claude sees the name and description of every available Skill and matches a request against them before it ever opens the full instructions.

The structure that works: what it does, when to use it, and its key capabilities, in under 1,024 characters, with no angle brackets. Compare:

• Too vague: "Helps with projects."
• Specific and actionable: "Analyzes Figma design files and generates developer handoff documentation. Use when user uploads .fig files, asks for 'design specs,' 'component documentation,' or 'design-to-code handoff.'"

The first one won't trigger reliably, or it'll trigger on everything and crowd out other Skills. The second tells Claude exactly when to reach for it, in the words a person would actually use.

Start with one workflow and define good output

Start with the weekly update before attempting a Skill that handles all product operations. Specify its inputs, required sections, and stopping points.

For example, require every blocker to link to its source task. If an owner or date is missing, label it unknown. Have Claude prepare the update for review and wait for approval before posting it to Slack.

Include one approved example so Claude can see the expected level of detail. These decisions also give you something concrete to test.

In a Reddit discussion about a month of building Skills, u/uebersax described copying their best prompts into skills and getting only modest improvement. They reported better results after getting specific about the role, constraints, and output. It's a useful reminder to show Claude the decisions behind the work, including what an acceptable result looks like.

As related Skills accumulate, check for overlapping descriptions. In Claude Code, large Skill listings can cause descriptions to be shortened to fit a context budget, potentially removing useful trigger words. There is no useful universal Skill-count target for every team. Check what Claude can see, then test whether it selects the right workflow.

Do Skills need updated with new model launches?

The instructions you write today can turn into dead weight faster than you'd expect. When Anthropic launched Opus 5, Boris Cherny, who created Claude Code and now leads it at Anthropic, said on stage at Y Combinator that the team had deleted 80% of Claude Code's system prompt.

Most of what they cut was correcting behavior the new model already handled on its own. The product got better.

Your Skills accumulate the same kind of scaffolding. Steps you added because a model kept skipping them. Warnings you wrote because it kept fumbling an edge case. A newer model may need none of it, and what's left is your instructions arguing with the model's own judgment.

You don’t need to rebuild your Skills every time Anthropic releases a new model, but you should re-test them on the work they support. 

How to share and maintain Claude Skills across your team

Once a Skill works, give the team one approved version to use and one place to suggest improvements. Otherwise, five people can end up maintaining five slightly different versions of the same workflow.

Start with a shared Skill. On Team and Enterprise plans, Skill sharing works in both chat and Cowork, subject to your organization's settings. Recipients can use the Skill but can't edit it, and the owner's updates reach them at next use. For one recurring task, this is a straightforward way to keep everyone working from the same instructions.

Bundle related Skills into a plugin. A product-team plugin could contain Skills for weekly updates, release notes, and launch reviews. An organization-managed marketplace gives teammates a common place to get approved plugins in chat and Cowork. Members can't edit organization-managed plugins.

Use GitHub when you need a review and release process. Keep the source files, tests, and change history in a private or internal repository connected to a GitHub-synced marketplace. Review changes through pull requests and release tested versions. Sync can be manual or automatic; automatic sync requires a merged pull request with a plugin version bump.

For a single workflow, start with sharing. As the collection grows, plugins and GitHub give the team a more structured way to maintain it. Name an owner, retire duplicate personal copies, and route improvements back to the shared version. Keep a previous working release and re-test when the model, connectors, or workflow changes.