Convert a Reusable Prompt Into a Claude Skill

By Yanni Papoutsis | 6 min read | 2026-07-18

If you keep a prompt in a notes app and paste it into Claude every time a certain task comes up, you already have the hardest part of a skill written. What the pasted prompt lacks is automation: you have to remember it exists, find it, and paste it. Converting it into a skill means Claude loads those same instructions automatically whenever the task appears. This post is the conversion procedure, start to finish.

The full authoring fundamentals are in writing a Claude skill from scratch; this post is the shortcut for when the content already exists as a prompt.

TL;DR: A reusable prompt becomes a skill in five steps. First, strip out the parts of the prompt that were only there because pasting loses context, such as "you are an expert X" preambles, which skills do not need. Second, separate the when from the what: the conditions under which you reach for this prompt become the front-matter description, and the instructions themselves become the body. Third, restructure the body from a wall of text into headed sections and numbered steps, because a skill is read as a procedure, not a message. Fourth, replace anything user-specific or secret with placeholders. Fifth, test it in a cold session with the natural phrasing you would have used before the skill existed, and confirm it triggers without being named. The most common conversion failure is a description that describes the prompt instead of the situations that should invoke it.

Why convert at all?

The candidates worth converting: any prompt you have pasted more than three times, any prompt your team shares in a document, any prompt that begins "whenever I ask you to X, always...".

The worked example

Here is a realistic reusable prompt, the kind that lives in a notes app:

You are an expert release manager. When I give you a list of merged
PRs, write release notes. Group them into Features, Fixes, and
Internal. Use past tense. Each line starts with the area in bold,
like **Auth:**. Skip dependabot PRs. Keep it under 300 words. At the
end add an "Upgrade notes" section if any PR touched config or env
vars. My product is called Orbit and the audience is technical
customers, not internal devs.

It works, but only when pasted. Converting it:

Step 1: Strip the paste-era scaffolding

"You are an expert release manager" exists because a pasted prompt has to establish a role from nothing. A skill body is instructions to Claude within an existing conversation; role-play preambles add nothing. Delete them. Similarly delete "When I give you", which becomes the trigger description instead.

Step 2: Split the when from the what

Ask: in what situations did I paste this? Those situations, phrased with the words you actually use, become the description:

name: release-notes-writer
description: Writes customer-facing release notes from a list of merged PRs, grouped into features, fixes, and internal changes. Use when the user asks for release notes, a release summary, or changelog text from PRs or commits.

Note the description does not say "expert release manager"; it says what comes out and which requests should invoke it. This is the step most conversions get wrong, and how skill triggers work covers the craft in detail.

Step 3: Restructure the wall of text into a procedure

# Release Notes Writer

## Output rules

1. Group entries under three headings: Features, Fixes, Internal.
2. Past tense throughout. Each line starts with the area in bold,
   for example **Auth:** fixed session refresh on token expiry.
3. Exclude dependency-bump PRs (dependabot and similar).
4. Keep the whole document under 300 words.
5. If any PR touched configuration or environment variables, add a
   final "Upgrade notes" section listing what operators must change.

## Audience

Technical customers. Assume they read release notes to decide
whether to upgrade, not to admire the work. No internal jargon,
no ticket numbers.

## If information is missing

If the PR list lacks descriptions, ask for the PR titles rather
than inventing what changed.

Three things changed beyond formatting. The rules became numbered and checkable. The audience note became its own section, because in a pasted prompt it was an afterthought and in a skill it is policy. And a missing-information rule was added, because a skill runs unattended in situations you did not anticipate; a pasted prompt always had you watching.

Step 4: Generalise or parameterise the specifics

The original prompt hardcoded "Orbit". Decide deliberately: if this skill is only for one product, keeping the name is fine. If it should serve any project, replace it:

Use the product name from the repository or ask the user; never
write a placeholder product name into the output.

While you are here, sweep for anything that must not ship: real URLs with account IDs, tokens, colleague email addresses. Placeholders like YOUR_API_KEY only.

Step 5: Test with your old phrasing

Install the skill, open a cold session, and type exactly what you used to type before pasting: "can you write release notes for these PRs". The skill must trigger without being named. Then run the negative test: a request that is nearby but different ("summarise these PRs for the standup") should not produce customer-facing release notes. Build both cases into a small eval set per the testing and eval guide.

When a prompt should become two skills

Some reusable prompts are actually two workflows stapled together: "summarise the PRs, then draft the announcement tweet". Split them. Each half gets its own trigger surface, and the combination still works because skills compose, as covered in skill chaining. A skill that does two things has a description that triggers well on neither.

Conversion checklist

- [ ] Role-play preamble removed
- [ ] Trigger situations moved into the description, with real user phrasing
- [ ] Body restructured into headed sections and numbered rules
- [ ] Missing-information behaviour defined
- [ ] Product-specific values kept or parameterised deliberately
- [ ] No secrets; placeholders only
- [ ] Cold-session positive and negative trigger tests pass
- [ ] Original prompt archived with a pointer to the skill

That last item matters more than it looks: delete or redirect the notes-app original, or you will end up maintaining two diverging copies.

Frequently asked questions

My prompt is only four lines. Is it worth converting?

If you paste it repeatedly, yes. Short skills are the best skills: the description does the remembering, and a four-line body costs almost nothing when triggered.

Should I convert my whole prompt library at once?

No. Convert the two or three you paste most, live with them for a week, then continue. Early conversions teach you trigger-writing lessons the later ones benefit from.

Can the skill keep my exact prompt wording?

Mostly, minus the preamble and the "when I give you" framing. If specific phrasings earned their place through iteration, keep them; conversion is about structure and triggering, not rewriting what already works.

About the author

Yanni Papoutsis builds AI products, automation pipelines, and technical documentation with Claude, and publishes free tooling and guides at yanni.uk.

Next step: Go deeper on trigger craft in how skill triggers work, or explore 1,000+ AI tools at yanni.uk/ai-tools.

Sources

• Claude documentation (agent skills): https://docs.claude.com
• Anthropic: https://www.anthropic.com