The AI Skill Builder: make your own Claude skill yourself

The problem behind this is familiar to anyone who works with AI regularly. You have a prompt that works well. You save it in a note, you paste it in again every time, you tweak it slightly every time, and after three weeks there are four versions and nobody knows which one is the good one. A skill fixes that: the method is set once, the assistant picks it up when it is needed, and everyone in your company works from the same file. What is left is that the file has to exist first, and that is exactly where most people go wrong.

Because writing a skill is not hard, it is just not what people think it is. Most first drafts are a vibe description: you are an experienced copywriter, you write catchy copy, you pay attention to the target audience. That reads pleasantly and does nothing, because there is not a single action in it the assistant can carry out and not a single point where you can tell whether it worked. The second mistake sits in the description: it is so generic that the assistant never picks it up, or so broad that it picks it up for everything. And the third is scope: a skill that handles everything around customer contact ends up doing nothing well.

We built the builder to take those three mistakes out before you ever use the file. It forces the goal into the shape verb plus outcome. It writes the description in three parts, including the sentence that says when the skill should specifically not trigger. It turns the method into numbered steps. And it only delivers after it has attacked its own concept against eight checks and written down, per check, what it changed.

It is useful for two kinds of people. For anyone who does not have a skill yet but does have a method that is the same every time: assessing quotes, checking invoices, writing a standard email, summarising a call in your team's format. And for anyone who already has a skill that does not work: it never triggers, or it triggers on everything, or it gives back something different every time. In that second case the skill runs in review mode: it tests the existing file, says what is good about it, and delivers a rewritten version with the difference alongside it.

A limit is stated in the file right away, and we take it over here literally: this is not a programming tool. This skill does not write an MCP server, a plugin or an API integration. If you are actually looking for tools for your AI instead of instructions, that is a different subject, and our MCP server page NL explains it. Instructions fix how work gets done. A tool gives the AI the ability to do something. That difference clears up a lot of confusion.

The description is a label instead of a net. This is the most important one, and the least well known. An assistant does not read all your skills. For every available skill it only sees the name and the description, and only once that description touches on what you are asking does it read the rest of the file. If it says "Helps write customer-friendly emails", that touches the word write, so it also triggers when you have it check a piece of code. What should be there are the sentences the way people type them, plus a sentence that says where the skill should stay silent.

The instructions say what the AI should be, not what it should do. You are an experienced specialist. You think strategically. You write with a feel for language. There is nothing to follow there, so something different comes out every time, and that is exactly the complaint people bring to this skill. Every sentence that only describes an attitude gets rewritten into an action with an outcome you can check. If more than one in four are like that, the file is not an instruction but an introduction.

The scope is too wide. Customer emails is not a task but a category. A return question, a delivery complaint and an invoice question call for different structures, and a file that wants to serve all three ends up in generalities. The test is simple: can you describe the skill in one sentence with a verb and an outcome? If there is an "and" between two unequal tasks, that is two skills. The builder then proposes the split and already gives the second skill a name, so you can build it later.

There is no output format and there are no refusals. Without fixed headings you get two shapes for two requests, and then the skill is worthless for a team. Without refusals the assistant invents whatever is missing: an order number, a delivery date, a goodwill arrangement the company does not offer. So it demands a minimum of five refusals, of which at least two go against the user's own convenience. A list of only pleasant refusals is cosmetic.

In diff form, with the three lines from the second example in the skill and what comes back for them.

Next comes a chapter on what the skill rests on. It sets out how the format works: a small folder with a SKILL.md in it, YAML frontmatter with at least a name and a description, and loading in layers, where the assistant first sees only those two fields. That chapter also names the sources, and they can be checked: Anthropic's own documentation on Agent Skills, their own example collection on GitHub including a skill-creator, the working-method thinking from obra/superpowers, the second pass from blader/humanizer, and the way the marketplaces skills.sh and find-skills from vercel-labs make skills findable on their description.

The core is nine fixed steps. It first asks which single task it should become and forces the answer into the shape verb plus outcome. It tests the scope and proposes a split if there are two. It writes the frontmatter in three parts. It turns the method into numbered steps. It sets out the input checklist and the output format. A minimum of five refusals go on paper. It writes at least one fully worked example. And last, it runs the self-check pass and only delivers after that.

Before the skill starts it runs through a six-point input checklist: the task in one sentence, what the user supplies when they use the skill, what good work looks like, the fixed rules of the field such as VAT and invoice requirements, GDPR, professional conduct rules or house style, what must never happen, and where the skill is going to run. On that fifth point there is an instruction that pays off a lot: keep asking until at least five things are on the table that must never happen. People usually know exactly what must not happen, but they only name it once you ask.

The output has a fixed structure of six blocks. First the file itself in a code block, ready to save. The folder name and the installation line per environment. The self-check pass report, eight lines long. Three test sentences to try yourself, plus one sentence that should deliberately not trigger it. What was deliberately left out of the skill, with the name a second skill could get. And finally the limit: what the skill cannot do and at what point a human should check along.

