Claude Skill Generator

A skill is procedural knowledge you hand Claude once and reuse forever: a directory containing a SKILL.md file, made of YAML frontmatter (a name and a description) plus a markdown body of instructions. When a request matches the description, Claude loads those instructions and follows them. It is the difference between re-typing the same three-paragraph prompt every week and just typing a slash command. A skill can also reference extra files beside it - a FORMS.md, a REFERENCE.md, or scripts under a scripts/ folder that Claude runs via bash, where only the output enters the conversation, not the script's code.

Personal skills live at ~/.claude/skills/<name>/SKILL.md and follow you into every project on that machine, but nobody else sees them. Project skills live at .claude/skills/<name>/SKILL.md inside the repo, so committing them to git shares them with everyone who clones it - that is the right home for anything team-specific, like your release checklist or your review standards. There is a third route too: skills can be bundled inside a Claude Code plugin, so installing the plugin brings its skills along - useful for distributing a whole set of skills without asking everyone to copy files by hand. This tool shows you the exact path for whichever of the first two you pick.

State what the skill does and when Claude should use it, in that order, in plain third-person language. The description is the only thing Claude matches a user's request against when deciding whether to run your skill, so a vague one means the skill sits there unused. Name the concrete triggers you expect - 'Use when the user asks to review a PR, check a diff, or asks what looks risky in these changes' - and stay under the 1024-character limit. This SKILL.md generator drafts the description in that what-plus-when shape and warns you live if an edit drops the trigger half.

They control who can start the skill. By default both routes are open: you can type /your-skill yourself, and Claude can trigger it automatically when a request matches the description. Setting disable-model-invocation: true closes the automatic route, so only a human can fire it - that is what you want for side-effecting actions like a deploy, a release or a push, which should never happen because a request sounded vaguely related. Setting user-invocable: false does the opposite: the skill stops appearing as a slash command and only Claude invokes it, which suits background knowledge you want applied automatically. Turning both on would leave nothing able to run the skill, so this builder blocks that combination. Both fields are Claude Code extensions - portable Agent Skills runtimes ignore them, so leave them off if you plan to share the skill more widely.

Only if you are tired of approving the same tool call every run. allowed-tools pre-approves specific tools while the skill is running, written as space-separated patterns like Bash(git add *) Bash(git commit *). Leave it empty and the normal permission prompts apply, which is the safer default for anything you are still testing. Its mirror, disallowed-tools, blocks tools for the duration of the skill - a sensible guard rail on a skill that edits files but should never push. Keep both as narrow as the job actually needs.

They overlap. Claude Code has unified the two: a command file and a skill both give you the same /<name> behaviour and accept the same frontmatter, and both support the $ARGUMENTS placeholder system. The difference is structure - a skill is a folder, so it can carry supporting files, scripts and progressive-disclosure references, and it takes a name field of its own (a command file ignores name and paths, because its file name is the command name). A command is a single markdown file, faster to write when the job is one short instruction. Reach for this Claude Code custom skill generator when the workflow has real steps, and the slash command generator when it does not.