Team marketplace · Cursor

Cursor: командный marketplace плагинов без репозитория — MCP, skills и сабагенты для команды

Единый каталог плагинов для Teams: кто что ставит по умолчанию и как это ускоряет вайбкодинг и контент-пайплайны

Коротко: в Cursor для организаций появился более прямой путь для командного каталога плагинов: администраторы могут вести team marketplace и настраивать first-party плагины без обязательного подключения репозитория на первом шаге. Параллельно зафиксированы три режима распространения (Default Off, Default On, Required) — это про политику установки, а не про «красивый каталог ради каталога». Ниже — что это значит для Cursor AI как IDE с искусственным интеллектом, для MCP-серверов, skills, сабагентов и для автоматизации разработки в целом.

Если вы следите за нейросетью для кода и ИИ для программирования, важно отделить три слоя: возможности редактора, «рантайм» агентов и корпоративное распространение настроек. Обновление team marketplace относится именно к третьему слою: к тому, как команда стандартизирует стек под вайбкодинг и смежные процессы (в т.ч. контент и продуктовые пайплайны, где те же принципы: единые правила, единые инструменты, контроль версий смысла, а не только кода).

admin@team-marketplace — zsh

$ cursor plugins policy push
# каталог → группы → MCP + skills пакетом

→ Default On: onboarding
→ Required: compliance-пакет
status: синхронизация Teams OK

Что изменилось в Cursor для команд: marketplace плагинов без привязки к репозиторию

Зачем команде единый каталог, если уже есть репо и расширения

Когда в компании есть Git, внутренние пакеты и привычный набор расширений, возникает резонный вопрос: зачем ещё один «магазин» внутри продукта? Ответ в практике команд Cursor Team и Enterprise простой: единый каталог снимает разрыв между «у нас где-то лежит репозиторий с правилами» и «у каждого разработчика реально одинаковый набор возможностей».

По заявлению Cursor в журнале изменений, администраторы могут создать team marketplace без предварительного подключения репозитория и дальше добавлять, удалять и настраивать поведение установки для first-party плагинов напрямую в настройках team marketplace (точка входа в дашборде — раздел плагинов и team marketplaces). Подробности формулировок см. в официальном changelog.

Маркер: простыми словами. Team marketplace — это внутренний каталог плагинов организации в Cursor: не публичный магазин для всех, а контур, которым управляет админ. First-party здесь — про свои плагины команды (внутренние стандарты), а не про сторонние публичные дополнения «с полки».

Отдельно стоит честно зафиксировать нюанс, который важен руководителю и техлиду: документация по плагинам по-прежнему подробно описывает импорт из GitHub, группы распространения и пары required/optional, а формулировки Default Off / Default On / Required и сценарий без репозитория на старте — в changelog. Для опубликованного материала это плюс: вы показываете, где искать первоисточник, и не смешиваете разные редакции справки. Актуальная структура раздела Plugins — в документации Cursor; русскоязычное зеркало — в русской версии docs (новые термины из changelog стоит сверять с EN, пока RU не обновят полностью).

Как это стыкуется с вайбкодингом и контент-пайплайнами

Вайбкодинг в широком смысле — это когда скорость итераций держится на «понятном намерении + хороших дефолтах + единых правилах», а не на бесконечном ручном копировании промптов. Для маркетинга и продукта это тот же класс задач: одинаковые skills (сценарии работы ИИ), одинаковые запреты и допуски в rules, одинаковые подключения к данным через MCP.

Маркер: простыми словами. Под политикой плагинов в этой статье имеется в виду не юридический документ, а набор админских решений: что видно в каталоге, что ставится само, что нельзя отключить, и как это различается для групп сотрудников.

Когда команда выросла из «нескольких энтузиастов с Cursor» в десятки мест, без каталога почти неизбежен дрейф: у одних подключён MCP к CRM, у других — нет; у одних свежий пакет правил, у третьих — устаревший форк. Team marketplace — попытка свести дрейф к управляемому процессу.

Состав плагина в терминах продукта: MCP, skills, сабагенты, rules, hooks

Team marketplace · состав плагина

Один плагин — пять слоёв стандарта

По формулировке Cursor плагин объединяет MCP, skills, сабагентов, rules и hooks: это не «одна кнопка», а пакет, который админ может выдавать команде единым контуром.

MCP — мост к данным и внешним системам
Skills / rules / hooks — как ведёт себя агент и на что реагирует
Сабагенты — узкие роли внутри многошаговых задач

Цикл подсветки ~24 с · не hero, только тело статьи

