A plugin bundles the pieces you have already written — commands, subagents, skills, hooks — into one folder somebody else can install. The manifest is small and mostly uncontroversial, which is why the mistakes in it are so annoying: a version that is not a version, a name with a capital letter in it, a homepage missing its scheme. None of those stop the file being valid JSON, and all of them cause trouble later. This builder fills the fields in, checks the ones with rules, and shows the layout the manifest expects around it, since the manifest on its own does nothing — the folders beside it are what actually get loaded.
Features
Name checked against the naming rules
Version checked as a semantic version, prereleases included
Author name and email nested correctly rather than flattened
Homepage checked for a scheme
Empty fields omitted rather than written as blanks
The folder layout shown alongside the manifest
Keywords entered one per line
Downloads as plugin.json
How to use the Plugin Manifest Builder
Name the plugin and give it a starting version
Describe what it bundles
Add the author, homepage and licence if you are sharing it
Download plugin.json into the .claude-plugin folder
Example
Input
"version": "1.0"
Output
Error: not a semantic version — use major.minor.patch
Two-part versions are the most common rejection.
Common errors & troubleshooting
The version is rejected. — Semantic versions have three parts: 1.0.0, not 1.0. A prerelease suffix such as 1.0.0-beta.1 is fine.
The plugin is not found after installing. — The manifest belongs at .claude-plugin/plugin.json inside the plugin folder, not at its root. The layout below the output shows where everything sits.
The name is rejected. — Lowercase letters, digits and single hyphens. It is used as an identifier, so capitals and spaces are out.
Nothing loads even though the manifest is valid. — The manifest only describes the plugin. Commands, agents, skills and hooks are loaded from the folders beside it — an empty plugin with a perfect manifest does nothing.
Frequently asked questions
What can a plugin contain?
Any combination of slash commands, subagent definitions, skills and hooks, each in its own folder beside the manifest. All of them are optional — a plugin that ships one useful command is a perfectly good plugin.
Which fields are actually required?
The name, in practice. Everything else is metadata that makes the plugin usable by other people: a description so they know what it is, a version so they can tell when it changed, and a homepage so they can find the source.
How should I version it?
Start at 0.1.0 while it is still moving, and treat the first number as the promise you are making about compatibility. Anything that changes a command name or removes a skill is a breaking change to whoever is using it.
Do I need a licence field?
Only if you are sharing it. If you are, saying so explicitly saves everybody a conversation — an unlicensed repository is legally awkward to reuse even when it is obviously meant to be reused.
Can I build a plugin from things I already have?
That is usually how it starts. Commands and skills that already work move into the matching folders unchanged; the manifest is the only new file.
Related tools
Slash Command Builder — Build a custom slash command, with arguments and a tool allow-list.
Subagent Builder — Build a subagent definition file with its tools and model set.
Skill Builder — Write a SKILL.md with the frontmatter checked as you type.
Hooks Builder — Build settings.json hooks and catch the matchers that never fire.
MCP Server Config Builder — Generate an MCP server entry for stdio, HTTP or SSE — and the CLI one-liner.