先に結論
Cursor でいま起きた変化は、plugin が増えたことより 公式の配布面が見えるようになったこと です。
見る順番はシンプルです。
- root の
marketplace.jsonで何が並んでいるか見る - 各 plugin の
plugin.jsonで何が入るか見る - 自分のチームに関係ある plugin だけ深掘りする
これで、skills、rules、agents、MCP をどこまでまとめて配れるのかが一気に分かります。
配布単位の比較まで広げたいなら、GitHub Copilot Custom Agents vs Claude Code Skills vs Codex Plugins がつながります。Cursor 自体の導入判断を見直したいなら、Cursor vs GitHub Copilot vs Claude Code【2026年版】 を合わせて読むと早いです。
何が公開されたのか
今回公開された cursor/plugins は、Cursor の plugin specification と公式 plugin 群 をまとめた repository です。
README で最初に分かるのは、各 plugin が root 直下の独立ディレクトリとして並び、.cursor-plugin/plugin.json を持つことです。root には .cursor-plugin/marketplace.json もあります。
つまり今は、plugin を個別の紹介ページから探すより、公式 repository を見れば marketplace の骨組みまで追える 状態になりました。
README に載っている公式 plugin には、次のようなものがあります。
continual-learningcursor-team-kitcreate-plugincursor-sdkorchestratedocs-canvaspr-review-canvas
一覧を見るだけでも、Cursor が plugin を単なる接続機能ではなく、運用知識や自動化の配布単位 として扱い始めているのが分かります。
まず marketplace manifest を見ればよい
最初に見るべきなのは、個別 plugin の README ではありません。root の .cursor-plugin/marketplace.json です。
ここには plugin の name、source、description が並んでいます。要するに、公式 marketplace の目録です。
このファイルがあるおかげで、読者は次の判断をすぐ切れます。
- いま公式にどんな plugin があるか
- どの plugin が developer tools 寄りか
- まず何から読むべきか
情報収集の入口が 1 つにまとまったのは大きいです。社内で「Cursor plugins って結局どこを見るの？」と聞かれた時も、この manifest を起点に案内できます。
plugin manifest を見ると配布単位が分かる
次に見るべきなのが、各 plugin の .cursor-plugin/plugin.json です。
ここで分かるのは、plugin 名や説明だけではありません。その plugin が何を束ねて配るのか まで見えます。
たとえば cursor-sdk の manifest では skills へのパスがあり、SDK ベースの自動化を plugin として配る前提が見えます。cursor-team-kit では skills、agents、rules が manifest に載っています。
README の directory 構成には、さらに mcp.json、README.md、CHANGELOG.md も含まれています。
この構造から読み取れるのは明快です。
- skills だけを配る のではない
- rules だけを共有する のでもない
- MCP 接続だけを足す のでもない
- それらを plugin 単位でまとめる方向に進んでいる
この変化は、チーム導入ではかなり効きます。配布単位が見えないと、社内標準にしづらいからです。
create-plugin が入っている意味は大きい
今回の公開で見逃しにくいのが create-plugin です。
README では、これは marketplace-ready な Cursor plugin を作るための meta workflow と説明されています。scaffold、manifest generation、pre-submission quality check まで含みます。
ここが重要です。Cursor は公式 plugin を並べただけでなく、内製 plugin を作る入口まで用意した ことになります。
そのため、いま読むべき論点は「どの plugin が一番便利か」より先に、次の3つです。
- 自チームの rules や skills を plugin 化する必要があるか
- MCP 設定を plugin と一緒に配る方が運用しやすいか
- 内製 workflow を repo 単位ではなく plugin 単位へ上げるべきか
特に Cursor を複数 repo で使っているチームほど、この整理は効きます。
誰に影響が大きいか
Cursor をチーム導入している開発組織
影響は大きいです。これまでは rules、skills、MCP、agent 運用を別々に説明しがちでした。いまは plugin という 1 つの単位で整理しやすくなりました。
Claude Code や Codex と並べて見ている人
この公開で、Cursor 側の配布単位がかなり話しやすくなりました。比較そのものは別記事に譲れますが、少なくとも「Cursor はどこまでまとめて配れるのか」が曖昧なままではなくなっています。
GitHub Trending や X で cursor/plugins を見かけた人
まず確認すべきなのは、人気の勢いより manifest が何を定義しているか です。README と manifest だけでも、何が新しいのかは十分に追えます。
いま何をすべきか
いまやることは多くありません。
- root の
marketplace.jsonを一度読む - 自分に関係ある plugin を 1 本だけ選ぶ
plugin.jsonを見て、skills、rules、agents、MCP のどこまで含むか確認する- チームで共有したい運用知識があるなら
create-pluginを起点に内製方針を考える
Cursor plugins は、単に plugin が増えたという話ではありません。配布と標準化の単位が公式に見えるようになった のが本質です。比較を増やす前に、この一点だけ押さえれば判断はかなり楽になります。