Cursor plugins: what is inside one, explained

What happened

On Friday, 17 October, cursor/plugins showed up on GitHub's trending list. The repo describes itself in six words: "Cursor plugin specification and official plugins". It trended on the same day as Anthropic's directory of Claude Code plugins, and next to two big skill libraries that say they work in Cursor, Claude Code and Codex alike. So for a day, a good part of GitHub's front page was about the same thing: how you package what an AI coding agent knows and can do.

The repo itself is not new. It was created in January, and Cursor announced plugins in a post called Extend Cursor with plugins on 17 February. The launch partners named there were Amplitude, AWS, Figma, Linear and Stripe. What changed since then is mostly scale and process. On 19 October the repo had 12,998 stars and 1,277 forks, and its marketplace file listed 112 plugins. Commits still land daily: a Meta Ads plugin on 18 October, a formal-verification skill for the pstack plugin the next day.

No announcement explains why it trended that particular Friday. My guess is the Anthropic directory pulled people toward the whole idea, but that is a guess, and I have no number to back it.

What a Cursor plugin actually is

Cursor's plugin docs put it in one sentence: plugins "package rules, skills, agents, commands, MCP servers, and hooks into distributable bundles." In practice a plugin is a folder. At its root sits .cursor-plugin/plugin.json, the manifest. The schema in the repo, schemas/plugin.schema.json, has 21 fields, and only one of them is required: name. Everything else is optional, and most of the fields are globs that point at the parts:

• Rules: .mdc files in rules/. These are the standing instructions, like "this repo uses the app router" or "never add a dependency without asking".
• Skills: SKILL.md files with frontmatter in skills/. A skill is a procedure the agent loads when the task calls for it.
• Agents: definitions for subagents with their own job and prompt.
• Commands: the slash commands you type yourself.
• Hooks: a config file, or an inline object, for code that runs around the agent's actions.
• MCP servers: an mcp.json, which is how the agent reaches outside tools such as a browser, a database or a SaaS API.

The manifest also has a variables field, a JSON Schema for settings the user fills in, and minClientVersions, so a plugin can refuse an editor that is too old for it.

That is the whole format: a manifest that only needs a name, and folders. A multi-plugin repo, like Cursor's own, adds .cursor-plugin/marketplace.json at the root to list them.

What is in the official list

Of the 112 entries in Cursor's marketplace file, 95 live under third_party/: plugins for other companies' products. Gmail, Google Drive, Salesforce, HubSpot, Shopify, Zoom, GitHub and Playwright are all in there. The rest are Cursor's own developer tools, with names like thermos (branch review), create-plugin, ralph-loop, orchestrate and cursor-sdk.

For someone building web apps, playwright and github are the obvious ones. Most of the list, though, is about connecting the agent to business tools rather than teaching it to write better frontend code. That tells you who Cursor expects to use plugins: whole teams, not just one developer tuning an editor.

How you install one, and who checks it

Installing is a click. You open Customize in Cursor, find the plugin and, per the docs, "Select Install and choose a project or user scope." To test your own, you drop it in ~/.cursor/plugins/local and run Developer: Reload Window.

On review, the docs are firm: "Every plugin is manually reviewed before it's listed," and "All plugins must be open source, and we review each update before publishing." That last part matters, because a plugin can carry hooks and MCP servers, which means code that runs on your machine. Reviewing every update, not only the first version, is the right promise. What the docs do not say is what the review checks or how long it takes.

Teams get a further layer. The February post said private team marketplaces were coming; they are now in the docs. The Teams plan gets one team marketplace and Enterprise gets unlimited. An admin sets each plugin to Default Off, Default On or Required, and a Required plugin cannot be uninstalled by a team member. Auto Refresh re-indexes a team marketplace at most once every 10 minutes.

The open standard underneath

The docs describe two formats, and this is the part I would read twice.

Cursor Plugins are everything above: all six component types.

Agent Plugins is an open standard at agent-plugins.org, "an open, vendor-neutral standard for packaging reusable components into portable plugins." Its spec repo, agentplugins/agent-plugins-spec, was created in April and is at version 1.0.0. Its initial Technical Steering Committee has core maintainers from Amazon, Cursor, Microsoft, OpenAI and Vercel.

The portable core of Agent Plugins is small: skills and MCP servers. Rules, agents, commands and hooks are Cursor-only. Each client can add its own behaviour in a namespaced folder, so the core stays the same everywhere.

Cursor's repo also hedges in the other direction. Next to .cursor-plugin/ it carries a .claude-plugin/marketplace.json, which lists two of its plugins, origin-apps and pstack, for Claude Code. Anthropic's own directory, for comparison, lists 315 plugins.

Why this matters if you build web apps with AI

Every team using an AI agent ends up with the same pile: a page of conventions, a few prompts that work, a browser MCP server, maybe a review step. Today that pile is usually copied around by hand, or it lives in one person's settings. A plugin turns it into one versioned folder you install, and a Required team plugin puts it on every seat.

The split between the formats also tells you where to put effort. If your team is on more than one tool, write the knowledge as skills and the connections as MCP config, because those are the parts that move. Rules, commands and hooks are worth writing too, but expect to keep a copy per tool.

What is not known yet

• Which clients read Agent Plugins today. The standard's site talks about "compatible clients" but does not name them.
• Install counts. Cursor publishes none, for any plugin, so "popular" in this marketplace is a guess.
• What the manual review checks. The promise is written down; the criteria are not.
• Why it trended now. The repo is almost nine months old and there was no announcement that week.

My take

I am Amar, and this part is my opinion. I think the six-part Cursor format will matter less than the two-part open core. Skills and MCP servers are the bits that hold real knowledge: how this codebase is tested, how this API is called. Rules and commands are closer to preferences, and they are cheap to rewrite for each tool. If I were setting this up for a frontend team tomorrow, I would put the effort into skills and an MCP config, and keep each tool's rules file thin.

I also think the review promise is the feature, not a detail. A plugin that runs hooks is code from a stranger with access to your repo. "We review each update" is the line I would check first in any marketplace, and it is the one I would hold Cursor to.