| name | skill-creator |
| description | Interactive skill builder: guides the user through defining a new skill as a structured SOP, then generates the SKILL.md and installs it. |
/skill-creator
Build a new toolkit skill interactively. Each skill is a mini SOP (Standard Operating Procedure) โ scoped, self-contained, with clear inputs, process, human gates, and defined output.
Arguments: $ARGUMENTS
<skill-name> โ name for the new skill (e.g., /skill-creator api-designer)
- No args โ ask the user what skill they want to create
Goal
Generate a production-ready SKILL.md file that follows the toolkit's SOP structure, install it into the project's .claude/skills/ directory, and optionally register it as a global slash command.
Dependencies
Tools
Read โ read existing skills for pattern reference
Write โ create the SKILL.md file
Bash โ install to project, optionally register global command
Glob โ find existing skills to avoid name collisions
Connectors
- None required (fully local)
Context
Skills follow a strict SOP structure:
1. Name & Trigger โ skill-name + when Claude should activate
2. Goal โ one clear desired-outcome
3. Dependencies โ tools, connectors, MCP servers needed
4. Context โ background knowledge Claude needs
5. Process โ step-by-step with human checkpoints (APPROVAL GATEs)
6. Output โ where result goes + what the final deliverable is
Critical rules:
- Skills are NOT fully autonomous โ they MUST have at least one human checkpoint
- Each phase should be a discrete, reviewable unit of work
- Error handling must be explicit (table of situations โ actions)
- An internal checklist at the end ensures nothing is missed
Process
Phase 1: Intake โ Understand the Skill
-
Parse $ARGUMENTS for skill name. If empty, ask:
"What skill do you want to create? Describe what it should do in 1-2 sentences."
-
Check for name collisions:
Glob: .claude/skills/*/SKILL.md
If a skill with the same name exists, warn and ask to proceed or rename.
-
Ask the user these questions (batch them, don't ask one at a time):
Skill Definition Questionnaire:
- What does this skill do? (one sentence โ this becomes the Goal)
- When should it trigger? (e.g., "when the user types /foo", "when reviewing PRs")
- What inputs does it need? (arguments, files, context)
- What does it produce? (file, PR, report, code changes)
- Are there external tools needed? (MCP servers, APIs, CLIs)
- How many phases? (suggest 3-6 based on complexity)
- Where should the user approve/review? (which phase boundaries)
-
If the user's description is vague, present 2-3 structured interpretations:
"I see a few ways to interpret this. Which fits best?"
APPROVAL GATE: Present the interpreted spec back to the user. Wait for confirmation.
Phase 2: Design โ Structure the Phases
-
Based on the intake answers, design the phase breakdown:
- Each phase gets: name, numbered steps, and clear completion criteria
- Insert
**APPROVAL GATE** markers where the user indicated review points
- At minimum: one gate after planning, one before final output
-
For each phase, determine:
- What tools/commands are needed
- What information flows from the previous phase
- What can fail and how to handle it
-
Design the error handling table:
-
Design the internal checklist (verification steps before the skill completes)
-
Present the full phase outline to the user:
Proposed Structure:
- Phase 1: [name] โ [what it does]
- APPROVAL GATE after this phase
- Phase 2: [name] โ [what it does]
- Phase 3: [name] โ [what it does]
- APPROVAL GATE after this phase
- Output: [deliverable] โ [location]
APPROVAL GATE: Wait for user to approve the structure. Accept modifications.
Phase 3: Generate โ Write the SKILL.md
-
Read 1-2 existing skills for tone and formatting reference:
Read: .claude/skills/plan/SKILL.md
Read: .claude/skills/code-review/SKILL.md
-
Generate the full SKILL.md following this template:
---
name: <skill-name>
description: "<one-line description>"
---
# /<skill-name>
<2-3 sentence overview>
## Arguments: $ARGUMENTS
- `<arg>` โ description
- No args โ default behavior
---
## Goal
<One clear desired-outcome sentence>
---
## Dependencies
### Tools
- `<Tool>` โ why needed
### Connectors
- `<MCP server or API>` โ why needed
- None required (if none)
---
## Context
<Background knowledge Claude needs to execute this skill properly>
---
## Phase 1: <Name>
1. Step one
2. Step two
3. Present findings to user
**APPROVAL GATE**: <what the user reviews>
---
## Phase 2: <Name>
...
---
## Error Handling
| Situation | Action |
|-----------|--------|
| <situation> | <action> |
## Checklist (Internal โ verify before completing)
- [ ] Item 1
- [ ] Item 2
-
Present the generated SKILL.md content to the user for review.
APPROVAL GATE: User reviews the full SKILL.md. Accept edits before writing.
Phase 4: Install โ Deploy the Skill
-
Write the file:
Write: .claude/skills/<skill-name>/SKILL.md
-
Ask the user if they also want a global slash command:
"Want to register /<skill-name> as a global command? (works across all projects)"
-
If yes, create the command file:
Read and execute the skill defined in .claude/skills/<skill-name>/SKILL.md
User arguments: $ARGUMENTS
-
Verify the install:
Glob: .claude/skills/<skill-name>/SKILL.md
-
Report to user:
"Skill installed:
.claude/skills/<skill-name>/SKILL.md
- Global command:
/<skill-name> (if registered)
Try it: /<skill-name> <example-args>"
Error Handling
| Situation | Action |
|---|
| Skill name already exists | Warn user, offer to overwrite or rename |
| User gives vague description | Present 2-3 interpretations to choose from |
No .claude/skills/ directory | Create it |
| Generated skill is too complex (>6 phases) | Suggest splitting into two skills |
| User wants to edit after install | Re-read, apply edits, re-write |
Checklist (Internal โ verify before completing)