MCP-серверы в IDE: что даёт подключение к данным и внешним системам

MCP (Model Context Protocol) в контексте Cursor — это способ дать агенту контролируемый мост к инструментам и данным: от корпоративных систем до узкоспециализированных сервисов. В официальной формулировке changelog плагины объединяют MCP servers, skills, subagents, rules, hooks — то есть это не «одна кнопка», а пакет возможностей, который админ может продвигать как единый стандарт.

Маркер: простыми словами. MCP-сервер — это подключаемый модуль, через который ИИ в редакторе может выполнять согласованные действия во внешней среде (получать структурированные данные, вызывать API, работать с разрешёнными ресурсами) — не «магия чата», а интеграция по правилам.

Для автоматизации разработки MCP особенно ценен там, где важна повторяемость: одинаковые проверки, одинаковые источники правды, одинаковые шаги расследования инцидента. Соседний по времени релиз Security Review (бета для Teams/Enterprise) в changelog отдельно подчёркивает идею подключать MCP к существующим SAST/SCA/сканерам секретов — это не замена team marketplace, но показывает общий вектор: governance + интеграции, а не только «ещё одна модель».

Skills и правила агентов: зачем стандартизировать под команду

Skills — это оформленные компетенции агента: как именно он должен рассуждать, какие шаги предпочитать, какие артефакты производить. Rules задают рамки. Hooks позволяют встраивать реакции на события в workflow. Сабагенты (subagents) — про разделение ролей внутри многошаговых задач, что близко к запросам вроде «ии агенты для программирования»: не один «универсальный болт», а набор специализаций.

Маркер: простыми словами. Сабагент — это вспомогательный агент с узкой ролью, который подключается к основной задаче: например, отдельно «ревьюер», отдельно «тест-планировщик», отдельно «документатор» — чтобы не смешивать всё в одном промпте.

Стандартизация здесь выгодна не только разработке. Команды маркетинга и продукта, которые уже используют нейросеть для кода и Cursor AI как редактор кода cursor для скриптов, шаблонов и автоматизации контента, получают тот же эффект: одинаковые инструкции и одинаковые интеграции — меньше «телефонного игры» между подразделениями.

Режимы для админов: Default Off, Default On и Required — что выбрать в маркетинге и в разработке

В changelog закреплены три режима распространения

Off

Default Off — пользователь видит плагин в каталоге и подключает сам.

Default On — плагин ставится по умолчанию, но пользователь может отключить.

Req

Required — плагин всегда установлен, пользователь не может удалить.

Маркер: простыми словами. Default On/Off/Required — это про дефолтное поведение установки из недавнего changelog. В документации параллельно описаны required и optional при назначении плагина на distribution group (группу распространения). Это разные плоскости формулировки: одна — «как звучит политика в свежем анонсе», другая — «как устроены группы в админке по docs». При внедрении полезно сверять оба источника и фиксировать у себя внутреннюю глоссарную таблицу.

Как снизить риски и хаос при массовом включении ИИ

Default Off — естественный старт для пилотов: каталог как «витрина», без принудительной установки. Это снижает сопротивление и даёт измерить, кто реально пользуется, и какие плагины дают эффект.

Default On — шаг к выравниванию: новый человек в команде сразу получает рабочий минимум (например, корпоративный пакет skills + базовый MCP), но остаётся возможность отключить то, что мешает конкретной роли.

Required — зона жёсткого compliance: то, что нельзя «случайно снести», потому что от этого завязаны безопасность, единый контур аудита или критичные интеграции. Здесь важно не перепутать строгость с тяжестью: если всё сделать Required, вы получите сопротивление и обходы процесса.

Маркер: простыми словами. Distribution group — это сегмент сотрудников в админских настройках: например «все инженеры бэкенда» или «команда продукта X». На группу вешают плагины; в docs для такого назначения используют пары required/optional (после сохранения required для группы может означать автоматическую установку — логика описана в справке).

Дополнительно в документации фигурирует синхронизация групп через SCIM: это про то, чтобы группы не поддерживать вручную, если у вас уже есть корпоративный каталог пользователей.

Как подключить и распространять: практический контур без лишней теории

Практический контур для админа обычно выглядит так: завести team marketplace, определить категории плагинов (безопасность, продуктивность, доступ к данным), назначить их группам, выбрать режимы Default Off / On / Required там, где это доступно по интерфейсу и политике, и заложить цикл обновлений (что делать, когда пакет skills поменялся).

