Do I need to know how to code to write a skill?

No. A skill is a folder with a Markdown file in it, and Markdown is just text with a few formatting marks. Everything that makes a skill good — knowing what the standard is, what the common mistakes are, what the finished thing should look like — is domain knowledge, not technical knowledge. In practice the best skills come from the person who does the work, not from an engineer. You can even ask Claude to write the file while you describe the rules out loud.

How is a skill different from a prompt template I paste in?

Two things: it fires without you, and it doesn't have to be pasted. A template only helps when you remember it exists and go and find it — which is exactly when you're rushed and won't. A skill carries a description of when it's relevant, so Claude picks it up on its own the moment the situation matches. It can also carry more than a paste reasonably can: reference material, examples, checklists, even scripts.

Won't a pile of skills slow Claude down or clog its context?

Not if they're written properly, because skills load progressively. What's always in view is just each skill's name and one-line description — a few dozen words each. The full instructions are read only when a skill is actually judged relevant to what you're doing. That's the whole design: you can have thirty skills installed and pay almost nothing for the twenty-nine that don't apply right now.

When should something be a skill rather than just a document?

Make it a document when a human needs to read it and decide. Make it a skill when Claude should apply it without being reminded — a repeated standard, a house format, a checklist for a recurring task, or the conventions someone learns in their first month. The test is simple: if you've explained the same thing to a fresh session three times, that's a skill you haven't written yet.

What are Claude Skills? (in plain English)

You’ve got a way of doing things. Your weekly report has a particular shape. Your team never uses the word “leverage” in customer-facing writing. Numbers are always in the local currency first. The client summary always leads with the decision, not the background.

None of this is written down anywhere, and that was fine when only humans did it — people absorbed it in their first month by having drafts handed back to them.

Then you start working with Claude, and you find yourself explaining it. Every session. Same paragraph, retyped. By the third time, you’ve stopped briefing and started performing manual data entry on your own house rules.

A skill is the file where those rules go to live permanently.

What a skill actually is

Strip away the jargon and it’s genuinely this simple: a skill is a folder containing a Markdown file of instructions, plus a one-line description of when it’s relevant.

That’s it. The file — SKILL.md — holds two parts:

A short bit of front matter with a name and a description. The description is the important half: it’s what Claude reads to decide whether this skill applies to what you’re doing right now.
The body: your actual instructions. The standard, the steps, the format, the things that always go wrong, what a good result looks like.

The folder can hold more than that — reference documents, example outputs, checklists, even scripts for the technical cases — and Claude will read those as needed. But a genuinely useful skill is often one page of text.

The thing that makes it a skill rather than a note in a drawer is that Claude checks the descriptions on its own, and when one matches the situation, it reads the file and follows it. Nobody had to remember it existed.

The idea that makes it work: loaded on demand

This is the part worth understanding, because it explains both why skills scale and why writing a good description matters more than writing good instructions.

Claude has a working memory — the context window — and everything it can see at once competes for that space. If every rule your team ever wrote were permanently loaded, you’d fill it with irrelevant material and get worse answers, not better.

So skills load progressively. What’s always in view is just the names and one-line descriptions — a handful of words per skill. The full body is read only when a skill is judged relevant to the task at hand.

Two consequences follow, and they’re the practical heart of using skills well:

You can install a lot of them cheaply. Thirty skills cost you thirty short lines of always-on context. The twenty-nine that don’t apply today are essentially free.
The description is the whole ballgame. A brilliant skill with a vague description (“helps with documents”) never fires, because nothing ever obviously matches it. A modest skill with a sharp description (“use when drafting or reviewing the weekly client status report”) fires exactly when it should. Write the description as when to use this, not what this is.

Skill, command, memory, plugin — the quick map

Four things sit near each other and get confused constantly. The short version:

A skill is know-how that fires automatically when the situation matches. You don’t invoke it.
A slash command is a shortcut that fires when you type it. Same kind of content, opposite trigger. (Skill vs slash command has the full comparison.)
Project memory (a CLAUDE.md file) is always-on background about this specific project — the stuff that’s true of every task here. (CLAUDE.md vs memory.)
A plugin is a bundle: several skills, commands, and connections packaged so you install them in one step. (Skill vs plugin.)

The useful heuristic: if you’d want it applied without being asked, make it a skill. If you’d want to summon it, make it a command. If it’s true of everything in this project, put it in memory.

What a good skill contains

Most first attempts fail the same way — they’re a description of a topic rather than instructions for doing a job. Three parts fix that.

1. When to use it. Stated in the description, in the words someone would actually use. Not “document standards” but “use when writing or reviewing any customer-facing document.” Be generous with the trigger phrasing — this is the part that decides whether the skill ever runs.

2. What to do. The actual procedure or standard. Concrete and ordered. Not “ensure quality” but “lead with the recommendation; three bullets of evidence; always give the number in AED first with USD in brackets; never open with background the reader wrote themselves.”

3. What good looks like. An example. This is the most-skipped part and it does the most work — for the same reason a sample beats an adjective when you’re briefing a person. One short worked example teaches more of your house style than a page of description of it.

Add a fourth if it applies: what usually goes wrong. The mistakes you find yourself correcting are the highest-value thing you know, and they’re invisible to anyone who hasn’t done the job.

Five skills a non-technical team would actually use

To make it concrete — none of these involve code:

House writing standard. Tone, banned words, how you refer to customers, formatting conventions, currency and date format. Fires on anything customer-facing.
The weekly report. The exact shape of your recurring report, which sources it draws on, what leadership actually reads, what to leave out.
Client onboarding checklist. The twelve things that must happen, in order, with the two everyone forgets flagged.
Data hygiene. Your redaction rules — what must be stripped before material goes anywhere, in your team’s specific vocabulary. (Pairs with the tiering in can I put company data into AI.)
Meeting notes to actions. How you turn a raw transcript into the decisions-and-owners format your team uses, including who typically owns what.

Notice that each one is something a new hire would take a month to learn by osmosis, and none of them existed as a written document before you wrote the skill. That’s not a coincidence — building skills tends to force teams to articulate standards they’d only ever held tacitly, which turns out to be valuable independently of the tool.

How to write your first one

Don’t design a system. Pick the single thing you’ve explained most often in the last month.

Open a session and just say it out loud — the standard, the steps, the mistakes, the format. Don’t polish.
Ask Claude to turn that into a SKILL.md, with a name, a “use when…” description, the instructions, and one worked example. It will produce the file; you’re the one who knows whether the content is right.
Read the description critically. Would it obviously match, in the words you’d actually be using at the time? This is the line to fuss over.
Use it for a week and edit it when it’s wrong. Every time you correct Claude on something the skill should have covered, that correction goes into the file. After three or four rounds it stops being wrong.

That fourth step is the real method. A skill isn’t a document you author once; it’s the accumulated record of every correction you stopped having to repeat.

Where this fits in the bigger picture

Skills look like a small convenience feature, and they’re really an answer to the central problem of working with capable agents — which is that a fresh session knows everything about the world and nothing about you. (What is an AI agent covers why that gap exists.)

Better prompting narrows the gap one request at a time; that’s a genuine skill and we cover it in how to ask AI for what you actually want. But re-explaining your standards forever doesn’t scale, and it doesn’t transfer — the colleague who joins next month starts from zero again.

A skill is the version that compounds. Written once, applied automatically, shared with the team, improved every time it’s wrong. The organizations getting real leverage out of these tools right now are mostly not the ones with cleverer prompts. They’re the ones that stopped re-explaining themselves.