Plugin ecosystem: категории и выбор

1. Топ недели ничего не знает про вашу задачу

Как только workflow дозрел до пакета, который можно установить, очень хочется учиться по принципу «что сейчас в топе». Желание понятное: список имён даёт иллюзию, что кто-то уже подумал за вас, но чужой рейтинг почти никогда не совпадает с вашей задачей. Для обучения это вдвойне ловушка: вы запоминаете бренды, а не боль, которую каждый plugin снимает.

Представьте обычный строительный магазин. Если вы зашли туда без вопроса «мне нужна дрель, отвёртка или уровень?», полка «самые популярные инструменты месяца» уведёт куда угодно, только не к нужной покупке. С plugin так же. Важно не громкое имя, а класс задачи: документация, diff, браузерные проверки, GitHub, инфраструктура, командный workflow.

Есть и ещё одна причина думать категориями: имена и «топы недели» меняются быстрее, чем живёт хорошая лекция, а категории задач — медленно. Разбираться в проекте, смотреть diff, вести PR — никуда не денется. Категория делает голову менее зависимой от чужой маркетинговой витрины.

2. Категория, plugin, capability surface — три разных слова

Начинающие часто смешивают три разные вещи — категорию, сам plugin и его реальные возможности, — и разговор становится странным. «Нам нужен plugin» — хотя нужна категория «ревью кода». «Этот plugin безопасный» — хотя проверена красивая страница в marketplace, а не его capability surface. Разведите уровни, и путаница исчезнет.

team-review-kit

Вот наглядный пример из нашего Workflow Kit. Допустим, у нас уже есть skill для self-review:

---
name: pr-review
description: Проверить diff перед PR
when_to_use: Когда изменение уже готово к self-review
---

Из этого skill не следует, что нам нужен любой plugin из мира ревью — и тем более первый красивый пакет с надписью «AI review suite». Сначала я называю категорию: «ревью кода». Потом решаю, брать ли чужой plugin или упаковать собственный pr-review. И только потом смотрю на capability surface: он читает diff — или заодно тянет hooks, сеть, shell-скрипты и пол-интернета впридачу.

Это разделение особенно выручает, когда вы обсуждаете решение с командой. «Давайте поставим популярный plugin» — фраза ни о чём. «Нам нужен plugin категории ревью кода, с минимальными правами, без браузерной автоматизации, чтобы сократить self-review перед PR» — уже нормальное инженерное требование.

3. Самый ценный plugin часто не пишет ни строчки кода

Не все plugins существуют ради написания кода. Большая и очень полезная их часть работает раньше — на входе в проект, поиске контекста, понимании, где живёт нужная логика. Для новичка это особенно ценно: пока вы ещё не уверены в кодовой базе, plugin-навигатор нередко полезнее того, что обещает «сгенерировать всё за вас».

Начинающему разработчику часто кажется, что самый «крутой» plugin — тот, который сразу меняет код. А выигрыш обычно раньше: если в Commerce OS вы каждый раз заново вспоминаете, где команды запуска и как зовётся модуль, то plugin для памяти проекта окупится быстрее ещё одного модного рефакторщика.

Отдельно стоит упомянуть мета-категорию — плагины для развития самих артефактов Workflow Kit. На первый взгляд звучит слишком абстрактно, но сценарий вполне живой. Как только команда начинает поддерживать переиспользуемые артефакты, пошли вопросы: одинаково ли оформлены шаблоны, не устарели ли примеры, не расползаются ли README, совпадают ли описания со структурой пакета. Такой plugin не пишет бизнес-код, зато не даёт Workflow Kit превратиться в коллекцию «исторически сложившихся прекрасных решений».

4. «AI помогает программировать» — это пять разных инструментов

Вот здесь начинается та часть экосистемы, которую обычно и представляют при слове «plugin». Но даже внутри неё полезно видеть не один общий мешок, а несколько классов задач: одни смотрят diff и ищут риск, другие проверяют интерфейс в браузере, третьи подсвечивают опасные места в безопасности, четвёртые подсказывают безопасные упрощения. Снаружи всё это «AI помогает программировать», а по сути — разные инструменты.

