How do you turn your best prompts into reusable skills?

A good prompt is usually the result of many rounds of correction. Saving it in a document helps, but you still have to find it, paste it and remember which version worked. A skill packages that knowledge so the assistant can pick it up by itself when the task comes along.

In the format Anthropic introduced for Claude in October 2025, now published as an open standard called Agent Skills, a skill is simply a folder. Inside is a file named SKILL.md with a short header and your instructions, plus optional extra files such as scripts, reference documents or templates. The assistant sees only each skill's name and description at first, and reads the full instructions when a task seems to match. Anthropic calls this progressive disclosure: loading detail only when it is needed, so many skills can be installed without crowding the conversation.

When a prompt is ready to become a skill

Not every prompt deserves a skill. Good candidates share three traits:

A one-off question or a prompt you are still experimenting with is better left as a prompt.

A worked conversion: meeting notes to action summary

Suppose you refined this prompt over a few weeks:

Turn these meeting notes into a summary for people who missed it.
Start with decisions (one line each), then action items as a table
with owner and due date, then open questions. Under 200 words.
Use names exactly as written. If an action has no owner, write
"Owner needed" instead of guessing.

1. Create the folder and header. The specification requires two fields: name, lowercase with hyphens and matching the folder name, and description, which should explain the task it handles and the situations that call for it. The description is what the assistant reads to decide whether to load the skill, so include the words people actually use.

---
name: meeting-summary
description: Turns raw meeting notes or transcripts into a short summary with decisions, an action-item table and open questions. Use when the user shares meeting notes, minutes or a transcript and asks for a recap, summary or follow-up.
---

# Meeting summary

## Steps
1. List each decision in one line, in the order it was made.
2. Build a table of action items: Action | Owner | Due date.
3. List open questions that still need an answer.
4. Keep the whole summary under 200 words.

## Rules
- Copy names exactly as they appear in the notes.
- If an action has no owner, write "Owner needed". Never guess.
- If no due date is given, write "No date".
- Do not add decisions that are not in the notes.

## Example
See examples/sample-notes.md and examples/sample-summary.md.

2. Add an example. Put one realistic set of notes and the summary you would accept in an examples/ folder. An example shows the format far more reliably than a description of it. Use invented or anonymized notes, never a real confidential meeting.

3. Write down your tests. A test is an input plus what a good answer must contain. Keep them in a short file inside the skill folder:

The last test checks the description. If the skill doesn't load when people phrase the request naturally, add those words to the description.

4. Run, fix, repeat. Try each test in a fresh conversation. Anthropic's engineers advise starting from the gaps you actually observe on real tasks, rather than guessing in advance what the skill might need. When something fails, change one rule, run the tests again, and keep the skill short; long reference material belongs in separate files the skill points to.

How do you share them with a team?

How you share depends on where your team works with Claude. In the Claude apps, Skills are available on Pro, Max, Team and Enterprise plans, and on Team and Enterprise an administrator has to turn them on for the organization first. Since December 2025, Anthropic has also offered organization-wide management of skills, which lets administrators look after one approved set for the whole organization.

For teams using Claude Code, a skill is just a folder, so the simplest approach is to keep skills in a shared code repository. Each change then has an author, a date and a review, and anyone can roll back a version that made results worse. Developers using the API can upload and version custom skills through its skills endpoint.

Whatever the method, agree on a few habits. Give one person ownership of each skill. Keep the tests inside the folder, and run them again before you publish a change. Note at the top of the instructions who maintains it, or use the optional metadata field for an author and a version number.

Finally, treat skills from outside your team with care. A skill can contain scripts that Claude runs, and Anthropic warns that a malicious one could expose data. Install skills only from sources you trust, and read the instructions and any code before you add one to your team's set.