A plugin packages what you already know how to configure separately: rules, skills, roles, commands, external servers and hooks - into one versioned bundle. The point is not a new capability but portability: what proved useful in one repository is installed into others whole and updated like a product. A manifest is required - at the root for an agent plugin, in a dedicated service directory for a Cursor plugin - components live in standard directories or are listed explicitly, and ready-made canvases can travel with them.
The naive alternative is copying good settings between projects by hand. That works while there are two projects. After that divergence begins: somewhere the rule was updated, somewhere it was forgotten, and finding out who has which version is impossible. Repairing such divergence costs more than it seems: you end up comparing files line by line and guessing which revision was the right one. A plugin turns copy-paste into a delivery with a version and an owner - and that, rather than the convenience of installation, is what makes it necessary.
It helps to see a minimal manifest once. Below are a name, a description, a version and an author. The name is required, the rest is hygiene: the description explains why the bundle exists, the version makes updates traceable, the author answers the question of whom to ask. Everything else consists of components that lie nearby and travel with the delivery.
The official catalog reviews every publication and every update by hand, requires open source and does not allow binaries. That noticeably lowers the risk but does not cancel the main point: a plugin remains third-party code. The documentation directly recommends reviewing the source, and that is not a formality - a bundle may contain hooks and external servers with powers of their own. The catalog's review answers the question of whether this is malware; the question of whether it fits your process is answered by you.
Teams have their own catalogs with distribution modes: off by default, on by default and required. The difference between them is the difference between an offer, a recommendation and a policy. A required bundle settles the question of uniformity but also demands a higher bar of quality: what cannot be switched off will get in the way everywhere it does not belong. In a large organization access is narrowed further by groups, and that is sensible - a platform team's release procedures are rarely needed by everyone.
Here is what that looks like in a team's life. Rules about the style of database queries, a release preparation skill, a read-only reviewer role and a handler forbidding edits to generated files live in one repository and stop everyone else from reusing them. They are put into a plugin, installed onto three neighbouring services and from then on changed in one place. The benefit is not in installation but in the next step: when the release procedure is edited, everyone receives the edit, and it is visible who has which version. That is exactly why a bundle must have an owner: without one there is nobody to publish the update and nobody to hold responsible.
There is an operational detail that costs the most to those who did not know it. Removing a plugin from a team catalog may also remove the external server linked to it - together with access for local users and cloud agents. So before such an operation dependencies are recorded and the confirmation is read in full. That is exactly the case where one click breaks work for several people at once, and breaks it in a way that is not immediately visible: locally things still work out of inertia while autonomous runs start failing.
Local plugin development is simple: a directory in the user folder and a window reload. For operation something else matters more - pinning the source and the version. Automatic updates are convenient and at the same time widen the supply chain: someone else's change arrives without your decision, and its hooks arrive with it. A reasonable compromise is a pinned version plus deliberate updating with an owner and a rollback plan.
Plugins have a limit of applicability. A single repository with settings that change every week is not worth packaging: the version will outrun the work, and updating will happen more often than using. There is also a clear sign that a required bundle has been overdone - local rules appear in projects that quietly cancel what came from above. That is not sabotage but a signal: the bundle describes a particular case rather than the general one, and it is time either to narrow it or to move it from policy to recommendation.
The typical failures are predictable. Installing a plugin as a harmless setting without reading what is inside. Making a bundle required before it has proved its quality. Removing a plugin from the catalog and stripping cloud agents of access along with it. And leaving automatic updates on where reproducibility is needed.
// .cursor-plugin/plugin.json - only the name is required
{
"name": "team-engineering",
"description": "Shared review and release workflows",
"version": "1.0.0",
"author": { "name": "Platform Engineering" }
}