Skills: package a repeated task once, reuse it forever

What a Skill actually is

A Skill is a packaged set of instructions and resources that teaches Claude how to do one particular task well. Where a prompt is what you type this time, and project instructions shape a whole strand of work, a Skill is a reusable bundle you build once and Claude pulls in whenever the task it describes comes up, in any chat, without you re-explaining anything.

Claude already ships with built-in Skills for producing Word documents, Excel spreadsheets, PowerPoint decks and PDFs; these switch on automatically when the job calls for them. What Level 3 adds is the ability to build your own. A custom Skill is a small folder containing one required file (a SKILL.md written in plain text) plus any extra resources you want it to use, like a template or a house-style example. The SKILL.md starts with two lines of metadata: a name and a description. The description matters more than it looks, because it's how Claude decides when the Skill is relevant. Everything after the metadata is the instructions: how to do the task, step by step, the way you'd brief a capable new colleague.

The key idea is triggering. You don't manually "run" a Skill each time. You describe your task in an ordinary chat, and if it matches a Skill's description, Claude loads that Skill's instructions and follows them. That's why a Skill beats a saved prompt you paste: the paste depends on you remembering to do it; the Skill fires on its own.

Skills are available across the Free, Pro, Max, Team and Enterprise plans, but they require code execution to be switched on in your settings, and you build custom ones under Settings / Customize → Skills. Custom Skills stay private to your account unless your organisation shares them centrally. Treat those specifics as the kind of thing that moves. The Skills help article has today's version.

Building a Skill for a real Fernway job

Here's a task that recurs every single week: Maya Roberts turns the rough operations-sync notes into Fernway's standard "Ops Digest": a three-sentence summary, an actions table with owners and due dates, and a short risks list. She's been pasting the same long formatting instructions into a fresh chat every Monday. That's exactly what a Skill is for.

Step one: write the instructions as if briefing a colleague. Before you touch any files, get the wording right. The fastest way is to have Claude draft it from a good example, then you tighten it.

I want to turn this repeated task into reusable instructions. Every week I convert rough operations-sync notes into a fixed "Fernway Ops Digest" format: (1) a three-sentence summary a manager can read at a glance, (2) a table of every action with columns Action, Owner, Due date, marking any action with no owner as UNASSIGNED, (3) a short "Risks / watch items" bullet list. Tone: plain UK English, warm but efficient. Write me clear step-by-step instructions for this task that I could give to a new colleague, and flag anything they'd need to ask me.

Claude returns a tidy set of steps. You edit it, cutting anything vague and adding a rule it missed (say, "put the nearest due date first"), and you now have the body of your Skill.

Step two: assemble the folder. Create a folder named for the task, for example fernway-ops-digest. Inside it, make a plain-text file called SKILL.md. At the top, add the two metadata lines, then paste your instructions:

name: Fernway Ops Digest
description: Use when turning rough operations-sync or meeting notes into Fernway's standard Ops Digest format: a three-sentence manager summary, an actions table (Action, Owner, Due date; nearest date first; unowned actions marked UNASSIGNED), and a short risks/watch-items list. Plain UK English, warm but efficient.

Instructions:

Read the notes in full before writing anything.
Write a three-sentence summary a busy manager could read at a glance.
Build a table of every action item with columns: Action, Owner, Due date. Put the nearest due date first. If an action has no clear owner, put UNASSIGNED.
Add a short "Risks / watch items" list covering anything raised that isn't yet an action.
If the notes contradict themselves or a date is missing, say so plainly rather than guessing.

If you want the digest to match a template exactly, drop a second file (say example-digest.md with one finished digest) into the same folder, and add a line to the instructions: "Match the layout of example-digest.md." Resources like that are what make a Skill more than a saved prompt.

Step three: package and upload. Compress the folder into a ZIP file. In Claude, go to Settings / Customize → Skills, choose Create skill, and upload the ZIP. Toggle it on. (You'll need code execution enabled first.)

Step four: trigger it. Now open any chat and describe the task in plain words. You don't name the Skill; you just ask.

Turn these operations-sync notes into our Ops Digest. Notes: [paste the Fernway meeting notes].

Claude recognises the task, applies your instructions, and returns the digest in Fernway's format (summary, actions table with owners and dates, risks list) without you pasting a word of formatting guidance. The output looks and reads the same every week, because the instructions are fixed in the Skill rather than retyped from memory.

Skill, Project, or prompt?

These three tools overlap, so the choice is worth naming. A prompt is right for a one-off. Project instructions are right when a whole strand of work shares context and reference files; the onboarding Project from Level 2 is the model. A Skill is right when a specific, repeatable task needs the same method every time, and you want it to fire across all your chats and Projects, not just one. Many people use all three together: a Project for the onboarding work, with the Ops Digest Skill available inside it whenever notes need formatting.

Try it now

Common mistakes

• A vague description that never fires. If the description doesn't name the task in the words you actually type, Claude won't know the Skill is relevant and it just sits there unused. Write the description around real requests, not an abstract summary.
• Putting confidential data inside the Skill. A Skill's files travel with it, and may be shared across an organisation. Keep templates and instructions generic; feed the real data in the chat, not baked into the Skill.
• Building a Skill for a one-off. If you'll do the task once, a prompt is faster. Skills earn their setup only on repeated work.
• Over-trusting the output because it's "automated". A Skill makes the format reliable, not the facts. It will still lift a wrong figure from messy notes, mis-assign an owner, or format a hallucinated action just as neatly as a real one. The consistency is disarming precisely because it looks finished. Read every digest against the source notes before it goes to a manager. The Skill guarantees the shape, never the truth of what's in it.

Keeping current

Skills are a fast-moving area. How you package them, where you upload them, and which plans include what will change. The idea is durable: instructions plus resources, bundled and triggered automatically. For the current mechanics see the Skills help article, the how-to-create-a-Skill guide, and the Claude release notes. Anthropic also publishes example Skills on its public Skills repository. Accurate as of 13 July 2026.