plugin-creator

plugin-creator — build and ship a Claude Code plugin

In: skills/agents/hooks you already have, or an idea for some. Out: a directory that claude plugin validate passes, that loads under claude --plugin-dir, and that a stranger can install.

A plugin is just a directory with a known shape. Almost everything that goes wrong is the shape being slightly off, and the CLI will tell you — so the whole job is: build the shape, run the validator, load it for real, fix what it says.

First decide: does this need to be a plugin at all?

	Standalone .claude/	Plugin
Invocation	/hello	/my-plugin:hello
For	one project, personal, experiments	sharing, versioning, reuse across projects

If the user is customizing one repo for themselves, .claude/skills/<name>/SKILL.md is the whole answer and a plugin is packaging they will never use — say so and stop. Convert to a plugin when someone else has to install it.

Reach for skill-creator instead when the work is authoring one skill's content (what it says, how it triggers, evaluating it). This skill is about the container. They compose: write the skills with skill-creator, ship them with this.

The loop

Everything here is verifiable, so never hand-reason about whether a layout is right — run the command.

claude plugin init <name> --with skills agents hooks   # scaffold (optional)
python3 scripts/preflight.py ./<path>                  # layout + sources
claude plugin validate ./<path> --strict               # manifest JSON
claude --plugin-dir ./<path>                           # load it for real

1. Scaffold or lay out the directories. claude plugin init <name> writes a working skeleton to ~/.claude/skills/<name>/ — which auto-loads next session as <name>@skills-dir with no install step, so it is the fastest way to iterate. --with skills agents hooks mcp lsp output-style channel adds examples of each. For a plugin that lives in a repo instead, create the directories yourself (layout below) — init always targets the skills dir.
2. Write the manifest, if you need one. It is optional: with no manifest, components are auto-discovered from default locations and the name comes from the directory. Add one when you want metadata (version, author, license) or non-default component paths.
3. claude plugin validate. Wrong-typed fields are errors; unrecognized fields are warnings that still load. Use --strict before publishing so a typo'd key (skill for skills) fails instead of silently doing nothing.
4. Load it: claude --plugin-dir ./<path>. Confirm skills appear under /help, agents under /context, and that hooks actually fire.