Важный нюанс здесь такой: категория полезна, только когда совпадает с текущей задачей. Если вы сейчас чините чисто backend-ошибку в API Commerce OS, а ставите plugin для браузерной автоматизации только потому, что он популярный, — это как брать в лифт палатку: снаряжение, да, но к этому походу отношения не имеет. Спросите себя, какой тип проверки даст больше сигнала прямо сейчас — и сразу видно, что один plugin не обязан закрывать всё.

5. Скучный командный plugin окупается быстрее эффектного

После того как код понят, изменён и локально проверен, остаётся ещё одна важная зона — упаковать результат в командный процесс. Именно здесь плагины интересны уже не одному разработчику, а команде. На демо они невзрачны, зато быстро окупаются: PR описываются единообразно, вход в проект короче, а полезные договорённости перестают жить только в головах самых терпеливых коллег.

Интересно, что именно командный workflow чаще всего оказывается самым недооценённым. На плагины обычно смотрят как на личные ускорители — «чтобы мне было быстрее». А выигрыш команды нередко в другом: новый человек быстрее понял проект, PR выглядят одинаково, не надо по кругу объяснять одни и те же правила про review, setup и границы изменений. Plugin здесь не аттракцион, а способ перенести рабочую привычку из головы автора в воспроизводимую форму.

6. Категория на каждую категорию — это перегруз

Когда вы впервые начинаете мыслить категориями, появляется новая ловушка: кажется, что раз категории полезны, можно поставить по одному plugin на каждую и стать максимально эффективным. На практике это почти всегда перегруз. Категории пересекаются: один plugin закрывает ревью, PR workflow и часть командного tooling; другой — тестирование, браузерные проверки и frontend/UI. Само пересечение не беда — беда, когда каждую категорию считаешь отдельной обязательной установкой.

Вместо этого полезно сделать короткую заметку с планом ещё до установки. Например, так:

# team-review-kit

Главная боль: review diff перед PR
Нужные категории: ревью кода, Git/PR workflow
Не включаем: browser automation, infra
Причина: первая версия должна решать одну боль — качественный review.

Такая короткая заметка отрезвляет лучше любого рейтинга: она заставляет формулировать не «что мне нравится», а «какую работу должен сократить этот пакет». И очень быстро половина красивых идей оказывается любопытством, а не болью.

Здесь же появляется типичный многоплагинный героизм: один plugin комментирует PR, другой красиво собирает summary по diff, третий подкидывает checklist — и вы ставите все три. Через полчаса команды дублируются, названия похожи, а понять, кто за что отвечает, сложнее, чем написать PR description руками. Две установки в одной зоне решают одну боль — не радуйтесь разнообразию, сравните capability surface и оставьте одно.

7. Звёзды не знают, что вы чините refund

Популярность сама по себе не бесполезна, но это очень плохой первый фильтр. Сигнал социальный, не инженерный: plugin много обсуждали, часто ставили, хорошо продвигали — про ваши задачи, стек, команду и ограничения почти ничего. Можно сказать грубее: количество звёзд не знает, что вы сейчас чините refund-логику, а не снимаете ролик «100 AI plugins in 10 minutes».

Сравнение полезно держать перед глазами буквально так:

Хороший инженерный порядок мыслей выглядит иначе. Сначала: «Нужна ли нам вообще эта категория?» Потом: «Что plugin реально делает?» Потом: «Не дублирует ли то, что уже решено внутри Workflow Kit?» И только потом популярность — маленький дополнительный сигнал: если два plugin одинаково подходят по категории и capability surface, разумно взять тот, у кого лучше README, активнее поддержка, понятнее репозиторий. Довесок при равенстве, а не стартовая эвристика.

На примере Commerce OS разница особенно заметна. Популярный plugin для браузерной автоматизации, пусть даже хороший, не станет полезнее от лайков, если весь спринт у вас про review backend-изменений и дисциплину PR. Наоборот — займёт место в голове и подтолкнёт тянуть тяжёлый инструмент туда, где хватило бы спокойного read-only review.

8. Категории на конкретных плагинах официального marketplace

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

