Skill Creator

Turn a plain-English request into a working skill at .claude/skills/<name>/SKILL.md.

Step 1 — Understand the request

Read what the user wants the skill to do. Ask clarifying questions ONLY if the answer changes what you write — at most 2-3, in a single message. Good reasons to ask:

• The trigger is ambiguous ("a skill for deploys" — which environment? which command?)
• The output format matters and is unspecified (file? message? PR?)
• The skill needs project-specific values you cannot infer (URLs, commands, paths)

If the request is already clear, skip questions and build.

Step 2 — Derive the name

• kebab-case, 2-4 words, verb- or domain-led: pr-summarizer, db-migration-check
• No filler words ("helper", "tool", "assistant", "my")
• Must not collide with an existing directory in .claude/skills/ — check first with ls

Step 3 — Write the description (the trigger)

The description decides whether the skill ever fires. Rules:

• State WHAT it does in the first sentence, WHEN to use it in the second.
• Include 3-5 concrete trigger phrases users would actually type, quoted: Use when the user says "review my PR", "check this diff", or asks for a code review.
• Add a negative boundary if confusion is likely: Not for writing new code.
• BAD: "Helps with code stuff." / "A useful skill for reviews." (vague, never triggers)
• GOOD: "Reviews the current git diff for bugs and security issues. Use when the user says 'review my changes', 'check this diff', or asks for a code review before commit."

Step 4 — Write the body

Structure the markdown body as:

1. One-line purpose statement under an # H1 matching the skill name.
2. Numbered steps in imperative voice ("Run git diff", "Ask for X if missing"). Each step must be executable — name the exact commands, files, and outputs.
3. An explicit output format (table columns, file path, message template).
4. A quality checklist the skill must pass before finishing (3-6 verifiable items).

Constraints:

• 40-120 lines total. If it needs more, the skill is doing too much — split it.
• Self-contained: no references to files outside the skill directory.
• No marketing language. Every sentence must change what Claude does.
• Encode failure handling: what to do when a command fails or input is missing.

Step 5 — Save and verify

1. Write the file to .claude/skills/<name>/SKILL.md (create the directory).
2. Re-read it and check the quality checklist below.
3. Tell the user how to test it, exactly:

Your skill is ready. To test it:
1. Start a new Claude Code session (skills load at session start).
2. Type: /<name>            — invokes it directly
3. Or phrase a request matching the trigger, e.g. "<one trigger phrase>"
To make it available in all projects, move the folder to ~/.claude/skills/<name>/.

Quality checklist (verify before finishing)

• Frontmatter has exactly name and description; name matches the directory
• Description states WHAT + WHEN and quotes at least 3 trigger phrases
• Every step is imperative and names concrete commands/files/outputs
• Output format is specified, not implied
• No external file references; no placeholder text left (e.g. "TODO", "<...>")
• Under 120 lines