1. Установка — это выбор радиуса действия, а не кнопка
На словах установка plugin звучит почти невинно: нажали команду, получили инструмент, пошли дальше. Но в реальном workflow это не кнопка, а решение о радиусе действия. Вы отвечаете не только на «хочу ли я этот plugin», но и на «где он начнёт жить и кто его ощутит». Именно здесь многие спотыкаются: кажется, установка — личное дело, а через пять минут plugin уже влияет на весь репозиторий и удивляет коллег.
Полезно держать в голове простую формулу-камертон: permissions отвечают за то, что плагин может делать, а scope — за то, где и для кого он существует. Сегодня нас интересует именно scope. Речь про механику уже выбранного кандидата или эксперимента в песочнице, который вы держите в узком scope: само умение ставить plugin не оправдывает установку первого попавшегося package.
# Концептуально: точные команды и флаги могут отличаться в вашей версии Claude Code
/plugin install team-review-kit --scope user # установить плагин только для себя
/plugin list # посмотреть список установленных плагинов
/plugin details team-review-kit # увидеть состав, scope и основные сведения
Важная тонкость в том, что «установлен» и «уже участвует в текущей сессии» — не всегда одно и то же. Где-то plugin подхватится сразу, где-то понадобится обновить список plugins, перезапустить сессию или открыть проект заново. Пакет лежит в системе — и пакет подхватило окружение: разделяйте эти два шага, иначе рождается «я же поставил, почему ничего не изменилось?».
2. Scope: где плагин живёт и кого он касается
Когда вы впервые видите несколько scope подряд, всё это выглядит как слегка бюрократический набор слов. Но идея очень бытовая. Представьте отвёртку: её можно положить в свой личный ящик, оставить на одном рабочем столе, убрать в общий шкаф команды или получить централизованно от завхоза. С плагинами так же — один и тот же team-review-kit в разных scope означает разный круг влияния.
Вот удобная карта, к которой стоит возвращаться каждый раз перед установкой:
| Scope | На кого влияет | Когда уместен | Что важно помнить |
|---|---|---|---|
|
Только на вас, во всех ваших проектах | Если workflow нужен вам регулярно в разных репозиториях | Удобно, но плагин будет всплывать везде, где вы работаете |
|
Только на вас и только в одном конкретном repo | Для эксперимента или временной настройки под один проект | Хорошо для проб, но не создаёт общий стандарт команды |
|
На конкретный repo и тех, кто работает по его общему workflow | Если plugin — часть общего workflow команды | Project-level scope привязывает плагин к repo, а точная модель хранения и раскатки зависит от реализации |
|
На организацию или её часть | В компаниях с централизованной политикой | Обычно вы не выбираете его сами, а получаете готовое решение |
Имена scope между версиями могут отличаться — user где-то называется personal — но логика та же.
flowchart TD
A[Нужно установить плагин] --> B{Кому он нужен?}
B --> C[Только мне
во всех проектах
user]
B --> D[Только мне
в одном repo
local]
B --> E[Всей команде
в этом repo
project]
B --> F[Организации централизованно
managed]
Самая частая путаница — между user и local: новичку они кажутся почти одинаковыми, «в обоих случаях это же только я». Но разница существенная. user — как положить инструмент в свой рюкзак: носите его по всем проектам. local — как оставить инструмент на одном верстаке: в соседнем репозитории его уже нет. Тестируете review-plugin только для Commerce OS — local разумнее user.
3. Project scope — это уже не личная настройка
С project scope начинается взрослая жизнь. До этого вы в основном возились со своим окружением — «я себе поставил удобную штуку». Но как только plugin привязывается к repo, это уже решение о проектном workflow, кусок общей инфраструктуры, даже если внутри пока два безобидных skill-компонента.
Представьте, что команда Commerce OS решила пользоваться единым review workflow. Выбирая project scope, вы говорите: plugin относится к этому repo, а не ко всем моим проектам. Где именно живёт привязка — в конфиге проекта или как состояние у менеджера plugins — зависит от реализации, поэтому перед раскаткой проверьте справку и договоритесь, как команда будет его распространять и отключать.
Даже простая фиксация решения делает жизнь спокойнее:
## Plugin baseline
Плагин: team-review-kit
Scope: project
Зачем: единый review workflow для Commerce OS
Кого касается: тех, кто работает по общему plugin baseline этого repo
Как отключить: временно disable; полностью убрать project-level привязку тем способом, который поддерживает текущая установка
Заметьте, это не сложная документация и не «процесс ради процесса», а способ не забыть, зачем у проекта вообще появился plugin уровня project. Иначе через месяц случается классика: половина команды считает его обязательным стандартом, вторая — чьим-то экспериментом, а автор уже сам не помнит, с чего всё началось.
Практическое правило здесь простое: если plugin сырой, живёт один день и нужен только вам — не торопитесь с project. Сначала докажите, что он нужен команде, а не только автору вчерашнего энтузиазма.
4. Namespace: зачем плагину «фамилия»
С namespace история очень похожа на обычную человеческую жизнь. Пока в группе один Дима, можно просто «Дима». Появляется второй — и внезапно выясняется, что фамилии не бюрократия, а способ не путать людей. С именами плагинов ровно та же история: один review-плагин — имя review удобно, появляется второй с похожим смыслом — начинается лёгкий организационный хоррор.
Представим два набора: один за review кода, второй — за review документации. Без namespace это может выглядеть так:
Без namespace:
- review
- review
С виду всё красиво. На практике не понять, какой именно review вызвался, откуда он пришёл и почему вместо проверки PR вы внезапно получили советы по README. С namespace картина становится человеческой:
С namespace:
- review-kit:pr-review
- docs-kit:review
Точный формат имени зависит от реализации, но идея одна: namespace добавляет skill или команде «фамилию». Это особенно важно именно на этапе установки. Почему? Потому что конфликт имён становится заметен не тогда, когда вы пишете plugin, а тогда, когда в одном окружении начинают жить несколько plugin сразу.
Новичку namespace кажется избыточным: «У нас же пока один plugin». Это логика примерно уровня «я пока один Дима, фамилия мне не нужна». Но такие вещи ставятся не на один день. Среда растёт, команды наслаиваются, коллеги приносят свои инструменты и артефакты. Если заложить namespace с самого начала, потом не придётся устраивать болезненную миграцию имён, объяснять всем, почему старые команды внезапно перестали работать, и ловить конфликты в духе «а у меня review делает не то».
Хороший namespace не обязан звучать как название стартапа. Его задача куда прозаичнее: быть понятным и стабильным. team-review-kit, commerce-tools, docs-kit работают лучше, чем абстрактное super-ai-pro. С именами плагинов вообще полезно чуть меньше поэзии и чуть больше инженерного смысла.
5. Жизненный цикл: install → use → update → uninstall
Когда люди говорят о plugins, они часто думают только про установку — а с неё всё лишь начинается. Без жизненного цикла в голове быстро копится кладбище полумёртвых расширений: что-то ставили, что-то выключали, что-то обновляли, а что активно сейчас — уже никто не понимает.
Самая полезная ментальная модель здесь такая: install → activate → use → update → disable → uninstall. Даже если интерфейс объединяет какие-то шаги, разделять их мысленно всё равно удобно.
| Шаг | Что это значит на практике |
|---|---|
|
package появился в вашем окружении |
|
plugin реально подхватился текущим проектом или сессией |
|
вы убедились, что он работает там, где ожидали |
|
вы переходите на новую версию и заново проверяете изменения |
|
временно выключаете plugin без полного удаления |
|
убираете plugin полностью |
Концептуально это может выглядеть так:
# Концептуально: названия команд и флагов зависят от версии Claude Code
/plugin update team-review-kit # обновить плагин
/plugin disable team-review-kit # временно выключить
/plugin enable team-review-kit # снова включить
/plugin uninstall team-review-kit # удалить полностью
Отдельно стоит проговорить разницу между disable и uninstall, потому что её путают постоянно. disable нужен, когда вы отлаживаете конфликт, сравниваете поведение «с plugin и без него» или временно выключаете эксперимент. Это как вынуть батарейки из пульта, но не выбрасывать сам пульт. uninstall — уже полноценное «нам это больше не нужно». Если эксперимент закончился и вы не собираетесь к нему возвращаться, лучше удалить plugin полностью. Иначе через месяц накопится зоопарк выключенных расширений, которые занимают место и в системе, и в голове.
Самый недооценённый шаг здесь — update. Люди часто относятся к обновлению как к технической рутине: «ну вышла новая версия, поставим». Но обновление plugin — это почти новый install. У новой версии может измениться состав, поведение, характер подсказок, даже косвенная нагрузка на контекст. Поэтому обновлять plugin «автоматом, потому что цифра версии стала больше» — плохая привычка. Намного здоровее относиться к update как к новой версии договора: вы ещё раз проверяете, что именно приняли в свой workflow.
6. Practical walkthrough: ставим реальный плагин из claude-plugins-official
До этого момента мы рассуждали про install, scope, namespace и lifecycle на синтетическом team-review-kit. Это удобно для объяснения, но в какой-то момент полезно увидеть, как тот же самый цикл выглядит на реальном плагине из реального marketplace. Так понятие из лекции превращается в навык, который можно повторить руками.
Marketplace, с которого имеет смысл начать, — это claude-plugins-official. Это поддерживаемый Anthropic каталог плагинов, доступный в Claude Code по умолчанию. Если вы ничего специально не настраивали, он уже подключён, и вам не нужно отдельно добавлять источник. Это важная деталь: для большинства пользователей путь от «хочу попробовать» до «уже установлено» короче, чем кажется.
Самое первое полезное действие — посмотреть, какие marketplace у вас уже активны и какие плагины в них доступны. Концептуально это выглядит так:
# Концептуально: точные имена команд и формат вывода зависят от версии Claude Code
/plugin marketplace list # какие marketplace подключены
/plugin marketplace add anthropics/claude-plugins-official # если по какой-то причине официальный не активен
В большинстве случаев первый из этих шагов вам уже покажет официальный marketplace в списке. Второй понадобится только в нестандартном setup — например, если вы работаете в окружении с собственным набором источников.
Дальше — установка конкретного плагина. Возьмём для примера code-review: это очень узнаваемая категория, и у плагина простой capability surface, который легко проверить:
# Концептуально: имена и флаги могут отличаться в вашей версии Claude Code
/plugin install code-review --scope user # ставим только для себя, без влияния на проект
/plugin list # видим, что плагин появился
/plugin details code-review # смотрим, что внутри
Команда details здесь особенно ценная. До запуска плагина в работу полезно увидеть, что именно он принёс с собой: какие у него slash-команды, какие специализированные агенты, какие hooks, какие требования к окружению. Это и есть тот самый capability surface, о котором мы говорили в прошлой лекции. Никакой магии: пакет, его состав, его права.
После установки можно проверить плагин на реальной задаче. У code-review сценарий простой: переключаетесь на ветку с готовым PR и запускаете команду плагина:
# На ветке с готовым PR, концептуально
/code-review # вывод в терминал
/code-review --comment # тот же результат, но опубликован как комментарий в PR
Здесь хорошо виден важный практический нюанс. Первая команда — это чтение и анализ, ничего не пишется наружу. Вторая команда — уже внешнее действие, и она требует осознанного решения. Это очень полезный паттерн в принципе: даже если плагин умеет что-то опубликовать, у вас почти всегда есть «спокойный» режим, в котором результат остаётся локальным. Начинать имеет смысл именно с него.
Теперь самое важное для дисциплины: уметь так же спокойно откатывать. Не «оставили навсегда, потому что вроде работает», а пройти всю цепочку lifecycle до конца:
# Концептуально, последовательность отката
/plugin disable code-review # временно выключили, не удаляя
/plugin enable code-review # вернули обратно (если ещё нужен)
/plugin uninstall code-review # убрали из системы полностью
Эти три шага — не просто «команды на всякий случай». Это и есть тот самый полный цикл install → activate → use → disable → uninstall, который мы только что обсудили на абстрактном уровне. Когда вы хотя бы один раз честно прошли его на реальном плагине, дальше любой следующий установленный пакет становится не «загадочным новым жителем системы», а просто очередным элементом со знакомой цепочкой состояний.
Полезная привычка: после такого практического прогона зафиксировать у себя короткую заметку. Не процесс ради процесса, а маленькую страховку от забывчивости.
## Plugin trial log
Плагин: code-review (claude-plugins-official)
Зачем пробовал: посмотреть, как закрывает self-review перед PR
Scope: user (только мой workflow, без влияния на проект)
Результат: помог поймать пропущенную проверку null; шум на простых diff
Решение: оставляю в user scope, переводить в project пока не буду
Как откатить: /plugin disable, далее /plugin uninstall
Заметка нужна не потому, что вы любите бюрократию. Она нужна потому, что через две недели вы не вспомните, почему этот плагин у вас вообще установлен, в каком scope, и что вы тогда о нём решили. Маленький log избавляет от такой амнезии лучше любого комментария в чате.
И последнее замечание про version-resilience, которое стоит держать в голове специально для этой лекции. Команды установки, имена флагов, формат вывода details и list, даже способ подключения marketplace по умолчанию — всё это может слегка меняться от версии к версии. Не запоминайте конкретную форму команды как заклинание. Запомните логику: подключили marketplace, посмотрели каталог, выбрали плагин по категории и capability surface, установили в самый узкий scope, использовали в безопасном режиме, при необходимости временно выключили или совсем удалили. Эта логика стабильна. Точная форма каждой команды — нет.
7. Невидимая цена: context overhead и лишние плагины
Самое коварное в плагинах то, что их вред редко выглядит драматично. Компьютер не обязательно падает, экран не обязан мигать красным. Гораздо чаще они просто понемногу засоряют среду. Один лишний plugin — мелочь. Но когда их становится пять, появляются странные подсказки, конфликтующие названия, чуть более шумный контекст и ощущение, что среда стала тяжелее и менее предсказуемой.
Полезно помнить: установленный plugin — это не просто файл где-то на диске. Его описание, названия компонентов, а иногда и инструкции с метаданными становятся частью рабочей среды Claude Code. У Claude нет отдельной пыльной полки под названием «это когда-нибудь пригодится». Если plugin активен, он увеличивает сложность общей картины. Поэтому установка плагина всегда имеет цену, даже когда он «ничего такого не делает».
Хорошая аналогия — рюкзак. Один дополнительный предмет почти не чувствуется. Но если каждый раз бросать туда «вдруг пригодится» и никогда не разбирать содержимое, рюкзак становится тяжелее, а искать нужную вещь — дольше. С plugin происходит то же самое: неиспользуемые расширения редко ломают всё сразу, но постепенно ухудшают обзорность системы.
Отсюда рождается простая гигиена. Если plugin больше не помогает — убирайте. Если эксперимент закончился — не оставляйте его просто выключенным навсегда «на память». Если у вас установлено сразу несколько похожих инструментов одной категории, задайте себе прямой вопрос: они действительно дополняют друг друга или вы просто коллекционируете инструменты из инженерской жадности? Это, кстати, очень программистская слабость: иногда мы любим настраивать свой набор инструментов больше, чем делать саму работу. И плагины этим прекрасно пользуются.
8. Сквозной пример: team-review-kit в Commerce OS
Теперь соберём всё в одну реальную картину. У вас есть Workflow Kit команды, в котором уже живут два полезных навыка: issue-analysis и pr-review. Вы упаковали их в plugin team-review-kit. Дальше перед вами не абстрактная, а очень живая задача: как именно подключить этот plugin к Commerce OS, чтобы он помогал, а не создавал лишнюю путаницу.
Разные сценарии требуют разного scope:
| Ситуация | Разумный scope | Почему |
|---|---|---|
| Вы один тестируете plugin в своём рабочем окружении | |
Не засоряете другие проекты и не трогаете команду |
| Вам нужен этот plugin почти во всех ваших репозиториях | |
Личный стабильный набор инструментов везде под рукой |
| Команда Commerce OS договорилась о едином review workflow | |
Плагин привязан к этому repo; как он раскатывается на всю команду, зависит от модели хранения |
| Компания централизованно раскатывает approved tooling | |
Решение живёт на уровне организации, не у отдельного разработчика |
Представим типичную историю. Сначала team-review-kit идёт в local scope Commerce OS: пару дней проверяете, помогает ли pr-review перед PR. Потом подключается второй разработчик, workflow повторяется — вот теперь решение переводите в project scope, фиксируете в plugin baseline и отдельно проверяете, как текущая версия Claude Code хранит такой уровень установки и делится им.
В этот момент на install-команду вы уже смотрите не как на «волшебную строчку из документации», а как на инженерное решение с тремя вопросами внутри. Где будет жить plugin? Кто его почувствует? Как я его выключу или удалю, если эксперимент не удастся? Если вы умеете честно отвечать на них ещё до запуска команды — значит, вы перестали «просто ставить плагины» и начали работать с ними как с нормальными артефактами команды.
ПЕРЕЙДИТЕ В ПОЛНУЮ ВЕРСИЮ