Walk the user through creating a new Claude Code skill step by step.
Step 1 — Name and scope
If $ARGUMENTS is provided, use it as the skill name. Otherwise ask the user for a name (lowercase, hyphens allowed).
Ask whether this should be a personal skill (~/.claude/skills/<name>/) or a project skill (.claude/skills/<name>/).
Step 2 — Gather requirements
Ask the user these questions (use AskUserQuestion):
- •What should the skill do? — get a plain-language description of the desired behavior.
- •Who triggers it?
- •User only (
disable-model-invocation: true) — good for actions with side effects - •Claude only (
user-invocable: false) — background knowledge Claude applies automatically - •Both (default) — Claude can invoke it when the description matches
- •User only (
- •Does it need arguments? — if yes, ask for an
argument-hint(e.g.[filename],[issue-number]). - •Should it run in isolation? — if the skill does heavy read-only analysis, suggest
context: forkwith an appropriateagenttype. - •Should tool access be restricted? — if the skill should be read-only or limited, ask which tools to allow.
Step 3 — Write the SKILL.md
Using the answers, generate the SKILL.md file with:
- •Correct YAML frontmatter (
name,description, and any optional fields gathered above). - •Clear, concise markdown instructions (under 500 lines).
- •Use
$ARGUMENTS/$0/$1where the user wants input substitution.
Create the directory and write the file.
Step 4 — Trigger analysis
Before finalizing, carefully review the skill for triggering issues. Consider and briefly report to the user:
- •False positives — Is the
descriptionbroad enough that Claude might invoke the skill when the user didn't intend it? If so, tighten the wording or adddisable-model-invocation: true. - •False negatives — Would a user who wants this skill use phrasing that doesn't match the description? If so, broaden the description or add synonyms.
- •Collisions — Could the description overlap with other common skills (e.g. a "review" skill clashing with PR review)? If so, make it more specific.
Suggest concrete revisions if any issues are found. Apply them with user approval.
Step 5 — Token efficiency review
Review the skill's instructions and identify steps where Claude would spend many tokens doing work that a shell script or CLI command could handle instead. Common opportunities:
- •Listing/searching files →
find,grep,globin a script - •Parsing structured data (JSON, YAML) →
jq,yq - •Gathering git context → a small shell snippet in the instructions
- •Repetitive formatting → a template file or
sed/awk - •Heavy analysis →
claude -pas a subprocess with a focused prompt
Present any suggestions to the user. If they agree, update the skill instructions to delegate that work to commands.
Step 6 — Confirm
Show the user the final file contents and the slash command they can use to invoke it. Mention they can test it immediately with /<name>.