Самый спокойный способ собрать осмысленный шорт-лист — заглянуть в claude-plugins-official. Это официальный, поддерживаемый Anthropic marketplace с плагинами, прошедшими хотя бы базовую проверку. По умолчанию он подключён к Claude Code; внутри — несколько десятков пакетов, разложенных по тем самым категориям. Не «единственный правильный источник», но самая аккуратная стартовая точка: что лежит здесь, имеет владельца, обозримую поддержку и понятный путь установки.

Чтобы не превращать лекцию в каталог, давайте просто пройдёмся по пяти плагинам — по одному на разные категории. Не «обязательный набор», а пример того, что вообще бывает.

Code Review — категория ревью кода

Это, пожалуй, самый показательный пример того, как абстрактная категория «ревью кода» превращается в установленный плагин. Code Review — официальный Anthropic-verified плагин из claude-plugins-official. Внутри — несколько reviewer-агентов, работающих параллельно над разными срезами изменения: соответствие правилам из CLAUDE.md, потенциальные баги, контекст из истории git, прошлые комментарии к PR, осмысленность комментариев в коде. Каждое замечание получает confidence-оценку, по умолчанию отсекается то, что ниже порога (порог настраивается).

Запускается это на ветке с готовым PR командой вида /code-review, результат в терминал; при желании публикуется комментарием к PR. Показательный capability surface: плагин читает diff и git-историю, но в простом режиме ничего никуда не пишет. Публикация комментариев — отдельное осознанное действие, не часть «по умолчанию».

Code Simplifier — категория рефакторинга

Code Simplifier — официальный плагин, автономно ищущий, что безопасно упростить в недавно изменённом коде. Не «переписать модуль с нуля», а уменьшить вложенность, заменить запутанные тернарные конструкции на ясные ветвления, привести имена переменных в порядок, убрать дублирование. «Недавно изменённый» тут принципиально: плагин не переделывает половину репозитория, работает по свежим правкам.

У него есть приятный побочный эффект, о котором обычно молчат: упрощённый код в будущих сессиях занимает меньше токенов, Claude читает его быстрее, контекст не раздувается сложностью. Это хороший пример того, что плагин бывает не только «фичей для задачи», но и инструментом гигиены кодовой базы.

frontend-design — категория frontend/UI

Если вы хоть раз просили LLM сгенерировать интерфейс «с чистого листа», вы знаете эффект: все результаты — близнецы. Бледный градиент, шрифт Inter, кнопки с лёгким border-radius, центрированный layout. Это distributional convergence — модель скатывается в статистическое среднее обучающих данных. frontend-design от Anthropic — официальный skill, который толкает Claude не в среднее, а в осознанные aesthetic-решения: brutalist, maximalist, retro-futuristic, luxury, playful — конкретный выбор под задачу, а не «универсальная красота из ниоткуда». На момент написания лекции у skill сотни тысяч установок — для UI-инструмента показательно: пользователи устали от одинаковых AI-интерфейсов.

Capability surface тут принципиально другой, чем у Code Review: frontend-design не reviewer, а co-creator — помогает создавать визуальный код, а не оценивать существующий. По нашей терминологии стоит на пересечении frontend/UI и рефакторинга/упрощения, ближе к первой.

Skill Creator — мета-категория «инструменты для развития skills»

Здесь мы попадаем в зону, которую новички часто пропускают. Skill Creator — официальный плагин, помогающий создавать сами skills. Звучит как мета-перебор, а на практике закрывает очень осязаемую боль: самописный SKILL.md обычно болен одним — описание слишком расплывчатое, чтобы стабильно срабатывать в нужный момент. У Skill Creator четыре режима — Create, Eval, Improve, Benchmark — и несколько специализированных агентов: один гоняет skill против тестовых промптов, второй оценивает результат, третий делает A/B-сравнение двух версий, четвёртый предлагает точечные улучшения.

Подход для нашего курса эталонный: разработка skills из «написал markdown и надеемся» превращается в нормальный eval-driven цикл с измеримым качеством. Если вы серьёзно строите Workflow Kit команды, рано или поздно понадобится что-то в этом роде. И оно уже в маркетплейсе.

