One skill beats another agent.
Anthropic's own engineers argue for one general agent with a library of skills. Here is how to build your first skill that holds up on real work, in under an hour, and knows when to switch itself on.
Free. No email required, nothing to download.
Skills are in Claude on the Free, Pro, Max, Team and Enterprise plans. They need code execution switched on, and on Team and Enterprise an admin has to enable skills for the organisation first.
To find them: open Customize, then Skills, then the plus button, then Browse skills. That is the current path. If you have seen a walkthrough that starts from the plus menu in the composer, it is out of date.
Recording yourself to create a skill is much narrower than it looks. It is called Record a skill, it is on Pro, Max and Team only, and it works only in Cowork in Claude for Mac. It is not in chat, not on Windows, and not on Free or Enterprise. Everything else on this page works on any plan that has skills, so we build by writing and by conversation instead.
You need one job you repeat. Not a clever idea for a job. Something you did last week and will do again this week, the same way.
Two of Anthropic's own engineers, Barry Zhang and Mahesh Murag, gave a talk at the AI Engineer Code Summit called "Don't Build Agents, Build Skills Instead". Their argument is that the agent architecture underneath is more general than people assumed, so building a fresh agent for every job is wasted effort. One capable agent with a library of skills covers more ground.
The difference is worth getting straight. The agent is the worker. A skill is a job the worker knows how to do, written down. Ten agents gives you ten things to set up, watch and keep current. One agent with ten skills gives you one thing to look after, and it gets better every week you add to it.
That is also why a skill is worth more than a saved prompt. A prompt has to be found and pasted. A skill is read by Claude on its own when the work matches it.
One folder with one file in it, called SKILL.md. The top of the file holds a name and a description. Everything below is the instructions, in plain English. No code, unless you want it.
The description is doing more work than it looks. Claude reads only the name and description of every skill you have until a request matches one, and then opens the full file. Anthropic calls this progressive disclosure: the toolbox stays shut until you need the tool. It is why you can have thirty skills without any of them slowing Claude down, and why a vague description means a skill that never fires.
A complete, working skill can be this short.
--- name: enquiry-reply description: "Drafts replies to new client enquiries in our voice, with pricing from our price list. Use whenever I paste an enquiry, forward an email from a new lead, or say reply to this." --- # Enquiry reply ## Steps 1. Work out what they are actually asking for. 2. Answer that first, in two sentences. 3. Give the price from the price list. Never estimate one. 4. End by offering a call. ## Rules - Never quote a price that is not on the list. Ask us instead. - No more than 120 words.
The name is capped at 64 characters and the description at 200. That cap is the real constraint on rule one below, and it is the reason to write the description deliberately rather than letting it ramble.
This is the step that saves the most time and the one everyone skips. A lot of the obvious skills are already written, maintained by someone else, and free.
Look in Claude's own skills directory first, under Customize, then Skills, then Browse skills. Then look at skills.sh, which is an open directory maintained by Vercel with a few hundred skills in it and a one line install command. GitHub is worth a search too, and there are skills whose whole job is finding other skills for you.
A skill can carry scripts, and scripts run. Installing a stranger's skill is closer to installing software than to pasting a prompt. Read it first, or have Claude read it for you with the prompt below. This matters more than anything else on this page.
Paste the link or the files in, and do not skip the last line.
Before we install this skill, read every file in it: [LINK OR FILES] Tell me in plain English: 1. What it actually does, step by step. 2. Whether it runs any scripts or code, and what those do. 3. Whether it sends anything anywhere, and where to. 4. What permissions or access it needs. 5. Anything that looks risky, careless or more than the job needs. Quote the lines you are basing each answer on. If you cannot read part of it, say so rather than assuming. Do not install it until I say yes.
A plain English account of what you are about to run. If the answer is vague or it cannot read part of the skill, that is your answer.
The description is how Claude decides whether to open the skill at all. Most skills that "do not work" are written fine and described badly, so they never get read. Say exactly when to use it, in the words you would actually use.
Every description needs three things in it.
Keep it inside 200 characters. If it will not fit, the skill is probably trying to do two jobs and should be two skills.
One AI tool or system you can use, every week. Free. Get the newsletter →
Writing a skill from a blank page produces a description of how you imagine you work. Do the job once with Claude in an ordinary chat instead, get the result right, and then turn that conversation into the skill. The chat already contains the real steps, including the corrections you made along the way.
Claude can also build one by interviewing you, which is the better option when the job is not in front of you. Either way, make it ask questions first.
Run this in the same chat, straight after the output came out right.
We just did this job together and the result is right. Turn exactly how we did it into a skill. Ask me questions first, one at a time, until you know: 1. When I would use this, including the phrases I would actually say. 2. What I will give you each time. 3. The steps, in the order we really did them. 4. The rules we followed, including the ones I corrected you on. 5. What good output looks like. 6. What you should never do in this job. Then write the SKILL.md. The description must say exactly when to use it, name my trigger phrases, and cover the situations where it should fire even if I do not name the skill. Keep the description under 200 characters and the name under 64. Show me the file before you save anything.
A SKILL.md built from a job that actually worked, with the corrections you made baked in as rules.
Run it on three real jobs. Not a demo, not the example you built it from. Open a fresh chat each time and make a normal request without mentioning the skill, so you find out whether the description is doing its job.
When the output is wrong, the instinct is to fix the output. Change the skill instead, so the same mistake cannot come back next week.
That output had these problems: - [PROBLEM ONE] - [PROBLEM TWO] Do not just fix this answer. Update the skill so it cannot make these mistakes again. Then: 1. Tell me in one line what you changed and why. 2. Show me the changed part of the file. 3. Run it again on the same job so I can see the difference. If a problem was caused by something missing from what I gave you rather than by the skill, say that instead of adding a rule.
A skill that is one mistake better. Three rounds of this is the difference between a skill that works and a skill you abandon.
Our own receipt for this. We rebuilt our hook writing skill after testing its rules against 105 of our own LinkedIn posts. Our best opener did 2,802 impressions and our worst did 90, and the rules that came out of that comparison are what is in the skill now. The first version was written from what we assumed worked.
If a skill never fires on its own, the problem is almost always the description, not the instructions. Go back to rule one and add the phrases you actually used in the chat where it failed to load.
Copy this, fill in the brackets, and you have a working skill. Every heading below is there because Claude uses it. The description is the only part worth labouring over.
Save it as SKILL.md in a folder named after the skill.
--- name: [short-name-with-dashes] description: "[What it does, in one sentence]. Use whenever [trigger phrases], or when [situations], even if I do not name this skill." --- # [Skill name] ## What I will give you [The inputs. A pasted email, a file, a link, a set of numbers.] ## Steps 1. [First step] 2. [Second step] 3. [Third step] ## Rules - [Something we always do] - [Something to never do] ## What good looks like [Describe it, or paste a real example of a great output. An example beats a description.]
Keep the name under 64 characters and the description under 200. Paste a real past output under "What good looks like" if you have one, because it teaches more than any rule you could write.
Skills started at Anthropic and were released as an open standard in December 2025, now governed at agentskills.io. More than 40 platforms read the same format, including Codex, Cursor, Gemini CLI, GitHub Copilot, Windsurf and Zed.
So the folder you build today is not locked to one tool. If you move, the skill moves with you, which is a reasonable argument for writing your process down as skills rather than keeping it in a tool's own settings.
One folder that holds a job you used to explain every week, with a description specific enough that Claude opens it without being asked, rules that came out of real mistakes, and an example of what good looks like. It took under an hour and it works in more than 40 tools.
The habit is the valuable part. Every time Claude gets something wrong in that job, change the skill. After a month the skill knows things you would struggle to write down from memory.
Three worth building first, in this order.
The tools, prompts and systems we actually use. Free, unsubscribe anytime.
Get the newsletterTell us about your team and the tools you use, and we’ll reply within 48 hours with a training plan built around your real work.