skill-creator

name	skill-creator
description	Use when the user wants to create, improve, or audit a custom skill (slash command) for Claude Code or Cursor. Produces a production-quality SKILL.md or command .md file that follows proven design standards. Does NOT create skills automatically — only when explicitly asked.
allowed-tools	Read, Glob, Grep, Write, Edit

Skill Creator

Create or improve skills that reliably trigger, produce consistent output, and hold up in real use.

What this skill does

• Scaffolds a new .claude/skills/<name>/SKILL.md or .claude/commands/<name>.md file
• Rewrites an existing skill to meet the standards below
• Audits a skill against these standards and reports gaps

What this skill does NOT do

• Create rules files (use manual editing for .claude/rules/)
• Auto-generate skills without the user asking
• Modify CLAUDE.md or project configuration

Standards checklist — every skill MUST pass these

1. Description is a trigger, not a summary

Start the frontmatter description with "Use when..." so Claude can pattern-match reliably.

Bad: "Generates database migrations." Good: "Use when creating a new database migration file. Produces a dated, idempotent SQL migration and updates schema.sql to match."

2. Inputs are explicit

State exactly what the user must provide: file paths, scope description, PR number, etc. Use $ARGUMENTS for required input. If no arguments are needed, say so.

3. Scope is bounded

One sentence on what the skill does. One sentence on what it does NOT do. Prevents accidental activation and scope creep.

4. Outcome over activity

Frame the goal as a deliverable, not a process. "Produce a migration file ready for npm run migrate:test" beats "Write SQL."

5. Success criteria are embedded

Define what "done well" looks like. KPIs if relevant (test pass rate, zero lint errors, etc.).

6. Frameworks are hardcoded

If the skill follows a repeatable structure (checklist, decision tree, template), embed it directly. Don't leave it to inference.

7. Constraints are explicit

List what the output must NOT contain. "No guessed column names." "No npm audit fix --force." "No hardcoded secrets." Constraints separate average from opinionated.

8. Output format is defined

Specify the exact format: markdown table, SQL file, code block with language tag, checklist, etc. Without format rules, outputs drift across invocations.

9. Examples of good output are included

One short example sharpens quality more than ten rules. Show the expected shape of the deliverable.

10. Decision logic is present

What to prioritize. What to skip. What to escalate to the user. Skills that decide produce better results than skills that just produce.

11. The skill is focused

One job per skill. If you need two jobs, create two skills. Clarity beats complexity.

12. Token budget is respected

Keep SKILL.md under 500 lines. Use references/ for detailed docs and scripts/ for executable code. The context window is shared — every token costs.

Template

---
name: <lowercase-hyphenated>
description: Use when <trigger condition>. <What it produces>. Does NOT <boundary>.
---

# <Skill Name>

## Inputs
- `$ARGUMENTS`: <what the user provides>

## Scope
- **Does**: <one sentence>
- **Does not**: <one sentence>

## Steps
1. <Step with concrete action>
2. <Step with concrete action>
3. <Step with concrete action>

## Constraints
- <Hard rule 1>
- <Hard rule 2>

## Output format
<Exact format specification>

## Example output
<Short, concrete example>

## Decision logic
- If <condition>: <action>
- If <condition>: <action>