Claude Code plugins — это расширения, каждое из которых представляет собой каталог, объединяющий навыки, подагентов, хуки и MCP-серверы в один устанавливаемый набор, и ставится он командой из каталога расширений либо из папки, которую вам передали. Удобство налицо: готовая настройка подключается одним действием и обновляется из каталога. Но каждый плагин выполняет код с вашими правами и присутствует в каждой сессии, а значит, к установке подходят как к подключению стороннего программного обеспечения: проверяют источник, область, разрешения и вес в контексте.
Что в плагине
Плагин объединяет в один набор навыки, подагентов, хуки и MCP-серверы; набор ставится из каталога и работает во всех сессиях, где он включён, выполняя действия с вашими правами.
По документации Claude Code, плагин — это каталог компонентов, обычно с файлом-описанием, в котором указано название, версия и другие сведения. Основные компоненты такие: навыки с инструкциями, подагенты для делегирования, хуки на события жизненного цикла, подключения к MCP-серверам и модуль хуков на JavaScript, который умеет рисовать панели и добавлять команды. Навык из плагина вызывается с префиксом имени плагина, например /my-plugin:review. Отдельные навыки, подагенты, хуки и серверы работают и сами по себе, а плагин нужен, когда их надо упаковать и передать целиком.
Про отдельные навыки рассказывает статья Skill Claude Code; здесь речь о наборе, который приходит со стороны. Общий взгляд на подключение инструментов к агенту дан в материале MCP подключения: как настроить и что открывать агенту, а запуск Claude Code командой разработки описан в статье Claude Code для команды.
- Навыки: инструкции, которые подгружаются по описанию или вызываются командой.
- Подагенты: отдельные исполнители с собственным контекстом для узких задач.
- Хуки: команды, срабатывающие на события, например после каждой правки файла.
- MCP-серверы: подключения к внешним системам, запущенные вместе с сессией.
- Модуль хуков: хуки в виде функций JavaScript, которые умеют рисовать панели и добавлять команды и тоже выполняют код.
Источник и доверие
Плагин исполняет код с вашими правами. Установка из каталога вендора и установка из папки коллеги несут разный уровень доверия, и разница должна быть записана в правилах команды.
Дополнительно проверьте, нужны ли плагину собственные учётные данные: набор, которому требуется ключ внешнего сервиса, расширяет круг мест, откуда возможна утечка. Для обычного пользователя это означает простую вещь: команда установки выглядит одинаково для безопасного и опасного набора, и различает их только ваша внимательность. Каталоги расширений делятся на три уровня: официальные каталоги вендора, каталоги сообщества, которые вендор называет своими именами, и сторонние. К сторонним относятся все остальные, включая каталоги коллег и вашей организации. Документация предупреждает, что на любом уровне, включая официальный каталог, поставленный плагин способен запускать код с правами вашей учётной записи. Поэтому сторонний набор читают так же, как читают скрипт, полученный по почте.
Перед установкой просмотрите состав: какие хуки срабатывают и на какие события, какие серверы запускаются, какие команды выполняются, куда уходят данные. Если состав изменился при обновлении, повторите просмотр. Для крупных организаций предусмотрены управляемые настройки: можно разрешить только утверждённые каталоги, заблокировать остальные и принудительно установить обязательные плагины.
Разрешения и область
При установке выбирают область: от неё зависит, у кого включён плагин. Ошибка с областью приводит либо к тому, что набор мешает везде, либо к тому, что коллеги остаются в неведении.
| Область | Кому доступен | Когда выбирать |
|---|---|---|
| Пользовательская | Вам во всех проектах на этом компьютере | Личные помощники и эксперименты |
| Проектная | Всем, кто работает в репозитории, через общие настройки | Процессы команды; каждый коллега всё равно ставит плагин у себя |
| Локальная | Вам в этом репозитории | Проверка плагина до решения о проектной установке |
Хорошая привычка — вести общий документ «что где установлено»: он спасает при смене сотрудника и при разборе странного поведения агента. Начинайте с локальной области: так плагин проверяется на одном репозитории без влияния на остальные. После проверки решите, нужен ли он команде, и перенесите его в проектные настройки. Сеансы в облаке игнорируют плагины из локальных настроек, и этот нюанс стоит записать в инструкцию для новичков.
Для проектной области учтите ещё одну деталь: общие настройки лежат в репозитории и попадают в историю изменений, поэтому изменение списка плагинов проходит ревью так же, как любое другое. Отдельный вопрос — разрешения на действия. Каждый хук и каждый сервер вправе делать то, что делали бы вы сами, поэтому права вашей учётной записи ограничивают заранее: рабочие ключи нужно убрать из окружения, доступного плагину, а доступ к производственным системам открывается через отдельные учётные записи с урезанными правами.
Тест и обновление
Для оценки удобно завести простую таблицу: что обещано в описании плагина, что обнаружено при просмотре, что подтвердилось на задачах. Плагин проверяют на копии проекта, держа рабочий репозиторий в стороне. Цель проверки — убедиться, что набор делает ровно то, что заявлено, и ничего сверх.
- Создайте тестовый репозиторий или временную ветку без доступа к рабочим ключам.
- Установите плагин в локальную область и просмотрите состав: хуки, серверы, навыки, подагенты.
- Выполните типовые задачи, ради которых плагин ставился, и зафиксируйте результат.
- Откройте журнал процессов и сетевую активность: убедитесь, что нет лишних запросов во внешние адреса.
- Оцените вес в контексте: плагин присутствует в каждой сессии, а имена и описания его компонентов занимают место и расходуют лимиты.
- Решите: принять в проектные настройки, оставить только у себя или удалить.
Фиксируйте и время загрузки: если после обновления сессии стали медленнее, а лимиты расходуются быстрее, виноват может быть новый компонент. Обновление проходит тот же путь в сокращённом виде. Прочитайте заметки об изменениях, а при смене состава повторите просмотр. Обновления из официального каталога удобно принимать сразу, а сторонние лучше обновлять вручную после прочтения. Неиспользуемые плагины отключайте: во вкладке установленных расширений есть группа давно неиспользуемых, а выключить плагин можно без удаления.
Какие плагины вы хотели бы подключить к рабочим проектам?
Аудит набора
Короткий разбор после аудита занимает немного времени и избавляет от путаницы: команда видит, что реально используется, а что осталось от старых экспериментов. Результаты аудита сохраняйте по датам, чтобы видеть динамику: рост числа плагинов без роста пользы говорит о захламлении. Набор плагинов растёт незаметно: кто-то поставил для эксперимента, кто-то обновил, кто-то забыл. Раз в квартал проводите аудит и фиксируйте результат одной таблицей.
- Название, каталог-источник, версия и область установки.
- Кто поставил, зачем и кто за него отвечает.
- Что входит: хуки, серверы, подагенты, навыки.
- Когда последний раз использовался и сколько стоит в контексте.
- Решение: оставить, обновить, заменить или удалить.
Для организации добавьте в аудит единые правила: список разрешённых каталогов, обязательные плагины, запрещённые источники, порядок обращения за новым плагином. Тогда сотрудник знает, куда идти, а безопасность знает, что искать. Если вам нужен такой регламент и настройка управляемых политик под вашу команду, это входит в работу по консалтингу по внедрению ИИ. Для первого аудита хватит одного репозитория, двух плагинов и таблицы; на остальные проекты переходите после разбора результата.