Superpowers — целая методология как plugin

Superpowers стоит немного особняком. Это не один маленький инструмент под конкретную категорию, а целый framework методологии, упакованный как plugin. Внутри — около дюжины composable skills: брейншторминг, test-driven development по циклу red-green-refactor, subagent-driven development, structured code review, инструменты для проектирования новых skills и многое другое. По сути — упакованная инженерная культура: вместо того чтобы каждый раз договариваться с командой, «как именно мы работаем с ИИ», вы получаете готовый набор привычек в виде markdown-файлов.

Технически Superpowers — это плагин третьей стороны (автор — obra), но он попал в официальный marketplace, и это хороший сигнал. Главная его сила в том, что работа с ИИ становится умнее: вместо «попроси Claude, получи результат» появляется внятный workflow с фазами, контролем качества и разделением ролей. Plugin закрывает не отдельную фичу, а способ работы целиком. Тот же набор skills работает не только в Claude Code, но и в Cursor, Codex, Copilot CLI, Gemini, OpenCode — методология не привязана к одному инструменту.

Короткое замечание про version-resilience

Все пять описанных плагинов — это снимок состояния маркетплейса на момент написания лекции. Конкретные команды, имена опций, версии, состав агентов внутри и даже расположение плагина могут меняться. Не меняется механика: открываете claude-plugins-official (или другой marketplace, которому доверяете), фильтруете по категории задачи, читаете capability surface и решаете, добавляет ли плагин что-то к тому, что уже есть в Workflow Kit. Список имён — приятный бонус, а не источник истины. Источник истины — текущее содержимое маркетплейса и его documentation.

9. Экосистема как карта, а не витрина

Теперь соберём всё это в нашем текущем контексте. У нас есть Workflow Kit со skills вроде issue-analysis и pr-review. В первой лекции этого уровня мы пришли к тому, что некоторые из них созрели для упаковки в переиспользуемый пакет. Сегодняшняя лекция добавляет недостающий кусок: прежде чем выбирать из экосистемы, надо понять, к какой категории относится наш будущий plugin.

Для первой версии нашего пакета мышление получается очень трезвое. Мы не строим «plugin обо всём» — мы видим одну командную боль: PR надо смотреть структурно и единообразно. Значит, базовая категория — ревью кода. Рядом почти неизбежно примыкает Git/PR workflow: review живёт не в вакууме, а в diff, summary и PR notes. Остальное пока вторично.

Это можно зафиксировать коротко, без лишней драматургии:

# Решение по plugin-package

Пакет: team-review-kit
Базовая категория: ревью кода
Соседняя категория: Git/PR workflow
Вне первой версии: browser testing, infra, project memory
Цель: сократить время self-review и сделать PR более ровными.

Но короткий список категорий и даже имя пакета — ещё не установка. Совпадение по категории только сужает поиск. Дальше — проверить источник, capability surface, совместимость и лишь потом решать, ставить ли пакет и в каком scope.

И вот после такой записи экосистема начинает выглядеть намного спокойнее. Список «лучших плагинов мира» не нужен — нужна очень маленькая его часть: всё про ревью кода и Git/PR workflow, с аккуратным capability surface и без лишнего груза. А значит, любой marketplace, любой каталог, любые рекомендации коллег превращаются из «всё надо изучить» в простой источник кандидатов для короткого списка.

В этом и есть главное взросление на сегодняшней теме. Читаете экосистему именами и топами — она бесконечна и оттого пугает. Читаете категориями — сворачивается до нескольких классов боли, из которых вашей задаче отвечают один-два. Имя и звёзды остаются, но перестают командовать: сначала категория, потом capability surface, и только потом всё прочее. Экосистема перестаёт быть витриной и становится картой. А с картой работать всегда легче, чем с витриной.

1

Задача

Claude code, 10 уровень, 1 лекция

Недоступна

Разложить локальный plugin catalog по категориям через терминал

Разложить локальный plugin catalog по категориям через терминал

Открыть

1

Задача

Claude code, 10 уровень, 1 лекция

Недоступна

Сформировать category-first shortlist через Claude Code

Сформировать category-first shortlist через Claude Code

Открыть