Plugin manifest
The metadata file that identifies a plugin package and, depending on the host, the components it bundles.
- Published
- Sep 27, 2026
- Checked
- Sep 27, 2026
How far we checked this page
Signed by Ravalika Korthiwada, Sep 27, 2026. Passing one check says nothing about the next.
- FormatNot checkedThe file format was not checked for this page.
- InstallsNot checkedInstallation was not checked for this page.
- LoadsNot checkedLive loading was not checked for this page.
- HelpsNot checkedA with/without task comparison was not run.
A plugin manifest is the file a host reads to identify a plugin package: its name, version, and, depending on the host, the skills, MCP connections, agents, rules or hooks it bundles. The filename and exact fields are host-specific. Claude Code looks for .claude-plugin/plugin.json; Cursor documents both a portable root plugin.json and a Cursor-specific .cursor-plugin/plugin.json; OpenAI documents a portable root plugin.json under the Agent Plugins 1.0.0 schema, with .codex-plugin/plugin.json kept as a compatibility fallback that its current plugin-creator scaffold still generates.
For example, a Claude Code plugin bundling our explain-error skill could use .claude-plugin/plugin.json declaring the plugin’s name (version is optional), with the skill itself moved to skills/explain-error/SKILL.md inside the package (though Claude Code can also load a plugin from its standard directory layout with no manifest file at all). Installed, it answers to a namespaced command like /plugin-name:explain-error rather than a bare /explain-error. We haven’t built or installed a plugin like this ourselves; this is what Claude Code’s plugin docs describe.
A manifest from one host doesn’t carry over unchanged to another: the portable Agent Plugins standard’s ${PLUGIN_ROOT} variable doesn’t expand in Cursor, which documents its own ${CURSOR_PLUGIN_ROOT} alternative instead, and each host’s field names differ.
Related: Plugin marketplace, Agent skill vs plugin.