How to Turn a Repeated Prompt Into a Reusable Skill

If you’ve typed some version of the same paragraph into Claude three times this month, that paragraph wants to be a skill.

Here’s the pattern that usually gives it away. You’ve got a task you do often enough to have opinions about it: draft a weekly status update in a certain format, review a pull request against a specific checklist, pull last week’s numbers into a summary that always has the same three sections. Every time, you retype the instructions from memory, or you dig up an old message and paste it back in. It works, but you’re re-explaining the job to Claude over and over, and if you’re doing this on a team, everyone’s re-explaining a slightly different version of the same job.

A skill fixes that by turning “here’s how I want this done” from something you say into something Claude reads.

What a skill actually is

At its core, a skill is a saved set of instructions with a name attached. Instead of typing the instructions into the chat, you type a name, Claude loads the instructions, and it follows them. That’s genuinely the whole idea. The instructions live in a file (usually called SKILL.md), the file has a short description of when to use it, and the moment your request matches that description, Claude can pull it in on its own instead of waiting to be told.

Think about the difference between explaining a recipe from scratch every time you cook it, versus writing the recipe down once and just reading it off the card. The card doesn’t cook the meal for you. It does make sure you don’t forget the ingredient you always forget.

When it’s worth doing

Not every task needs this. If you’ve only done something once, or you don’t expect to do it again in a predictable way, just ask normally. The signal to build a skill is repetition plus specificity: you keep doing roughly the same thing, and you have real opinions about how it should go (this section first, that tone, always check this one thing before finishing).

A few examples that are obviously worth it: a weekly report that always needs the same four numbers pulled from the same two places, a code review pass that should always check for the same three issues, an email reply format you use with a specific client, a research summary that always needs a sources list at the bottom.

Building one

Here’s roughly how it goes, using Claude’s own skill-building skill (yes, there’s a skill for making skills):

Start with the real instructions, not a vague idea. Write down, as specifically as you can, what you want done and how. If you already have a version of this in an old message or email you’ve sent Claude before, that’s your starting draft. The more specific you are about format, tone, and steps, the less Claude has to guess later.

Name it something you’d actually type. The name matters more than it seems like it should, because it’s part of how Claude recognizes when to use the skill later. “Weekly Status Update” is a better name than “Report Thing,” because when you type “can you do the weekly status update,” Claude has an obvious match.

Let Claude turn that into a proper skill file. You don’t need to hand-write a SKILL.md yourself. Describe what you want, and Claude will structure it: a short description of when to trigger the skill, then the actual step-by-step instructions, written so a future session with no memory of this conversation can still follow them cold.

Save it, then actually test it. Trigger the skill on a real task and see if the output matches what you had in your head. If it’s close but off in a specific way (wrong section order, missing a step you always do), that’s not a failure, that’s the first draft doing its job. Tell Claude what was off, and update the skill rather than fixing the output by hand each time. The point is that the correction happens once, in the skill, instead of every time you use it.

Handing it to a teammate

This is where a skill earns its keep in a way a saved prompt in a notes app never quite does. Once it’s packaged, someone else on your team can trigger the exact same process by name, without you explaining it to them first. They don’t need your phrasing. They don’t need to know the format lives in your head. They just need to know the skill exists and what it’s called, and they get the same result you’d get.

That’s a real shift from “ask the person who knows how we do this” to “ask for the thing by name.” It doesn’t replace judgment. Someone still needs to check the output and decide the format still makes sense six months from now. But it does mean the process itself stopped being tribal knowledge.

The part people skip

A skill you build once and never revisit will drift out of date. Update it when your format changes, when you notice it consistently gets one thing wrong, or when the task it covers evolves. Treat it less like a finished tool and more like a habit you’re still refining, one that happens to live in a file instead of in your head.

Once you’ve done this for even one task, you’ll start noticing the other ones. That paragraph you keep retyping? Same signal, same fix.