There is also a chapter of writing rules for the file you produce. You-form, no formal address. Actions in the imperative or the third person. No long dashes in running text. AI in capitals. No promises about time saved or results, because a skill fixes a method and guarantees no outcome. And the rule that a long list or a template belongs in a separate file next to the SKILL.md, with a reference to it, so the main file stays about one subject.

Finally there are two fully worked examples in it, and that is deliberate. The first builds a new skill for a fictional accounting firm: from the question about invoices to the complete file, including the self-check report where you see a claim about a fine getting cut because it could not be checked. The second is a review: an existing skill from a fictional webshop agency that triggers on everything, with the verdict per check, the rewritten description, the replaced attitude sentences and the refusals that were missing, including the GDPR rule that only the data needed for that answer goes into the email.

The official examples are on GitHub, in anthropics/skills. There is also a skill-creator there: a skill that writes skills. That is not a curiosity but a sign that the meta level is being taken seriously, and it is the reason we built a Dutch-language variant. The format has been an open standard since December 2025, so the same file also works in Codex, Cursor and Gemini CLI. So you are not building a skill for one brand but for a file format.

The attitude comes from obra/superpowers. That is a collection of skills that enforces methods instead of suggesting them: think first, then build; tests first; debug systematically. The lesson from that in our builder is short: instructions are not advice. If a skill says "you could consider", the assistant chooses for itself, and then you get something different every time again. Hence the numbered steps and the fixed order.

The second pass comes from blader/humanizer. That skill strips AI writing patterns out of text using a numbered pattern list, and the clever part is not the list but the method: rewrite first, then attack your own result, then deliver. That pattern has been taken over here as the self-check pass. We built a Dutch-language variant of it, the AI Text Humanizer, because the Dutch AI tells are partly different from the English ones.

From the marketplaces comes the realisation that a skill has to be found. skills.sh lists hundreds of thousands of skills, and the most installed one is find-skills from vercel-labs: a skill that finds and installs skills. That says something about the pile. What is not found does not exist either, and getting found happens here on the description. That is exactly why the trigger test in FIG.03 is a fixed step and not a suggestion.

The fourth source is our own pile. We built a hundred Dutch-language skills and maintain them, and the mistakes this builder catches come from there. Descriptions nobody's phrasing touches. Instructions that only say what the AI should be. Zips where the file sat loose at the root instead of in a folder, so the skill will not install however good the content is. That last one is a separate check in the pass, because we have had to fix it ourselves seven times.

We do not quote figures on how much time a skill saves or how much better the work gets. There are none, at least not in a way we can check, and the file itself forbids that kind of promise. A SKILL.md fixes a method. Whether that method is good is decided by the work that comes out of it, and that stays human work.

After that, using it is simple: describe in plain language the work you keep explaining from scratch, and what must never happen. It asks itself what is missing, one thing at a time. If you already have a SKILL.md that does not do what you want, just paste it into the conversation; the skill then switches to review mode and delivers a rewritten version with the difference alongside it. What comes back goes into a folder with the same name as the name field, and that folder goes to the spot from the list above.

One more practical point that often goes wrong: the folder name. If the folder is named differently from the name field in the frontmatter, the skill is not recognised. And the file has to be called exactly SKILL.md, in capitals, inside the folder and not next to it. That sounds like a detail until you spend half an hour looking for the reason nothing happens. If you are not yet sure what a skill actually is before you make one, start with the explanation of Claude skills NL.

It also works for tidying up. If you have three half-finished skills that overlap, hand over all three and ask for a breakdown. The scope test is suited for that: it names which tasks belong together and which need to be separate, and gives the loose parts a name. You get a proposal back there, not a decision, because you know better than a file which tasks belong together.

There are situations where you are better off leaving it, and the file is brief about that. Not for installing an existing skill, because that is a manual and not a build request. Not for building an MCP server, a plugin or an API integration: that is code, not instruction. Not for writing a loose prompt or a system prompt for a chatbot, because that is a different kind of text with a different purpose. And not for programming work where code is the end product.

One more honest limit, and it is the most important one on this page. A skill like this has no memory. It teaches your AI how something works, but every new session starts empty. What you decided last week, which client has which appointment, what was rejected last month and why: a skill does not know that and cannot know it. Anyone who wants that does not need a better skill but a place where that knowledge stays put. The next section is about that.

And finally: the builder writes the file, you assess it. It cannot know whether your field rules are correct, whether your output format is what your clients expect, or whether a refusal is missing that is obvious in your field. Read the file all the way through once before you roll it out to your team. If you would rather do that together, or your whole team needs to learn to work with it, then an AI training NL is the shortest route. More background on the writing itself is in the guide on writing a SKILL.md NL.

After that you run into two limits. Skills know how something should go, but remember nothing between sessions: that is where Jarvis starts, one brain all your skills and all your AIs draw on, from €9 per month including VAT. And a skill cannot touch anything in your own systems: for that you connect tools through MCP NL. If your team needs to learn to write this kind of file itself, we do that in the AI training NL.