Skill-Creator Claude: Build Skills That Activate

The fastest way to build a good Claude skill is to not write the SKILL.md by hand — you ask Claude to write it for you, using the skill-creator meta-skill. It interviews you about what the skill should do, drafts the file, structures the folder correctly, and even helps you test whether the skill actually fires when it should. This guide covers both halves of that job: using skill-creator to build skills, and fixing the single most common failure mode people hit after — a skill that exists but never activates.

If you have not built a skill before, start with our guide to what Claude skills are for the fundamentals. This article assumes you know the basic shape of a skill and want to go faster and get activation right.

Skill-creator is a skill that writes skills

Skill-creator is a meta-skill — a skill whose job is producing other skills. Instead of hand-writing a SKILL.md file, opening a conversation, and describing what you want a skill to do, skill-creator walks you through naming it, scoping its trigger conditions, drafting the instructions, and laying out the folder. It ships as an official skill from Anthropic and is available as a built-in option in Claude Code and as an installable plugin.

The practical value is not that it saves typing. It is that skill-creator knows the structural mistakes beginners make — descriptions too vague to trigger reliably, instructions that read like documentation instead of steps an agent can execute, folders in the wrong place — and it corrects for them while you are still in the drafting conversation, not three failed activations later.

A skill itself is just a folder containing a SKILL.md file: a short YAML frontmatter block (name, description) followed by plain-language instructions Claude reads when it decides the skill is relevant. For the deeper mechanics of what goes inside that file, see our companion piece on how to build a Claude skill.

What activation actually depends on

Claude does not run every installed skill on every prompt. At the start of a session, Claude loads just the name and description of every available skill — a lightweight index, not the full instructions — and matches your request against those descriptions using its own reasoning, the same way it would match a request to any other tool. Only when a description looks relevant does Claude load the rest of that skill's SKILL.md into context.

That means the description field is not documentation for humans. It is the entire routing signal. A skill with a perfect set of instructions and a vague description will sit unused, and a mediocre skill with a sharp description will fire every time it should. This is the single most common reason a freshly built skill "does nothing" — the instructions were never wrong, they were simply never loaded.

Notice the pattern in the third row: it states what the skill does, then explicitly lists the situations and words that should trigger it. Skill-creator is built to push your draft toward that third row — when you describe a skill in vague terms during the interview, it will ask follow-up questions until you have named the concrete triggers.

Folder placement decides whether a skill exists at all

Before activation matters, the skill has to be somewhere Claude actually looks. There are three valid locations, and mixing them up is the second most common reason a new skill seems to vanish.

Skill-creator asks where you want the skill to live as one of its first questions and writes the folder to the correct path for you — which removes an entire class of "I wrote the file but nothing happened" reports that come from a skill sitting one directory off from where Claude scans. For a broader map of how skills fit alongside CLAUDE.md, hooks, and subagents inside Claude Code, see our Claude Code skills guide.

Building, testing, and iterating with skill-creator

The interaction is conversational, not a form. You open Claude Code (or Claude.ai, where skill-creator is also available), invoke it, and describe the skill in plain language — what problem it solves, when you want it to fire, and roughly what steps it should follow. Skill-creator then drafts the SKILL.md, proposes a name and folder location, and — critically — proposes a description built around trigger phrases rather than a feature summary.

Here is a prompt template that gets a productive first draft out of skill-creator on the first pass, instead of a vague back-and-forth:

Use skill-creator to build a new skill.

WHAT IT DOES: [one sentence — the concrete outcome, not "helps with X"]
WHEN IT SHOULD FIRE: [list 4-6 phrasings a real user would type,
e.g. "format this changelog", "clean up my release notes",
"write a changelog entry for this PR"]
WHEN IT SHOULD NOT FIRE: [anything adjacent that would be a false trigger]
STEPS IT SHOULD FOLLOW: [numbered, in the order you actually do this
task yourself — treat this like training a new hire, not summarizing
a policy]
SCOPE: personal (~/.claude/skills) or project (.claude/skills) — [pick one]

Draft the SKILL.md, propose the folder path, and flag anything in my
description that is too vague to trigger reliably before you finalize it.

The line asking it to flag vague phrasing is doing real work — it is the difference between skill-creator handing back whatever you typed and skill-creator doing the job it is actually good at, which is catching the description problems before you find them the hard way, mid-project, three weeks from now.

