К этому моменту книга разобрала настройки по одной: AGENTS.md, rules, skills, subagents, hooks, MCP. Agent plugin - это способ упаковать их в один устанавливаемый пакет и раздать команде или сообществу. Соблазн очевиден: нашёл готовый плагин, который "настраивает Devin как надо", поставил одной командой - и получил чужой опыт даром. Ровно здесь и прячется вопрос, который легко проскочить: вы устанавливаете не список удобств, а цепочку доверия.
Наивное прочтение приравнивает плагин к расширению редактора: поставил, попробовал, не понравилось - удалил, риск нулевой. Из него растёт привычка ставить плагин ради одной приглянувшейся команды, не глядя, что ещё приезжает вместе с ней. Ломается эта привычка на том, что agent plugin по составу гораздо больше, чем набор команд, и часть его содержимого начинает действовать сразу и молча.
Что именно упаковывает плагин, стоит знать поимённо. Skills лежат в каталоге skills/ в стандартном формате и вызываются как слэш-команды вида /plugin:skill. Файл AGENTS.md работает как always-on правило в каждой сессии, а срабатывающие по условию правила - в папке rules/. Кастомные субагенты - это профили agents/<имя>.md, доступные как <plugin>:<имя>. Файл hooks.json регистрирует хуки жизненного цикла, которые запускаются в каждой сессии, где плагин установлен. И, наконец, плагин может нести MCP-серверы, стартующие вместе с сессией. Две последние строки - about executable code, а не about удобство.
Устанавливается плагин целиком и из разных источников: по короткому имени GitHub owner/repo, по git URL, из подпапки репозитория (git-subdir) или из локальной папки. Манифест требует по сути только уникальное имя, но поддерживает и объявление зависимостей - requiredPlugins, optionalPlugins и forbiddenPlugins, - то есть один плагин может тянуть за собой другие. Это удобно и одновременно расширяет ту самую цепочку: вы доверяете не только этому пакету, но и всему, что он объявляет своими зависимостями.
Функция находится в closed beta, и у неё есть тонкость с областью установки, важная для практики. Плагины ставятся на уровне пользователя и доступны во всех ваших проектах. В stable 3.7.16 установка через панель Customizations по умолчанию кладёт плагин в personal plugins - так он доступен и в Cloud, и на других ваших устройствах; отдельная опция Install locally ограничивает его текущей машиной. Разница не косметическая: personal-плагин расширяет свою поверхность доверия на облако и на все ваши сессии сразу, локальный - остаётся при одной машине.
С облаком связана ещё одна граница, которую документация проводит прямо. Кастомные субагенты плагина загружаются только в локальных агентах - CLI и Devin Desktop - и не поднимаются в облачных сессиях Devin. Command-хуки в облаке исполняются на машине сессии и работают лишь пока она поднята. Значит, один и тот же плагин даёт разный набор возможностей в зависимости от поверхности, и "плагин установлен" не равно "всё из плагина работает здесь".
Почему к этому стоит относиться как к вопросу доверия, а не удобства. Плагин - это одновременно звено supply chain (код из чужого репозитория), набор always-on инструкций (AGENTS.md и rules действуют без вашего повторного согласия) и исполняемые хуки (код, встающий на путь вызовов инструментов). Каждая из трёх частей по отдельности уже требует осторожности; вместе они означают, что установка плагина - это делегирование чужому автору права влиять на поведение агента и запускать код в ваших сессиях. Цена ошибки здесь - не "неудобная команда", а тихое изменение того, что агент делает по умолчанию.
Отсюда практика ревью до установки, а не после. Закрепляйте источник и версию, чтобы не поехать вслед за чужим обновлением незаметно. Читайте манифест и список зависимостей - что именно приедет и что потянется следом. Изучайте, что плагин кладёт в AGENTS.md и rules, потому что это начнёт действовать в каждой сессии. Смотрите на hooks.json как на исполняемый код и на MCP-серверы как на внешние endpoint с их правами и данными. Это тот же аудит, что для отдельной настройки, только умноженный на число компонентов пакета.
Проверять результат установки стоит не по факту "поставилось", а по факту "я вижу, что именно загрузилось". После установки откройте панель Customizations и убедитесь, какие rules, skills, субагенты, хуки и MCP-серверы принёс плагин и активны ли они на нужной поверхности. Сверьте закреплённую версию с источником. Если субагент из плагина "не появился" в облаке - это документированное поведение, а не поломка. Одна такая сверка отделяет реально работающий набор от списка обещаний в README плагина.
Типичные провалы предсказуемы и почти все - следствие пропущенного ревью. Плагин ставят ради одной команды, а вместе с ней получают always-on правило, тихо переписывающее стиль работы агента. Источник не закрепляют - и чужой релиз меняет поведение без спроса. Personal вместо Install locally выбирают не думая - и хуки с MCP расширяются на облако и все устройства. Ищут субагента плагина в облачной сессии, где он по определению не грузится. Признак всех случаев один: пакет установили раньше, чем прочитали, что в нём и куда он дотягивается. Сначала манифест, источник и состав - потом установка.