Cursor Plugins: чем отличаются Skills, Rules, Subagents, MCP и Hooks
Как разделить постоянные правила, повторяемые workflow, роли, интеграции и автоматические проверки.

Что именно появилось в Cursor 2.5

17 февраля 2026 года Cursor выпустил версию 2.5. В changelog Plugins описаны как одна установка, которая объединяет Skills, Subagents, MCP servers, Hooks и Rules. Плагины можно найти в Marketplace или установить из редактора командой /add-plugin.

Plugin здесь не шестой способ объяснить модели задачу. Это упаковка для нескольких компонентов агентной среды. Она нужна, чтобы набор правил, процедур, ролей и интеграций можно было версионировать и распространять вместе, а не собирать на каждой машине вручную.

В документации Cursor Plugins помимо состава из анонса 2.5 также указаны Commands и Variables. Cursor поддерживает два формата. Открытый Agent Plugins упаковывает переносимые Skills и MCP servers, а собственный формат Cursor Plugin добавляет Rules, Agents, Commands, Hooks и Variables.

Короткая карта ответственности

Путаница начинается, когда длинную инструкцию пытаются целиком положить в Rules или назвать Skill. Я пользуюсь более простым тестом: какую ответственность несёт этот фрагмент?

Rule      = что всегда соблюдать
Skill     = как выполнять повторяемую работу
Subagent  = кому делегировать отдельную ответственность
MCP       = к каким внешним системам обращаться
Hook      = что запускать в событии agent loop
Plugin    = как упаковать и распространить набор

Эта схема не описывает всю механику Cursor, но хорошо помогает проектировать конфигурацию. Если фразу нельзя уверенно положить в одну строку, скорее всего, в ней смешаны несколько слоёв.

Rules фиксируют постоянный контракт проекта

Rule — устойчивое ограничение, которое должно влиять на работу агента во многих задачах. В Symfony-проекте это может быть запрет бизнес-логики в controller, обязательный input DTO для API или правило не добавлять dependency без явного согласования.

Symfony project rules

- Controllers remain thin.
- API input uses DTOs and Symfony Validator.
- Business logic belongs to application services.
- Public API changes require explicit task scope.
- New dependencies require approval.

Фраза «добавить поле phone в User» не является Rule: это одноразовая задача. Неудачным будет и правило Always add an index, появившееся после единственного review. Индекс нужен конкретному query pattern, а не каждой колонке. Полезный контракт звучит точнее: при добавлении или изменении запроса оценить план выполнения и необходимость индекса.

Rules должны оставаться короткими и удобными для review. Файл на три тысячи строк постепенно накапливает исключения и противоречия; агент получает больше текста, но хуже понимает приоритеты.

Skills сохраняют повторяемый способ работы

Skill описывает процедуру для определённого класса задач. Он может включать инструкции, скрипты, references и assets, а агент загружает его, когда описание совпадает с текущей работой. Это удобное место для опыта, который команда раньше передавала через документацию и комментарии в code review.

Например, Skill add-symfony-api-endpoint может требовать сначала найти похожий endpoint, затем определить DTO и validation, добавить application service, обновить OpenAPI, написать functional tests и проверить diff. Rule при этом отвечает только за инвариант: controller остаётся тонким.

Rule
Controllers must not contain business logic.

Skill
How to add and verify a Symfony API endpoint.

Я не стал бы создавать один php-development Skill со Symfony, Laravel, Doctrine, Redis, security, CI и очередями внутри. Так получается энциклопедия, которую дорого загружать и трудно поддерживать. Лучше несколько процедур с ясным результатом: create-doctrine-migration, debug-messenger, review-api-contract.

Subagent получает роль и собственный контекст

Subagent — отдельный исполнитель, которому основной агент делегирует самостоятельную часть работы. Cursor описывает subagents как специализированных помощников для параллельной или изолированной работы; каждый запускается со своим контекстным окном.

После реализации endpoint для изменения email основной агент может отдельно вызвать Security Reviewer. Тот проверит authorization, подтверждение владения адресом, утечки чувствительных данных и regression risks. Test Reviewer независимо посмотрит happy path, duplicate email, invalid input и unauthorized.

Implementation Agent
        │
        ├── Security Reviewer
        └── Test Reviewer

Skill «как проводить security review» остаётся процедурой. Subagent «Security Reviewer» — роль с отдельной задачей и контекстом. Создавать агента ради поиска controller или открытия одного файла бессмысленно: стоимость передачи контекста выше пользы. Хорошая граница subagent обычно совпадает с инженерной ответственностью — research, security, database migration, testing или accessibility.

MCP подключает данные и действия вне репозитория

Rules, Skills и Subagents меняют поведение внутри процесса. MCP servers дают агенту инструменты и данные внешних систем: issue tracker, Sentry, внутреннюю документацию, CI или тестовую базу.

Без интеграции разработчик копирует stack trace и acceptance criteria в чат. С MCP агент может прочитать issue, запросить событие Sentry, сопоставить его с кодом и проверить состояние pipeline. Это уже не дополнительная инструкция, а новый канал доступа к рабочему контексту.