Важно: в docs по-прежнему подробно описан Import из GitHub URL как рабочий поток для team marketplaces и есть ориентиры по шагам и примерам шаблонов репозитория — это не отменяет сценарий «без репо сначала» из changelog, а дополняет его: у команды могут быть разные пути поставки (через импорт и через прямую настройку), и выбор зависит от зрелости внутренней инженерной платформы.

Отличие от сценария «всё только из Git» и типичные ошибки внедрения

Типичная ошибка — объявить «теперь у нас стандарт», но не определить владельца каталога: кто публикует версию плагина, кто подписывает изменения, кто отвечает за откат. Вторая ошибка — смешать публичный маркетплейс и внутренний: разные риски, разные SLA, разные ожидания пользователей. Третья — игнорировать документационный лаг: команда читает только RU-страницу и не видит свежих терминов — лечится внутренним регламентом «истина — changelog EN + наша таблица соответствий».

Для тарифных рамок полезно помнить различие уровней: в документации указано, что team marketplaces доступны на Teams (до одного team marketplace) и Enterprise (без лимита на количество), а добавлять team marketplaces на Enterprise могут только админы. Это влияет на дизайн процесса: в Teams вы строите один «золотой» каталог, в Enterprise — можете разделять контуры.

Связка с экосистемой: Cursor AI, нейросети для кода и автоматизация разработки

Где заканчивается тема marketplace и начинается отдельный разговор про SDK

За несколько дней до обновления marketplace Cursor выпускал Cursor 3.2 (в т.ч. async subagents и multi-root), затем Cursor SDK как программный API для облачных агентов, затем Security Review как контур проверок безопасности. Team marketplace логично читать как слой распространения и политики: «что именно люди получают в клиенте и в каком режиме», в то время как SDK — про программное управление агентами снаружи редактора.

На сайте Ковчега уже есть отдельный материал про угол Cursor SDK — этот лонгрид не дублирует его: здесь фокус на team marketplace, first-party плагинах и режимах установки. Если вам нужна именно интеграция CI/облака через API, ориентируйтесь на линию SDK; если нужна унификация клиентского стека для людей — на marketplace и группы.

Для запросов вроде «как пользоваться cursor ai» и «как подключить mcp к cursor» смысл простой: сначала выравниваете базовые настройки и доступы, затем подключаете MCP, затем упаковываете лучшие практики в skills/rules, и только потом масштабируете через сабагентов и автоматизации.

Системно разобрать цепочки автоматизации и вайбкодинга под контент и продукт можно в программе «Обучение по Make и вайбкодингу» на kv-ai.ru.

FAQ для руководителя и лида: подписка, команда, безопасность, стандарт инструментов

Что такое team marketplace в Cursor простыми словами?

Это внутренний каталог плагинов организации, которым управляет администратор, чтобы у команды был согласованный набор MCP, skills, сабагентов, правил и хуков.

Чем это отличается от публичного маркетплейса?

Публичный каталог ориентирован на широкую аудиторию и модерацию листинга; team marketplace — про корпоративные пакеты и политику установки для ваших сотрудников.

Обязательно ли подключать GitHub-репозиторий до создания marketplace?

По changelog от мая 2026 — нет: можно начать без репозитория и настраивать first-party плагины в настройках. Параллельно в docs остаётся сценарий импорта из GitHub — это альтернативный/дополняющий путь.

Что выбрать: Default Off, Default On или Required?

Off — для пилота и прозрачности; On — для выравнивания «из коробки» с возможностью отключить; Required — для жёстких требований, где удаление недопустимо.

Как это связано с MCP?

Плагин может включать MCP-серверы как часть пакета — то есть вы можете стандартизировать не только текстовые правила, но и доступы к данным.

Сколько team marketplace может быть на Teams?

По документации — до одного на Teams и без лимита на Enterprise; детали — в разделе Plugins.

Нужно ли маркетингу это знать?

Если маркетинг и продакт используют те же корпоративные стандарты вайбкодинга и автоматизации, им важно заранее договориться с IT/InfoSec о категориях плагинов и группах, чтобы не строить «теневые» процессы в обход политики.

Что проверяли по источникам

Changelog Cursor: обновление team marketplace, режимы Default Off/On/Required, состав плагина (MCP, skills, subagents, rules, hooks), сценарий без репозитория на первом шаге.
Документация Plugins (EN/RU): team marketplaces, distribution groups, required/optional, импорт из GitHub, лимиты Teams/Enterprise, SCIM.
Соседние релизы того же периода: Cursor 3.2, SDK, Security Review — для контекста слоёв продукта, без смешения в один «релиз всего».