Follow up Cursor upstream updates: Plugins/Marketplace packaging surface (Cursor 2.5)

[dyoshikawa]

Summary

Cursor 2.5 introduced Plugins and an official Marketplace — a packaging/distribution surface that bundles rules, skills, agents, commands, MCP, and hooks into a single installable unit. rulesync emits each of these features only as loose files under .cursor/, with no concept of a Cursor plugin bundle.

Note: This is a distribution/packaging wrapper rather than a new per-feature config key. Every individual Cursor feature adapter is itself up to date with upstream. If plugin packaging is considered out of rulesync's scope, this can be closed as wontfix — filing it so the maintainer can make that call.

Recent Releases

• Cursor 2.5 — Plugins + Marketplace, released 2026-02-17: https://cursor.com/changelog/2-5
• Plugins documentation: https://cursor.com/docs/plugins
• Plugins repo: https://github.com/cursor/plugins

Gaps

• Plugins packaging — unsupported. A Cursor plugin is a repo-root directory with a manifest at .cursor-plugin/plugin.json (name kebab-case, displayName, description, version, author, keywords, license), optionally listed in a root .cursor-plugin/marketplace.json. A single plugin bundles any combination of rules (rules/*.mdc), skills (skills/<name>/SKILL.md), agents, commands, MCP (mcp.json), and hooks — the same feature surfaces rulesync already generates, assembled as one marketplace-installable unit. rulesync side: emits loose files under .cursor/ only; no plugin.json/marketplace.json manifest and no .cursor-plugin/ bundle layout.

Proposed Follow-up

• Evaluate adding a Cursor plugin packaging mode that emits a .cursor-plugin/plugin.json manifest (and optionally marketplace.json) and lays out generated rules/skills/agents/commands/mcp/hooks in the plugin directory layout, so rulesync-managed config can be published as an installable Cursor plugin.
• Alternatively, document the plugin surface as an explicitly out-of-scope distribution wrapper if packaging is not pursued.

References

• https://cursor.com/changelog/2-5 — Cursor 2.5 Plugins + Marketplace announcement (2026-02-17).
• https://cursor.com/docs/plugins — plugin manifest fields and bundled feature layout.
• https://github.com/cursor/plugins — official plugins/marketplace repo.

[dyoshikawa]

Triage note (leaving open for a maintainer scope decision):

Confirmed: Cursor 2.5 (2026-02-17) added Plugins + a Marketplace that bundle rules/skills/subagents/MCP/hooks into a single installable unit via a .cursor-plugin/plugin.json manifest (optionally marketplace.json). All of rulesync's individual Cursor feature adapters are already current; what's missing is a packaging/bundle concept.

This is a scope decision only a maintainer can make:

1. wontfix / document as out-of-scope — Plugins is a distribution wrapper, not a per-feature config gap. Every Cursor adapter is already up to date. The issue body itself invites this.
2. implement — add a Cursor plugin packaging output mode that emits .cursor-plugin/plugin.json and re-lays the generated rules/skills/agents/commands/mcp/hooks into the plugin layout. This is a new cross-cutting output mode (not a single adapter) and diverges from rulesync's current "generate loose config files" model.

No single defensible fix exists without that call, so leaving open.

[dyoshikawa]

Closing as out-of-scope (wontfix), per maintainer decision.

Cursor 2.5's Plugins/Marketplace is a packaging/distribution wrapper that bundles rules/skills/subagents/MCP/hooks into a single installable unit (.cursor-plugin/plugin.json, optionally marketplace.json) — it is not a per-feature configuration gap. Every individual Cursor feature adapter in rulesync is already current, so there is no missing config surface to generate. Implementing a Cursor-specific plugin packaging output mode would be a new cross-cutting "re-lay generated files into a plugin layout" concept that diverges from rulesync's "generate loose config files" model, which we've decided not to pursue.

If a plugin-packaging output mode is wanted later, it can be filed as a dedicated feature request describing the desired bundle layout.