Екосистема плагінів: категорії та вибір

1. Топ тижня нічого не знає про вашу задачу

Щойно workflow дозрів до пакета, який можна встановити, дуже кортить учитися за принципом «що зараз у топі». Бажання зрозуміле: список імен створює ілюзію, що хтось уже подумав замість вас, але чужий рейтинг майже ніколи не збігається з вашою задачею. Для навчання це подвійна пастка: ви запам’ятовуєте бренди, а не біль, який знімає кожен плагін.

Уявіть звичайний будівельний магазин. Якщо ви зайшли туди без запитання «мені потрібен дриль, викрутка чи рівень?», полиця «найпопулярніші інструменти місяця» поведе куди завгодно, тільки не до потрібної покупки. Із плагінами так само. Важлива не гучна назва, а клас задачі: документація, diff, браузерні перевірки, GitHub, інфраструктура, командний workflow.

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

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

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

team-review-kit

Ось наочний приклад із нашого Workflow Kit. Припустімо, у нас уже є skill для self-review:

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

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

Таке розмежування особливо виручає, коли ви обговорюєте рішення з командою. «Давайте поставимо популярний плагін» — фраза ні про що. «Нам потрібен плагін категорії ревʼю коду, з мінімальними правами, без браузерної автоматизації, щоб скоротити self-review перед PR» — це вже нормальна інженерна вимога.

3. Найцінніший плагін часто не пише жодного рядка коду

Не всі плагіни існують заради написання коду. Велика й дуже корисна їхня частина працює раніше — на вході в проєкт, у пошуку контексту, у розумінні, де живе потрібна логіка. Для новачка це особливо цінно: поки ви ще не впевнені в кодовій базі, плагін-навігатор нерідко корисніший за той, що обіцяє «згенерувати все замість вас».

Початківцю розробнику часто здається, що най«крутіший» плагін — той, що відразу змінює код. А виграш зазвичай раніше: якщо в Commerce OS ви щоразу заново згадуєте, де команди запуску і як називається модуль, то плагін для пам’яті проєкту окупиться швидше за ще одного модного рефакторщика.

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

4. «AI допомагає програмувати» — це пʼять різних інструментів

Ось тут починається та частина екосистеми, яку зазвичай і уявляють, коли чують слово «плагін». Але навіть усередині неї корисно бачити не один загальний мішок, а кілька класів задач: одні дивляться diff і шукають ризик, інші перевіряють інтерфейс у браузері, треті підсвічують небезпечні місця в безпеці, четверті підказують безпечні спрощення. Ззовні все це «AI допомагає програмувати», а по суті — різні інструменти.

Важливий нюанс тут такий: категорія корисна лише тоді, коли збігається з поточною задачею. Якщо ви зараз лагодите суто backend-помилку в API Commerce OS, а ставите плагін для браузерної автоматизації лише тому, що він популярний, — це як брати в ліфт намет: спорядження, так, але до цього походу воно не має стосунку. Запитайте себе, який тип перевірки дасть більше сигналу просто зараз — і одразу видно, що один плагін не зобов’язаний закривати все.

5. Нудний командний плагін окупається швидше за ефектний

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

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

6. Плагін на кожну категорію — це перевантаження

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

Замість цього корисно зробити коротку нотатку з планом ще до встановлення. Наприклад, так:

# team-review-kit

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

Така коротка нотатка протвережує краще за будь-який рейтинг: вона змушує формулювати не «що мені подобається», а «яку роботу має скоротити цей пакет». І дуже швидко половина красивих ідей виявляється цікавістю, а не болем.

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

7. Зірки не знають, що ви лагодите refund

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

Порівняння корисно тримати перед очима буквально так:

Добрий інженерний порядок думок виглядає інакше. Спочатку: «Чи потрібна нам узагалі ця категорія?» Потім: «Що плагін реально робить?» Потім: «Чи не дублює він те, що вже вирішено всередині Workflow Kit?» І лише потім популярність — маленький додатковий сигнал: якщо два плагіни однаково підходять за категорією та capability surface, розумно взяти той, у кого кращий README, активніша підтримка, зрозуміліший репозиторій. Додавка за рівності, а не стартова евристика.

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

8. Категорії на конкретних плагінах офіційного marketplace

Досі ми навмисно трималися на рівні категорій — це правильний спосіб почати. Але в якийсь момент корисно побачити, як розмова про категорії приземляється на конкретні плагіни, інакше категорії лишаються красивими, але абстрактними.

Найспокійніший спосіб зібрати змістовний short-list — зазирнути в 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 — ціла методологія як плагін

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

Технічно Superpowers — це плагін третьої сторони (автор — obra), але він потрапив до офіційного marketplace, і це гарний сигнал. Головна його сила в тому, що робота з ІІ стає розумнішою: замість «попроси Claude, отримай результат» з’являється чіткий workflow з фазами, контролем якості та розподілом ролей. Плагін закриває не окрему фічу, а спосіб роботи цілком. Той самий набір 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. У першій лекції цього рівня ми дійшли до того, що деякі з них дозріли для упакування у повторно використовуваний пакет. Сьогоднішня лекція додає бракуючий шматок: перш ніж вибирати з екосистеми, треба зрозуміти, до якої категорії належить наш майбутній плагін.

Для першої версії нашого пакета мислення виходить дуже тверезе. Ми не будуємо «плагін про все» — ми бачимо один командний біль: 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, і лише потім усе інше. Екосистема перестає бути вітриною і стає картою. А з картою працювати завжди легше, ніж із вітриною.