For a while I did the same kind of work with Claude almost every day. Open a new conversation, paste the same block of context, paste the same list of steps, paste the same examples, then give the task. The next day, paste it all again. Copy, paste, until I knew it by heart.
What felt wrong was that none of that knowledge actually lived with Claude. It lived in my head alone. Every new chat, Claude started from zero. I was never teaching it, I was just telling it again every day. That's the line where a prompt stops being enough, and it's where a skill comes in.
Part 1Where a prompt stops being enough
A prompt is an instruction you type to the model, one at a time. It's great for work that's done in one shot: ask something, have it write something, and the conversation ends.
The trouble shows up when that work becomes routine. A prompt has no memory across chats, and no place to hold the files or tools the task needs. Everything the model has to know, you re-supply every single time, and drop one line and the result drifts. The knowledge never accumulates; it resets every morning.
Most people patch this by making the prompt longer, stuffing everything into one block and saving it to paste back. That helps, but it's still text you have to fetch and paste yourself, with no attached files, no scripts, and the model has no idea it exists until you show it. Skills exist to close exactly that gap.
Part 2So what exactly is a skill
The plainest definition, in Anthropic's own words: "Skills are folders that include instructions, scripts, and resources that Claude can load when needed." That one sentence already carries most of the difference. It isn't text, it's an actual folder on disk.
Inside are three main parts. One is a SKILL.md file that holds the instructions and steps. Two is a short description of what the skill does and when to use it. Three is the files or scripts you can bundle alongside: document templates, reference tables, or real runnable code.
The part that changes the game is how Claude reaches for it. You don't paste it in each time. Claude scans for the skill that matches the task in front of it, and only then loads what it needs. When it isn't relevant, Claude doesn't touch it. That's what lets you keep many skills around without slowing the model down or confusing it: it loads them one at a time, only as needed.
Part 3How it differs from a prompt
Set them side by side and the difference isn't length. It's who owns the knowledge, and who reaches for it.
| prompt | skill | |
|---|---|---|
| When you use it | One-off, ends with the conversation | Packaged, reused over and over |
| Who reaches for it | You type it, every time | The model loads it itself when a task matches |
| What it can carry | Plain text | Instructions + reference files + runnable scripts |
| Where the knowledge lives | In your head, re-pasted each time | In a folder, accumulating |
| Scope | Just this conversation | Build once, use across the Claude app, Claude Code, and the API |
The bottom two rows are the heart of it. However long a prompt gets, it's still knowledge that lives with you and has to be fed in. A skill moves that knowledge into the tool. Package it once and it's ready everywhere, with nothing for you to remember. And because a skill can carry scripts, the work that must be exact has somewhere to live, in code, instead of being left to the model's guess.
Part 4When to package a prompt into a skill
Not everything should be a skill. For one-and-done work, a prompt is better and faster. There are three signals that it's time to package one.
- You're repeating yourself. If you catch yourself pasting the same context or steps for the third time, that's the first sign.
- The task needs files or scripts. If there's a template, a reference table, or a calculation that must be exact, those can't ride along in plain text. They need a real place to live, as files.
- You want the model to reach for it on its own. If you want Claude to pull this procedure up when a matching task appears, without being told every time.
Hit any one of those and it's worth packaging. And there's a bonus: skills use the same format everywhere, so you build once and use it across the Claude app, Claude Code, and the API, with no rewriting per platform.
Part 5Packaging is only the first half
Now you know what a skill is, but packaging it is only the first half of the story. The harder half: since a skill can carry code, the next question is which parts should be code and which should be left to the model. Get that line wrong and a tidy-looking skill turns into something that's sometimes wrong and sometimes brittle.
That line is what moves a skill from "usable" to "ready for production." We pulled that apart in full in don't let the LLM do the math. And real work taught another lesson: before you package anything into a skill, you have to understand the process of the work first, or you're just doing the wrong thing faster.
If you take one thing away, take this. A prompt tells the model what to do once; a skill teaches it how to do it. The next day you catch yourself typing the same instruction for the third time, stop and package it into a skill. That's the first step from prompting AI task by task to building tools the AI can reach for on its own.
Written from real work, not theory, from packaging my own repeated workflows into a handful of skills.
Sources & referencesReferences
- The definition and mechanics of a skill (a folder of instructions, scripts, and resources; loaded only when relevant; same format across the Claude app, Claude Code, API) are from Anthropic, "Introducing Agent Skills", original wording: "Skills are folders that include instructions, scripts, and resources that Claude can load when needed" and "Build once, use across Claude apps, Claude Code, and API."
- The take on prompts running out when work becomes routine is from our own work, packaging repeated workflows into skills.
- This one: what a skill is and how it differs from a prompt (you're reading it)
- The line that makes a skill trustworthy don't let the LLM do the math
- Proving your checker can still catch a mistake the tool you trust to catch mistakes was the one making them