You Write Good Prompts? Turn Them Into Skills
A good prompt you use every day gets retyped dozens of times. A prompt catalogue soon gets tedious. A modular skill does the job once and takes parameters.
Do you know how to write a good prompt? Good. But if you use it every day, you'll type it dozens of times, each time with a small variation. There are two ways to handle that. The first gets tedious fast. The second is a skill.
A good prompt, as a reminder
A good prompt gives the model what a capable colleague would ask you before starting:
- Context: who you are, who the result is for, and why you need it.
- The task, stated plainly in one or two sentences.
- Constraints: length, tone, format, and what not to do.
- An example of the expected result, when you have one.
- What to do when information is missing: ask rather than make it up.
- How to check: the criteria the result must meet.
For example, to audit a website:
Audit the site durand-law.com. It's a law firm in Lyon.
Three areas: security and compliance, technical and performance, SEO.
Passive tests only: no active scanning, no form submissions.
If the site doesn't respond, stop and explain why.
Deliver a report in English, with fixes ranked by priority.
The problem: you'll type it again
That prompt works. Tomorrow you'll audit another site, in another sector, maybe in French. You'll copy the prompt, change three words, forget a line, and the result will be slightly worse without your knowing why. And when you improve it in a conversation, the improvement stays in that conversation.
Option 1: a prompt catalogue
The natural reflex is a document or a Notion page where you keep your best prompts. At first it helps. Then it gets tedious: find the right prompt, copy it, replace the values by hand, paste it. Versions multiply, improvements made along the way never make it back, and your agents don't know the catalogue exists.
Option 2: a modular skill
A skill is a text file, SKILL.md, kept in a folder your AI tool reads. It holds a name, one line saying when to use it, and then the instructions. In Claude Code, the skill runs when you type its name, /audit-site for instance, or when your request matches its description.
It becomes modular when you separate what changes from what stays. What changes becomes parameters, each with a default value. What stays, the rules, the format and the checks, is written once. Here's the top of my audit skill:
---
name: audit-site
description: Passive audit of a website in three areas (security,
technical, SEO). Use when I type /audit-site or ask to audit a site.
argument-hint: "<url> [sector=lawyer|health|e-commerce] [country=FR] [language=fr] [max=300] [format=html|pdf|md]"
---
## Parameters (default if missing)
- URL: first argument, required. Ask for it if missing.
- Sector: infer it from the site's content.
- Country and applicable law: France.
- Report language: French.
- Cap: 300 pages. Beyond that, sample and say so.
- Format: Markdown report + standalone HTML page.
## Frame
- Passive tests only. No active scanning, no forms.
- Contact no one: we write the report, nothing is sent.
- If the site doesn't respond: stop and explain why.
Now I just type /audit-site durand-law.com sector=lawyer. The rest is already written. For an English-language site, I add language=en and leave everything else alone.
The benefits add up:
- One place to improve. When a result disappoints me, I fix the skill, not the conversation.
- A skill can carry its own reference files and scripts: a scoring grid, a report template.
- My agents use it too, and the same skill serves both Claude Code and Codex.
What else a skill can do
So far, a skill looks like a well-filed prompt. It can go much further.
Carry its own files
A skill's folder can hold more than SKILL.md: reference files and scripts. My newsletter skill has a references/ folder with my editorial method and the newsletter's profile, which it rereads for every issue. Only each skill's description is loaded all the time. The rest is read only when the skill runs, so you can have dozens of them without cluttering the AI.
Connect to your tools: APIs and MCP
A skill can call APIs and MCP servers, the connectors that give AI access to your tools. My audit skill queries Google's PageSpeed Insights API to measure the site's speed. A follow-up skill can read your email and calendar through an MCP server, and leave a draft in Gmail. The draft waits for your click: the skill prepares, you send.
Choose the output format
The output format can be a parameter like any other: format=html, format=pdf, format=md, or a Google Doc. By default, my audit skill delivers a Markdown report and a standalone HTML page that opens in any browser and can be sent as is. With format=pdf, the same audit comes out as a PDF, without changing a line of the rest.
Ask questions before acting
A skill doesn't have to rush ahead. My newsletter skill starts by asking me the tone of the issue, then asks two or three questions to enrich my notes before writing. That's the difference between a text template and a collaborator: it fetches what's missing instead of making it up.
Let code do what code does
Anything that must give the same result every time goes into a script: a measurement, a calculation, a layout. The model keeps what takes judgement. My audit skill measures headers and speed with commands, and the model explains what they mean and what to fix. My video skill writes the script, then tools assemble the edit.
Write the description with care
The description decides whether the skill runs on its own. "Help with audits" is too vague: the AI won't know when to use it. "Use when I type /audit-site or ask to audit a site" says exactly when it applies.
Rule, skill or agent?
The three look alike, but they don't apply at the same moment.
| Tool | When it applies | Example |
|---|---|---|
| Rule | Always, in every session | "Never send an email without my approval" |
| Skill | On demand, for a specific task | /audit-site, the newsletter |
| Agent | When you hand it a whole task, with its own tools | An agent that builds the screens of an iOS app |
Test and evolve a skill
You test a skill like any tool. Before relying on it, I replay it on two or three cases I've already handled by hand and compare the results. After that, every disappointment becomes a fix: one more line in the rules, a parameter, an example. Since a skill is just a text file, keep it in git: you can always go back to an earlier version. And because Claude Code and Codex read the same folder, one fix serves both tools at once.
Turn your prompt into a skill
- Take the prompt you've used most this month.
- Separate what changes from one use to the next from what stays the same.
- Give each parameter a default, and say what to do if a required one is missing.
- Write one line saying when to use the skill.
- Save it all as
SKILL.md, in a folder named after the skill, under~/.claude/skills/. - Each time the result disappoints you, fix the skill.
You can even ask the AI to do the conversion: paste your prompt and ask it to turn it into a skill with parameters.
