Turn Your Repeated Prompts into Claude Code Skills

Look at the prompts you pasted into Claude this week. At least one of them was the same long block of instructions you pasted last week, with a small edit at the end. That prompt should be a command. In Claude Code, a skill turns any repeatable workflow into something you run by typing its name, and it takes about five minutes to build one.

What a skill is

A skill is a folder with a SKILL.md file inside. The file has a short header (frontmatter) that says what the skill does and when to use it, followed by your instructions in plain Markdown. The folder name becomes the command. A folder called release-notes gives you /release-notes.

Two things make skills better than a saved prompt in a notes app:

• They load on demand. Until a skill is used, only its short description sits in context. The full instructions arrive when you call it, so ten skills cost far less than ten paragraphs in your CLAUDE.md.
• Claude can use them on its own. If your request matches the description, Claude loads the skill without you typing anything.

If you used custom slash commands before, they have been merged into skills. Files in .claude/commands/ still work, but new work should go into skills because they support extra files and more options.

Build your first one

Pick the task you repeat most. For me it is often writing release notes from a batch of commits, so that is the example. Create the folder in your personal skills directory so it works in every project:

mkdir -p ~/.claude/skills/release-notes

Then save this as ~/.claude/skills/release-notes/SKILL.md:

---
description: Writes user facing release notes from recent commits. Use when I ask for release notes, a changelog entry, or a "what's new" summary.
argument-hint: [audience or focus]
disable-model-invocation: true
allowed-tools: Bash(git log *)
---

## Recent commits
!`git log --oneline -30`

## Instructions
Write release notes for: $ARGUMENTS

1. Group changes into New, Improved and Fixed. Skip internal refactors and dependency bumps.
2. Write for users, not developers. One short sentence per item, starting with a verb.
3. Mention the screen or feature by the name users see in the app.
4. End with a list of anything you were unsure about, so I can check it.

Now type /release-notes iOS users, focus on the new onboarding. A few things are happening here:

• $ARGUMENTS is replaced by whatever you type after the command. Use $0, $1 and so on for separate arguments.
• The line starting with ! runs the command before Claude reads the skill, so the real commit list is already inlined. The allowed-tools line pre-approves that command, because an injected command that would need your permission stops the skill instead of asking.
• disable-model-invocation: true means only you can trigger it. I set this for anything with side effects or anything I want to run at a moment I choose.

Claude Code watches the skills folders, so a new or edited skill is picked up in the current session without a restart. Run /skills to see everything that is available.

Personal or project

• ~/.claude/skills/<name>/SKILL.md works in all your projects on this machine.
• .claude/skills/<name>/SKILL.md inside a repository works in that project. Commit it and everyone on the team gets the same command.

If a personal and a project skill share a name, the personal one wins. When you want to share a set of skills across many repositories, package them as a plugin.

Write descriptions Claude can act on

The description decides when Claude reaches for a skill on its own. "Writes reports" is too vague to trigger reliably. "Writes the weekly client status report. Use when I paste raw meeting notes and ask for the weekly update" works, because it names both the job and the moment. Put the key use case first, since long descriptions are cut short in the skill listing.

Two more habits that pay off:

• Most important instructions first. After a long session is compacted, invoked skills are brought back with a size cap and the start of the file is what survives.
• Move bulk into supporting files. Templates, examples and reference docs can sit next to SKILL.md in the same folder. Tell Claude in the instructions when to read them.

Let Claude write the skill for you

You do not have to write the file by hand. After you finish a task you liked, ask Claude to turn it into a skill while the details are fresh:

Turn what we just did into a personal skill at ~/.claude/skills/design-qa/SKILL.md.
Write a description that says what it does and when to use it.
Keep the steps in the order we actually followed, include the checks that caught problems, and leave out anything specific to this one screen.
Show me the file before saving it.

Anthropic also publishes a skill-creator skill in its public skills repository that helps you build and test skills, along with other examples worth reading.

Skills in the Claude app

Skills are not only for the terminal. In the Claude app, go to Customize, then Skills, and upload a ZIP of the skill folder. Code execution needs to be turned on in your settings first. The help center guide walks through the format. If you sign in to Claude Code with the same account, skills you enabled in the app are synced to your machine too.

Ideas worth turning into skills

• A design QA pass: check spacing tokens, contrast, focus states and empty states on a screen.
• A weekly update that turns raw notes into your team's exact format.
• A pull request description written from the current diff.
• A copy review that checks tone, spelling rules and banned phrases.
• A research brief that turns links and notes into a one page summary.

One caution: a skill can include scripts and instructions that run on your machine. Only install skills from sources you trust, and read the SKILL.md before you do.

Start with one skill for the task you repeat most, use it for a week, and fix it every time the output needs a manual edit. Once it runs without edits, build the second one. The official skills docs cover every frontmatter field when you are ready for more.