Agent Plugins: Isolated packaging + lifecycle management for sub-agents, skills, hooks, rules (incl. AGENT.md) across Cursor IDE + CLI

Ideas Feature Requests
, , , ,
1

Feature request for product/service

Cursor CLI

Describe the request

Problem

As of Feb 2026, Cursor supports:

  • Sub-agents
  • Agent skills
  • Hooks
  • Rules (Cursor rules + AGENT.md)
    And Cursor can load agent resources from other ecosystems (e.g., Claude Code). For example, if I place skills/agents under ~/.claude/{skills,agents}, Cursor IDE can use them.

However, I’m increasingly frustrated with installing and managing sub-agents, skills, hooks, and rules consistently:

  • Global config directories (~/.claude, ~/.cursor, ~/.gemini, etc.) will become messy quickly as these ecosystems grow.
  • Existing solutions like Vercel’s skills package are helpful, but mainly target skills only and do not treat sub-agents + skills + hooks + rules as a cohesive, versioned, installable unit.
  • In practice, these resources are tightly connected: sub-agents should be able to depend on skills; hooks and rules should be shipped together with agent behaviors to ensure consistent guardrails.

What I’m requesting

Add a first-class “Agent Plugins” system in Cursor (IDE + CLI) that provides isolated packaging + lifecycle management for:

  • Sub-agents
  • Agent skills
  • Hooks
  • Rules
  • AGENT.md and related policy / metadata files

This should work similarly to “custom Claude Code plugins”, but extended to Cursor’s richer set of agent resources and ideally compatible with multi-ecosystem setups.

Why this matters (Underlying intent)

The real goal is:

  1. Seamless, flexible lifecycle management for agent configurations (install/update/rollback/disable).
  2. Isolation and cleanliness (avoid global config sprawl).
  3. Governance & security at scale: org-wide distribution of audited hooks/rules/policies as an installable unit, with controlled updates and traceable versions.

Proposed solution (high-level)

1) Plugin packaging format

Introduce a plugin bundle that can contain multiple resource types and declare dependencies.

Example structure:

  • cursor-plugin.yaml (or plugin.json) manifest:

    • name, version, publisher
    • compatible Cursor versions
    • resources included: skills, sub-agents, hooks, rules, AGENT.md
    • dependency graph (e.g., sub-agent depends on skill set)
    • optional permissions/scope (what the plugin can do)

  • skills/ (AgentSkills spec compatible where possible)

  • subagents/

  • hooks/

  • rules/

  • AGENT.md

  • README.md, CHANGELOG.md, signatures/checksums

2) Isolation model

Plugins install into an isolated directory, e.g.:

  • ~/.cursor/plugins/<publisher>/<name>/<version>/...
    or workspace-local:
  • <repo>/.cursor/plugins/...

No more copying scattered files into global config folders.

3) Lifecycle management

Add a consistent lifecycle UX for both IDE and CLI:

  • Install / update / pin version / rollback / disable
  • Workspace-level enable/disable overrides
  • Clear visibility: “which plugins are active and why”
  • Conflict resolution rules when two plugins provide the same skill/agent/rule/hook

Possible CLI:

  • cursor plugin install <source>
  • cursor plugin list
  • cursor plugin update <name>
  • cursor plugin disable <name>
  • cursor plugin rollback <name> --to <version>
  • cursor plugin verify <name> (signature/integrity)

Possible IDE:

  • Plugin manager UI (like extensions), showing:
    • Installed plugins + versions
    • Enabled per workspace
    • Diff/changelog on update
    • Policy/hook/rule visibility

4) Governance & enterprise use cases

This unlocks “policy distribution”:

  • AI governance/security team publishes a “guardrails plugin”:
    • Hooks for auditing and guardrails
    • Rules + AGENT.md baseline policies
    • Approved skills/sub-agents patterns
  • Engineers install once and automatically stay aligned with updates (with version pinning and controlled rollouts).
  • Ability to enforce org policies:
    • “Required plugins”
    • “Approved publishers”
    • “Disallowed hooks/permissions”
    • SBOM-like metadata, signatures

Requirements / acceptance criteria

  • Cohesive bundle: ship sub-agents + skills + hooks + rules + AGENT.md together.
  • Isolation: no need to sprinkle resources into global directories.
  • Dependency + linking: sub-agents can declare required skills from the same plugin or dependencies.
  • Multi-ecosystem friendly: Cursor can continue to interop with ecosystems like Claude Code, but with Cursor-managed installation and isolation.
  • Governance hooks: signatures, publisher trust, and auditability (at least basic).
  • Determinism: workspace can be made reproducible (e.g., lockfile / pinned versions).

Alternatives considered (and why they fall short)

  • Global config folders (~/.cursor, ~/.claude): will become unmanageable, hard to audit, hard to version/rollback.
  • Vercel skills package: focuses mainly on skills and not the full resource set (hooks/sub-agents/rules/AGENT.md) as a cohesive unit.
  • Ad-hoc git submodules / copy scripts: works for power users but doesn’t scale, and governance/audit is brittle.

Expected impact

  • Cleaner user experience for advanced agent workflows
  • Stronger security & governance story for enterprise adoption
  • Better interoperability across agent ecosystems
  • Lower maintenance burden and fewer “mystery behaviors” from scattered configs

Screenshot / Screen Recording

N/A (happy to attach if you want a mock plugin manifest + directory layout or CLI UX demo)

Operating System (if it applies)

  • MacOS (primary)
  • Linux (secondary)
  • Windows 10/11 (nice to have parity)

References

2 Likes
3

I posted the proposals to the communities of AGENT.md and agentskills.

4

I would love to see Cursor support the same/similar API as Claude Code plugins :heart:

5

@Colin I am so sorry for bothering you, but I want to discuss the feature request with Cursor team, because I think it might be a great enhancement for Cursor. Thanks.

6

i’ve got rules in .cursor/rules/, an AGENTS.md in the root, and i’ve been meaning to try hooks but i keep putting it off because adding another config location feels like it’ll get messy fast.

one thing from my testing that’s relevant here: i found that the same rule in AGENTS.md vs a .mdc file with alwaysApply: true gives identical model compliance. the only functional difference is .mdc files support glob scoping so you can target specific file types. so right now theres no behavioral reason to have both, its just organizational. a plugin system that lets you declare “this rule applies to *.tsx files” in one manifest instead of managing separate .mdc files would clean that up a lot.

being able to push a versioned rules pack to a team would solve a real problem too. right now sharing rules across a team is just “copy these files into your repo” which is pretty fragile.

7

i’ve got rules in .cursor/rules/, an AGENTS.md in the root, and i’ve been meaning to try hooks but i keep putting it off because adding another config location feels like it’ll get messy fast.

one thing from my testing thats relevant here: i found that the same rule in AGENTS.md vs a .mdc file with alwaysApply: true gives identical model compliance. the only functional difference is .mdc files support glob scoping so you can target specific file types. so right now theres no behavioral reason to have both, its just organizational. a plugin system that lets you declare “this rule applies to *.tsx files” in one manifest instead of managing separate .mdc files would clean that up a lot.

being able to push a versioned rules pack to a team would solve a real problem too. right now if you want to share rules across a team its just “copy these files into your repo” which is pretty fragile.

9