Testing whether it actually activates

Do not assume a skill works because the file looks right. Skill-creator also supports an evaluation loop: you (or it) write a handful of test prompts — some that should trigger the skill, some adjacent prompts that should not — and run them to see what actually happens. This catches two failure modes at once: under-triggering, where a reasonable request does not activate the skill, and over-triggering, where the skill fires on requests it has no business handling.

Use skill-creator to evaluate my [skill-name] skill.

Run these test prompts and tell me, for each one, whether the skill
activated and whether that was the correct call:

SHOULD trigger:
1. [realistic phrasing #1]
2. [realistic phrasing #2]
3. [realistic phrasing #3]

SHOULD NOT trigger:
1. [an adjacent but out-of-scope request]
2. [a request that sounds similar but isn't the same task]

If any result is wrong, rewrite only the description field to fix it —
do not touch the instructions unless the activation logic itself is
the problem.

That last instruction matters. Most activation failures are description problems, not instruction problems — rewriting the whole skill when only the trigger phrasing needed a fix wastes a revision cycle and can introduce new bugs into instructions that were already working.

A troubleshooting checklist for skills that will not fire

When a skill you built is not activating, work through these in order rather than rewriting the whole file — the fix is usually one of the first three.

Skill-creator's evaluation loop essentially automates this checklist for you, but it is worth understanding the four causes directly — most real-world reports of a skill "not working" turn out to be step one or two, not a deeper problem with the instructions themselves.

Iterating on a skill after it ships

A skill you built once is rarely the final version. As you use it, you will notice edge cases the instructions did not cover, or requests that should have triggered it but did not. Skill-creator is also the right tool for that revision pass — feed it a real transcript of a failed or awkward run and ask it to update the file.

Use skill-creator to update my [skill-name] skill.

Here is a transcript where it either didn't trigger when it should have,
or triggered and then did the wrong thing:

"""
[paste the relevant exchange]
"""

Diagnose whether this was a description problem (wrong trigger) or an
instructions problem (right trigger, wrong steps), then make the
minimum edit that fixes it. Show me the diff, not just the new file.

Asking for a diff instead of a fresh file matters for the same reason it mattered during evaluation — it keeps you from silently losing working instructions every time you fix one small trigger issue.

Where skill-creator fits next to everything else

Skill-creator is not a replacement for understanding what skills are or how to write one by hand — it is faster once you know the shape of a good SKILL.md, and it catches mistakes you would otherwise only discover through failed activations. If you are new to skills entirely, start with what Claude skills are and how they work, then use our build guide to understand the file structure skill-creator is generating for you. And because a skill is only as useful as the prompts you feed it and the prompts it produces, our Claude prompting guide covers the fundamentals that make both better.

The pattern worth remembering: build with skill-creator, but debug activation with the checklist above before you touch the instructions. Folder placement and description phrasing account for the overwhelming majority of "my skill doesn't work" reports — and both are fixable in minutes once you know to look there first. For the official reference on skills and the SKILL.md format, see Claude Code's skills documentation.

Frequently Asked Questions

These are the questions people ask most often after their first attempt at building a skill did not activate the way they expected.

Do I need Claude Code to use skill-creator, or does it work in Claude.ai too?

Skill-creator is available both as a built-in skill you can invoke inside Claude Code and as part of Anthropic's public skills repository, which you can install and use with Claude.ai as well. The drafting conversation works the same way in either surface — what differs is where the resulting skill folder needs to live.

Why does my skill trigger on requests it shouldn't?

Over-triggering usually means the description is too broad rather than too narrow — it is matching on a general word or theme instead of specific phrasings. Narrow the description to the exact situations the skill handles, and explicitly note what it should not cover, the same way you would list what it should.

Can I have the same skill available personally and inside a specific project?

Yes, but be deliberate about it. If both a personal (~/.claude/skills/) and a project (.claude/skills/) skill share a name, the project version takes priority inside that repo. If you want one canonical version, keep it in only one location rather than maintaining two copies that can drift out of sync.

How do I know if a skill actually loaded during a session?

Ask directly — Claude can tell you which skills it currently sees available and whether a given request would trigger a specific one. This is the fastest way to confirm a fix worked before you run a full test suite through skill-creator's evaluation loop.