What Are Claude Skills and How Do You Use Them?

A good prompt is still just a message. You write it, Claude reads it in that one conversation, and if you want the same careful instructions next week you either remember to paste them again or you don't. A skill removes that step entirely. It sits on disk (or inside a project, or inside a plugin) and Claude checks whether it's relevant to what you're currently asking, without you having to mention it by name.

That checking step is worth understanding because it's the actual mechanism, not a marketing word. Claude keeps a short description of every skill available to it, one or two sentences, and only reads the full instructions when your request lines up with one of those descriptions. This is sometimes called progressive disclosure: the short version is always in view, the long version loads on demand. It's why you can have a folder of a dozen skills installed and Claude won't slow down or get confused picking between them; most of what's in each one stays unread until it's actually needed.

The second real difference is that a skill can carry more than instructions. A prompt can only ever be words. A skill can include a script that does the boring, exact part of a task, reformatting a date, checking a file against a rule, running a calculation, so Claude isn't retyping logic from scratch inside its own response every time. That's a meaningful jump: it's the difference between explaining how to do something and handing over a tool that already does part of it.

None of this makes a skill smarter than Claude. The model behind a skill-aided answer and a plain-prompt answer is the same model. What changes is reliability and repetition: a skill is a way of making sure the same careful process runs the same way every time, instead of depending on you remembering to ask for it correctly.

What made a skill worth posting about on X wasn't a new capability nobody had seen before. Claude could already do the underlying task, whatever it was, if someone wrote a detailed enough prompt. What people were reacting to was the gap between "I have to explain this carefully every single time" and "I just ask, and it already knows the careful version." That gap is the entire pitch of a skill, and it's genuinely visible the first time you see one in action, which is why it travels well as a short clip or screenshot.

It's worth being honest about what that moment doesn't prove. A viral skill demo shows one task, done well, once. It doesn't tell you how that skill behaves on a messier version of the same task, what happens when the input doesn't match what the author expected, or whether the skill was written carefully enough to fail safely instead of guessing. Treat a skill you see trending the same way you'd treat a recipe you found online: promising, worth trying, and worth reading through before you follow it exactly.

The more durable lesson from moments like this is about where the leverage actually sits. The value wasn't in a flashier model. It was in someone taking the time to write down, once and clearly, a process they'd otherwise have re-explained from scratch every time. That's a skill you can build for yourself on day one, for something boring and specific in your own work, without waiting for anyone else's viral moment.

You don't need to be a programmer to write a skill, because the core of it is a markdown file, the same kind of plain text you'd use for a README or a set of notes. The header needs a short name and a one-sentence description. That description is the single most important line in the whole file, because it's what Claude checks against your future requests to decide whether to load the rest.

The body of the file is just clear instructions, written the way you'd explain the task to a careful colleague who's doing it for the first time. State what the task is, what a correct result looks like, and anything that commonly goes wrong. If part of the task is mechanical and exact, like checking a number against a rule or reformatting text a specific way, that's a candidate for a small script rather than another paragraph of prose.

The best first skill to write is almost always something you already do by hand, repeatedly, with a process you could describe in a few sentences. Not a sweeping ambition like "write better blog posts," but something narrow: a specific check you run on every draft, a specific way you want commit messages formatted, a specific review you do before sending an email. Narrow skills are easier to write correctly and easier to trust later, because there's less room for the instructions to drift away from what you actually meant.

It's easy to blur skills together with other words you've heard in the same conversations, like "tools" or "MCP." They're related but they sit at different layers. A tool is a specific action Claude can take, searching the web, reading a file, running a command. MCP (the Model Context Protocol) is a standard way of connecting Claude to tools and data that live outside the conversation, like a project management system or a database.

A skill doesn't replace either of those. It's a layer on top: a packaged set of instructions that often tells Claude how to use the tools it already has access to, in a specific order, for a specific purpose. A skill for reviewing pull requests, for example, might rely on Claude's existing ability to read files and run commands. The skill is the judgment and process wrapped around those existing abilities, not a new ability by itself.

Once that distinction is clear, the rest of the skills landscape gets easier to read. When you see a skill described as connecting to something external, that's the skill using a tool or an MCP connection underneath it, not a fourth separate thing. The skill is the recipe; the tools and connections are the kitchen it's cooking in.