You maintain a plugin that packages a code-review skill and an MCP server against the vendor-neutral Agent Plugins specification. Cursor users are asking for it, and you would also like the bundle to ship a shared rules file. How should you proceed?

The principle — Cursor recognises two plugin formats and works out which one it is looking at from the manifest. An Agent Plugin has a plugin.json at the bundle root and packages the portable pieces: skills and MCP servers. A Cursor Plugin has a .cursor-plugin/plugin.json manifest and may add rules, agents, commands, hooks and variables. Both install through the same flow, and a team marketplace can distribute either.

Why the key is correct — A plugin that follows the Agent Plugins specification loads in Cursor without changes, so the skill and the server you already ship need no work. Rules, though, are a Cursor Plugin component, so the moment you want them inside the bundle you are shipping a Cursor Plugin: move the manifest into .cursor-plugin/ and add a rules directory beside it. That is the trade being made, portability against Cursor-specific components.

Why the others are wrong — Nothing needs rewriting for Cursor to accept a conformant bundle, and assuming otherwise buys you a fork to maintain. The standard covers skills and MCP servers only, so a rules directory in a portable bundle is quietly ignored rather than loaded. And the local plugins folder is a development convenience that accepts either format, rather than the only way a portable plugin reaches the editor.

Remember this — Skills and MCP servers travel between tools; rules, agents, commands and hooks stay with Cursor.

Sources — Cursor's Plugins documentation.