What a Skill Actually Is

The paragraph you have typed forty times

Every new conversation, you rebuild the same scaffolding. Our meeting notes start with decisions, then actions with an owner, then anything unresolved. No bullet longer than a line. Never use the word synergy. You type some version of that, the work gets done, the conversation closes. Tomorrow you type it again.

If you did the context engineering course you already have half an answer: a standing brief, kept in a note outside the chat, pasted back in whenever a session drifts. That genuinely works. It also means you are the delivery mechanism. Every time it gets used, it is because you remembered.

A skill is the durable version of the same idea. You write the brief once, put it somewhere Claude can reach, and stop being the one who carries it.

The requirement, before anything else

Skills need Claude Pro, Max, Team or Enterprise, with code execution enabled. If you are on a free plan, the ideas here will still make sense, but you will not be able to follow along. Nothing else on this site needs a paid plan, so there is no harm in reading now and building later.

Who should skip this course

This is the first Intermediate course here, on a site otherwise written for people who do not code, and it would be dishonest not to say so plainly. Everything else happens inside a chat box. This one asks you to keep a file in a folder and edit it in a plain text editor. No programming, no command line, no scripts. But it is a step up, and two groups should leave it for now.

Skip it if you have not yet hit the repetition problem. If you use Claude a few times a week on varied one-off tasks, there is nothing durable to write down, and a skill will just be a file you forget you made. Come back the third time you catch yourself typing the same paragraph.

Skip it if maintaining a document in a folder sounds like a chore you will resent. That is a fair preference, not a failing. Do the context engineering course instead, keep a standing brief in a note, and paste it when you need it. You get most of the benefit and none of the upkeep.

How we do meeting notes:

Decisions first, one line each
Then actions, each with a named owner and a date
Then open questions, clearly marked as unresolved
No bullet longer than one line
Never use the words synergy, leverage or robust

So what is a skill

A skill is a folder. Inside it sits a document of instructions, and optionally whatever else that document needs: reference material, examples, small helper files. That is genuinely the whole shape of it. It is not software you install, and it is not a settings screen you fill in.

The centre of the folder is a document called SKILL.md. It has two parts. At the top, a few labelled lines, rather like the header on a form: a name, and a description of when the skill applies. Below that, ordinary written instructions. If you can write a handover note for the colleague covering your holiday, you can write this.

meeting-notes
SKILL.md          the instructions, and the labelled lines at the top
examples.md       optional: two notes that came out right
house-style.md    optional: anything long you want kept separate

Why five skills do not clutter every reply

The obvious worry: if I have five of these, is Claude reading all five before every answer, and is my actual work getting crowded out?

No, and the reason changes what you can put in one.

At the start of a session, Claude reads only the name and description of each skill. Nothing more. Picture a shelf of ring binders: it reads the spines. When a task matches one of those descriptions, it takes that binder down and opens it, and only then do the full instructions arrive.

That is progressive disclosure, and the consequence is generous. A skill can be long. Worked examples, awkward edge cases, the three exceptions your team argues about every quarter: none of it costs you anything until the moment it is relevant. So write the instructions properly rather than squeezing them into something terse.

The trade is that the description now carries enormous weight. It is the spine of the binder. If it does not say clearly when this skill applies, the binder never comes off the shelf, and everything you carefully wrote inside stays invisible. Lesson 4 is largely about getting that one line right.

Read at the start of every session:
name: meeting-notes
description: when this skill applies, in one or two lines
Read only when a task matches that description:
everything else in the document, however long it runs

Where they work

The same skill works in Claude.ai, in Claude Code and through the Claude API. Which matters mostly because the effort is not tied to one place. What you write today for the chat window is not wasted if your work moves somewhere else later.