У такого удобства есть цена. Read Jira issue и close Jira issue — разные разрешения; чтение схемы test database и запись в production — тем более. Я подключаю MCP только после того, как ручной перенос контекста стал повторяющейся проблемой, и начинаю с read-only capabilities. Полный доступ «на будущее» раздувает поверхность риска без пользы для текущих задач.

Hooks механически встраиваются в agent loop

Hook срабатывает на конкретном событии: до shell-команды, после изменения файла, перед обращением к MCP, при запуске subagent или при остановке агента. По официальной документации hook может наблюдать, изменять или блокировать действие.

Различие с Rule принципиальное:

Rule
PHPStan must pass before completion.

Hook
on stop → run the verification script

Rule сообщает агенту обязательство. Hook обеспечивает вызов проверки в заданной точке и возвращает машинный результат. Так можно форматировать изменённый файл после edit, отклонять опасную SQL-запись до выполнения или проверять итоговый diff перед завершением.

Hooks тоже легко испортить. Если каждый edit запускает весь PHPUnit suite на десять минут, агентный цикл станет мучительно медленным. Автоматизация должна быть быстрой, детерминированной и соответствовать событию: formatter после файла, узкий test после локального изменения, полный набор проверок — перед завершением.

Где в этой схеме Commands

В анонсе Cursor 2.5 Commands не перечислялись, но современный Cursor Plugin умеет их упаковывать. Command — сохранённый prompt, который разработчик явно вызывает через /. Например, /prepare-release или /review-migration.

Command хорошо подходит для ручной точки входа. Skill агент выбирает по релевантности или получает явно, Hook запускается событием, а Command начинается с действия пользователя. Это ещё одна причина не называть все markdown-файлы «скиллами».

Минимальная среда для Symfony-проекта

Я бы не начинал с большого корпоративного plugin. Для обычного сервиса достаточно набора, который закрывает частую работу и обязательные проверки:

Symfony Agent Environment
├── Rules
│   ├── architecture
│   └── testing-and-dependencies
├── Skills
│   ├── add-api-endpoint
│   └── doctrine-migration
├── Subagent
│   └── symfony-reviewer
└── Hooks
    ├── formatter-after-edit
    └── phpunit-phpstan-before-stop

MCP здесь намеренно отсутствует. Он появится, когда агенту действительно понадобится регулярно читать задачи из Linear, ошибки из Sentry или внутренний каталог API. Интеграция ради полноты архитектурной схемы только усложняет разрешения и диагностику.

При таком окружении конкретный prompt становится коротким: «Добавь endpoint отмены заказа. Отменять можно только заказы в статусах NEW и PAID; повторная отмена запрещена; формат API-ошибок не менять». Архитектурный маршрут, процедура endpoint и обязательные проверки уже находятся рядом с задачей.

Что хранить в проекте, а что глобально

Репозиторий должен содержать знания, без которых невозможно безопасно изменить именно этот код: архитектурные границы, соглашения о migrations, команды тестов, локальные Skills и специализированных reviewers. Тогда они версионируются вместе с изменением framework, структуры каталогов и CI.

Глобально разумно оставить личные предпочтения и переносимые процедуры: общий debugging workflow, Git hygiene, универсальный security review или способ писать документацию. Есть и техническая причина предпочитать project-level конфигурацию: локальные пользовательские Skills не обязаны автоматически попадать в Cloud Agents и удалённые окружения.

PROJECT
architecture + tests + migrations + local review

GLOBAL
personal defaults + generic debugging + reusable practices

Как разобрать один длинный prompt

Возьмём привычную инструкцию: «Всегда используй DTO. Перед migration проверь schema. После изменения запусти PHPStan. Для security-кода попроси отдельного reviewer. Возьми acceptance criteria из Jira».

После классификации она превращается в пять независимых решений:

• Use DTO for API input — Rule;
• безопасное создание и проверка migration — Skill;
• запуск PHPStan в нужной точке — Hook;
• независимая проверка security — Subagent;
• чтение Jira — MCP с минимальными разрешениями.

После такого разложения проще увидеть лишнее. Если Jira открывают раз в квартал, MCP пока не нужен. Если PHPStan занимает двадцать минут, его нельзя бездумно запускать после каждого edit. Если DTO нужны лишь в одном bounded context, Rule должен иметь соответствующий scope.

Plugin упаковывает практику, а не заменяет её

Cursor Plugins полезны тем, что делают конфигурацию агента распространяемой. Команда может собрать базовый Symfony Plugin с архитектурными Rules, Skills для endpoint и migration, reviewer-агентом, hooks для проверок и интеграциями, которые действительно используются во всех сервисах.

Но плохие инструкции не становятся лучше после упаковки. Огромный Rule остаётся огромным, универсальный Skill продолжает грузить лишний контекст, «Super Developer Agent» не получает ясной ответственности, а MCP с широкими правами сохраняет риск.

Я бы начал с двух Rules, двух частых Skills, одного независимого reviewer и пары быстрых Hooks. Через несколько недель станет видно, где агент повторяет ручную процедуру, где ему не хватает внешних данных и какие ограничения действительно работают. Только после этого набор стоит превращать в plugin для команды.

Зрелость agent environment измеряется не количеством компонентов. Хорошая среда позволяет в prompt оставить бизнес-задачу, потому что повторяемый инженерный контекст уже разложен по правильным слоям.