Plugins

На минулому вебінарі ви зібрали свій перший skill - git-commit. Він лежить у .claude/ і працює у вас. Але щойно ним захочуть користуватися колеги, одразу постає кілька питань: як роздати, як оновлювати, як не ловити конфлікти імен. Саме на це й відповідає plugin - спосіб упакувати ваші skills (а згодом і agents, hooks, MCP) в один поширюваний набір.

Сьогодні розберемо:

коли standalone-налаштувань у .claude/ вистачає, а коли workflow час пакувати в plugin;
як влаштована екосистема готових плагінів і де їх брати;
install scopes і життєвий цикл: /plugin, marketplace, /reload-plugins;
як перевірити плагін на безпеку перед встановленням;
як зібрати мінімальний плагін для команди самому.

Наскрізний приклад team-kit: плагін, який пакує два ваші skill з минулого вебінару - git-commit та prompt-improve - в один набір для команди.

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

Сьогодні пройдемо: рівень 10. Plugins, plugin ecosystem та team-ready plugins.

Майстерня, ящик і плагін

Повернімося до нашого столяра. У нього є скіл - "Прибирання та підготовка робочого місця": інструмент по місцях, кава праворуч на верстаку, усе записано один раз. Тепер ця процедура потрібна не йому одному: сусід по цеху просить "дай своє прибирання та заточку", підходить підмайстер, а через дорогу - друга майстерня. Пересилати кожному по теці руками швидко набридає.

Тут і з'являється плагін - іменний ящик оснащення. Столяр складає в нього кілька своїх процедур разом, ставить збоку тавро майстерні й кладе записку "що всередині і як цим користуватися". Не ще одна процедура, а ящик, який тримає їх разом: такий можна віддати цілком, оновити й пронумерувати.

Зібрав ящик, віддав - і ось що це змінює:

Тавро розводить однакові імена. У сусіда теж є "прибирання". Поки на ящику тавро, їх не сплутати: беруть "прибирання з ящика Бендера", а не безіменне. За спільний набір платять довгим іменем.
Ящик приймають, а не кидають у куток. Чужий ящик не заводиться сам: майстерня його розписує й заносить до реєстру. Усередині - живий інструмент під напругою, а не плакат на стіну, тому підпис ставлять свідомо.
Ящики беруть зі складу оснащення. Потрібен чужий набір - ідете на склад, чіпляєте його і знімаєте їх по одному, а не тягнете весь стелаж.
Відкритий ящик займає верстак. Навіть незайманий ящик на столі їсть місце з першої секунди. На верстаку тримають ті, що реально в роботі, решту закривають.
Кому дістанеться ящик - вирішуєте заздалегідь. Особисто вам у всіх майстернях, усій бригаді цього цеху чи лише в цьому цеху - під кожен випадок свій рівень.

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

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

Уміння та упаковка

Одна пастка збиває найчастіше: здається, що плагін - це "скіл на максималках". Річ не в розмірі: навіть один скіл, загорнутий у маніфест, - уже плагін. Різниця не в потужності, а в упаковці та роздачі.

Що	Це	Відповідає на питання
Skill	уміння - одна процедура	що Claude вміє робити
Plugin	упаковка навколо умінь	як це роздати й оновлювати

Скіл - це уміння. Одна процедура: SKILL.md з інструкцією, поруч опційно scripts і references. Одиниця поведінки.
Плагін - це упаковка. Коробка навколо одного-кількох умінь: маніфест (ім'я, версія, namespace) плюс вміст. Сам по собі плагін нової поведінки не додає - він пакує, версіонує й роздає те, що вже є.

Найпростіше тримати так: skill - уміння, plugin - тара навколо умінь. Сьогодні ми саме цим і займемося: упакуємо готові скіли, не написавши нової поведінки.

Коли skill час пакувати в plugin

Ваш git-commit працює, але живе в одному репозиторії. Standalone .claude/ добрий для особистого й одно-проєктного - питання в тому, коли цього стає замало.

Сигнали, що час у plugin - вистачає навіть одного:

ділитеся з командою чи спільнотою - набір потрібен не лише вам;
той самий набір потрібен у кількох репозиторіях;
потрібні версії та оновлення, а не ручне пересилання;
хочете уникати конфліктів імен між різними наборами;
роздаєте через marketplace;
пакуєте разом skills, agents, hooks та MCP в один набір.

Не поспішайте пакувати перший вдалий skill у plugin. Спершу переконайтеся, що ним справді треба ділитися: standalone у .claude/ лишається правильним вибором для особистого й одно-проєктного.

Ціна за упакування - імена стають довшими: /team-kit:git-commit замість /git-commit. Звідки це - на наступному слайді.

Namespace плагіна

Skills із плагіна завжди звуться з префіксом: /plugin-name:skill-name. Це не бюрократія, а захист від конфліктів.

два різні плагіни можуть принести skill з іменем commit - namespace їх розводить;
префікс береться з поля name у маніфесті плагіна;
standalone-skill зветься коротко /git-commit, плагінний - через namespace /team-kit:git-commit.

Тобто коротке ім'я - привілей особистого налаштування, а плагін платить префіксом за те, що його skills не зіткнуться з чужими.

Ім'я плагіна name задає одразу і ідентифікатор пакета, і namespace його skills. Зміните name - зміниться префікс у всіх skills плагіна.

Які плагіни бувають

Під майже будь-яке завдання в екосистемі вже щось є - і зазвичай не одне. Корисніше не запам'ятовувати каталог імен, а розуміти класи роботи - тоді ви знаєте, де шукати.

mindmap root(("Плагіни")) code["Code intelligence / LSP"] integ["Зовнішні інтеграції"] git["GitHub / GitLab"] track["Jira / Linear / Notion"] review["Code review"] test["Testing"] sec["Security"] dev["Dev workflows"]

На схемі плагіни згруповані за типом користі. Ось що лежить в офіційному наборі вже зараз:

code intelligence - LSP-плагіни за мовами, напр. typescript-lsp та pyright-lsp: навігація та помилки типів одразу після правки; потрібен language server;
зовнішні інтеграції - під'єднують Claude до GitHub, трекера, дизайну через готовий MCP-сервер; MCP, як ви вже бачили на карті розширень, це доступ до зовнішніх інструментів і даних, наприклад читати завдання з трекера без copy-paste;
code review та testing - готові рев'юери та помічники з тестів, напр. pr-review-toolkit; він робить рев'ю PR - пропозиції влити гілку в основну, і Claude вміє їх готувати та коментувати;
security - security-guidance перевіряє кожну зміну на типові вразливості;
dev workflows - commit-commands та plugin-dev: commit, PR, створення власних плагінів.

Категорії - це карта для орієнтації, а не обов'язок: поставили один потрібний плагін - і класифікація не потрібна. Кошики виручають, коли вибираєш у великому каталозі. А механіку того, що плагіни приносять (MCP, agents, LSP), розберемо на своїх рівнях.

Точний склад офіційного marketplace змінюється. Відкрити актуальний список - /plugin, вкладка Discover, або каталог на claude.com/plugins.

Плагін треба під'єднати

Тут плагін поводиться не як skill з минулого вебінару. Skill ви клали в .claude/skills/, і Claude читав його прямо з теки: поклав - працює. З плагіном так не вийде.

плагін - керований пакет: при встановленні він копіюється в кеш, отримує версію та namespace, а не читається з довільної теки репозиторію;
він виконує код із вашими правами, тому Claude Code вимагає явного кроку встановлення, а не запускає код зі склонованої теки мовчки.

Під'єднати можна трьома шляхами:

/plugin install ...@marketplace - звичайне встановлення собі;
claude --plugin-dir ./path - на одну сесію, для розробки й тесту;
для команди - прописати marketplace через extraKnownMarketplaces та потрібні плагіни через enabledPlugins у .claude/settings.json проєкту; колега, довіряючи репозиторію, отримає пропозицію їх встановити.

Просто покласти теку з плагіном у репозиторій і чекати, що підхопиться сам, - не спрацює: плагін із marketplace треба під'єднати командою, на відміну від skill.

Marketplace: каталог плагінів

Ці команди ви вже бачили мигцем: Skill Creator на минулому вебінарі ставили через /plugin marketplace add та /plugin install. Тепер розберемо механіку цілком.

Marketplace - це каталог чужих плагінів, і користуватися ним це два кроки: спершу додати каталог, потім ставити з нього окремі плагіни. Як app store: додали магазин - далі вибираєте застосунки по одному.

claude-plugins-official від Anthropic доступний одразу, додавати нічого не треба;
community-маркетплейс додають вручну: /plugin marketplace add anthropics/claude-plugins-community;
джерелом каталогу може бути GitHub-репо у форматі owner/repo, git-URL, локальний шлях або URL на marketplace.json.

sequenceDiagram participant Dev as "Developer" participant CC as "Claude Code" participant MP as "Marketplace" Dev->>CC: /plugin marketplace add owner/repo CC->>MP: завантажити каталог Dev->>CC: /plugin install name@marketplace CC->>MP: завантажити плагін Dev->>CC: /reload-plugins CC-->>Dev: skill доступний як /name:skill

Ось тут і видно ті самі два кроки: додавання каталогу не ставить жодного плагіна, встановлення йде окремою командою, а /reload-plugins підхоплює новий skill у поточній сесії.

# official доступний одразу - ставимо прямо
/plugin install github@claude-plugins-official

# community додаємо вручну, потім ставимо з нього
/plugin marketplace add anthropics/claude-plugins-community
/plugin install <plugin>@claude-community

Не ставте все підряд: плагін виконує код із вашими правами. Ставте з джерел, яким довіряєте; на зірки та популярність не покладайтеся. Як перевірити плагін перед встановленням - розберемо трохи далі.

У сторонніх каталогів бувають власні встановлювачі - і такий встановлювач може спитати спосіб встановлення: symlink чи копія. Різниця видна, коли в проєкті кілька агентів - Claude Code, Codex та інші: такі інсталери часто ставлять skill їм усім одразу. Symlink, зазвичай позначений як Recommended, - усі агенти дивляться на той самий файл: оновили каталог - оновилося в усіх; копія - у кожного агента свій незалежний знімок, і з часом вони розходяться. На Windows symlink іноді вимагає режим розробника або права адміністратора - тоді простіше взяти копію.

Прямо зараз, якщо Claude Code під рукою: наберіть /plugin, вкладка Discover - official-каталог уже під'єднаний. Нічого не ставте, просто відкрийте деталі будь-якого плагіна й подивіться, що він принесе. Це нульовий крок практики 2: спершу дивимося, потім вирішуємо.

Install scopes: кому дістанеться плагін

Це ті самі три рівні, що й у налаштувань .claude/ на першому вебінарі (user / project / local), просто тепер вони вирішують, куди стане плагін. Питання рівно те саме, що було у skills: кому він потрібен.

user scope (за замовчуванням) - вам у всіх проєктах;
project scope - усій команді цього репозиторію, прописується в .claude/settings.json і їде в version control;
local scope - лише вам і лише в цьому репозиторії, колегам не видно.

flowchart TD A["Кому потрібен плагін?"] --> B["Лише мені, у всіх проєктах"] A --> C["Усій команді цього репо"] A --> D["Лише мені, у цьому репо"] B --> E["User scope"] C --> F["Project scope - .claude/settings.json"] D --> G["Local scope"]

За замовчуванням /plugin install ставить у user scope. Щоб вибрати інший - відкрийте інтерактивний /plugin, вкладку Discover, і при встановленні вкажіть scope.

Є ще managed scope - його ставить адміністратор через managed settings, і змінювати його не можна. У більшості його ніколи не буде; зустрінете - значить, так вирішили в організації.

Життєвий цикл плагіна

Уся робота з плагінами живе за однією командою - /plugin. Вона відкриває менеджер із вкладками.

Discover - шукати плагіни в усіх ваших marketplace;
Installed - керувати тим, що стоїть: увімкнути, вимкнути, видалити;
Marketplaces - додавати й оновлювати каталоги;
Errors - дивитися помилки завантаження плагінів.

Поставити, тимчасово вимкнути, увімкнути назад чи видалити - команди /plugin install | disable | enable | uninstall. Після встановлення чи перемикання запустіть /reload-plugins, щоб підхопити зміни без рестарту; skills з'являться під namespace, напр. /team-kit:git-commit.

Коли плагін заважає

Плагін стоїть і щось пішло не так - конфлікт, помилка завантаження, сесія гальмує? Це не глухий кут: вимкніть його через /plugin disable, причину дивіться у вкладці Errors, не потрібен зовсім - /plugin uninstall, а в крайньому разі почистіть кеш ~/.claude/plugins/cache і перевстановіть.

Після встановлення щось дивне - найперше вимкніть свіжий плагін і подивіться, чи зникла проблема. Швидше, ніж гадати, хто винен.

Плагіни жеруть контекст

Згадайте операційну модель контексту з вебінару 3. У плагіна є ціна, і не лише контекстна - платите за трьома статтями:

контекст, завжди - кожен увімкнений плагін від самого старту додає у вікно оголошення своїх компонентів: імена та описи skills, імена інструментів. Повний контент підтягується вже при використанні, але оголошення висять завжди;
токени на роботу - коли плагін реально працює: відповідь зовнішнього сервісу, тіло skill, вивід його інструментів - це токени понад контекст;
час - плагіни, які ходять у зовнішні сервіси або запускають команди, додають реальні секунди на запит;
/plugin показує context cost ще до встановлення - дивіться на нього, а не лише на користь.

Тому "поставив усе й ніколи не вимикаю" - погана стратегія: вікно зайняте з першої секунди, а важкий плагін у роботі легко подвоює вартість і час запиту. Тримайте активним лише потрібне, зайве - /plugin disable.

Ціну легко побачити на власні очі: наберіть /context - Claude Code покаже, чим зайняте вікно, включно з плагінами. Увімкніть плагін, запустіть ще раз - і порівняйте.

Наставити плагінів "про всяк випадок" - швидкий спосіб засмітити контекст від самого старту й уповільнити сесію. Менше активних плагінів - чистіше вікно й дешевші запити.

Ставити чи ні

Плагін виконує код на вашій машині з вашими правами, тому зірки та "усі ставлять" - не причина ставити. Anthropic не контролює, що всередині стороннього плагіна, тож рішення за вами - і спертися є на що.

Спершу джерело - воно задає базовий рівень довіри

claude-plugins-official - курує Anthropic;
community-маркетплейс - пройшов автоматичну перевірку безпеки Anthropic, але це не гарантія;
довільний git-URL або локальний marketplace - жодної перевірки: самі дивіться, хто його веде і чи є зрозумілий README.

Потім деталі - Claude Code показує їх сам

Живий приклад - великий сторонній набір skills на кшталт superpowers. Просто зараз відкрийте його деталі в /plugin і подивіться на свої цифри; приблизний вигляд такий:

# приклад деталей плагіна - числа умовні, у кожного свої
Will install:  skills: 12   agents: 2   hooks: 1   MCP servers: 0
Context cost:  ~1.8k tokens/session

На що дивитися:

"Will install" і context cost - обсяг і ціну видно до встановлення: склад набору і скільки токенів додасться кожному ходу;
що він уміє - просто skills, які читають і підказують, чи ще вихід назовні й запуск команд;
чи підходить він вам - навіть добрий плагін можна не ставити: він дублює ваш skill або тягне bash-скрипти там, де у команди Windows/PowerShell.

Міра - за плагіном: чим більше він уміє і чим далі джерело від офіційного, тим уважніше дивіться; дрібний офіційний LSP ставлять без церемоній. І ставте в найвужчий відповідний scope: менше прав - менше ризику.

Marketplace із довільного git-URL або локального шляху Claude Code бере й виконує як є, без перевірки. Додавайте такі джерела, лише якщо довіряєте їхньому автору.

Перевірили один раз - не означає заморозили: оновлення - майже новий install, склад може змінитися. Офіційні marketplace оновлюються самі - перед важливим апдейтом пробіжіть деталі заново; авто-оновлення перемикається в /plugin -> Marketplaces.

Плагін - пакувальний контейнер

Структуру треба знати, щоб читати чуже

Під капотом плагін - це звичайна тека, а не магія. І розібратися в ній варто, навіть якщо ви нічого не збираєте: відкрили репозиторій чужого плагіна, глянули на теки - і вже бачите, що він принесе, ще до встановлення. Рівно цей погляд знадобиться вам у практиці 2.

Своє збираємо з готового

team-kit ми теж пишемо не з нуля: беремо готовий git-commit із .claude/skills/, переносимо в теку плагіна й додаємо manifest. Код той самий, змінюється лише обгортка.

# було: standalone-skill
~/.claude/skills/git-commit/SKILL.md

# стало: той самий skill усередині плагіна
team-kit/
  .claude-plugin/plugin.json   # додали manifest
  skills/git-commit/SKILL.md   # перенесли як є
# і skill тепер зветься /team-kit:git-commit

Структура контейнера

Одне правило, яке легко порушити: маніфест plugin.json лежить строго в .claude-plugin/, а все інше - skills/, agents/, hooks/ та інші теки компонентів - у корені плагіна.

mindmap root(("team-kit/")) manifest[".claude-plugin/plugin.json"] skills["skills/"] s1["git-commit/"] s2["prompt-improve/"] readme["README.md"] advanced["agents/ hooks/ .mcp.json - згодом"]

Ось наш team-kit: поки всередині два skill і README, а місце під agents, hooks та MCP підписане на майбутнє. Контейнер росте в міру потреби - зайвого в нього класти не треба.

Типова помилка: засунути skills/ або agents/ всередину .claude-plugin/. Туди йде лише plugin.json, решта тек - у корінь плагіна.

Маніфест plugin.json

Маніфест задає особистість плагіна. Технічно Claude вміє працювати й без нього (auto-discovery за теками), але для командного плагіна ми його не пропускаємо: саме manifest стабільно задає ім'я, namespace та версію, які бачить команда.

name - і ідентифікатор, і namespace skills, звідси префікс /team-kit:...;
version важлива для оновлень: підняли версію - користувачі отримали апдейт; забули, а роздаєте через git - кожен коміт вважається новою версією;
description - те, що побачать у менеджері плагінів;
author - для атрибуції.

{
  "name": "team-kit",
  "description": "Team git-commit and prompt-improve skills",
  "version": "1.0.0",
  "author": { "name": "Platform team" }
}

Це основні поля. Повна схема, де є ще homepage, repository та license, - у документації; набір може змінюватися з версією Claude Code.

Маніфест плюс два skill - і набір готовий

Більше для робочого плагіна нічого не треба: цей маніфест, ваші git-commit та prompt-improve у skills/ і README, без якого команда не зрозуміє, як цим користуватися. Дерево ви щойно бачили на попередньому слайді - від появи маніфеста воно не росте.

Розширений варіант - reviewer-агент і форматувальний hook - лишаємо на потім, після того як розберемо agents і hooks. Зараз перевіримо набір локально, а роздати команді - крок, який розберемо далі.

README - це частина плагіна, а не формальність. Мінімум: що плагін робить, як поставити, які skills усередині і як їх звати.

Перевірте плагін локально

Публікувати плагін, щоб його спробувати, не треба: --plugin-dir вантажить його прямо з теки. І перевіряємо не саму команду, а результат - викликали skill і подивилися, що він реально відпрацював під namespace.

# у терміналі: вантажимо плагін із теки, без встановлення
claude --plugin-dir ./team-kit

# ↓ далі вже всередині Claude Code:
# перевіряємо результат, а не команду: skill відпрацював під namespace?
/team-kit:git-commit
# > created commit a1b2c3d  feat(api): add health endpoint

# змінили файл - підхоплюємо без рестарту
/reload-plugins

# знову в терміналі, перед сабмітом - той самий чек, що й при роздачі
claude plugin validate ./team-kit

Якщо щось не завантажилося, вкладка Errors у /plugin покаже, що саме.

git-commit - action-skill, він робить коміт. Ще з минулого вебінару в ньому стоїть disable-model-invocation: true, щоб Claude не запускав його сам за збігом опису; упакування в plugin це зберігає - викликаєте вручну.

На ходу вистачає --plugin-dir та /reload-plugins. validate - це разовий чек перед сабмітом/роздачею, а не ритуал після кожної правки.

Роздати команді

Плагін зібраний і перевірений - лишилося зробити так, щоб колега поставив його однією командою. Для цього поруч із плагіном заводять свій marketplace: репозиторій-каталог, назвемо його team-tools. Публікувати у відкритий доступ не обов'язково - команді вистачає приватного git-репозиторію.

Колега під'єднує - два рядки

# додати ваш каталог і поставити з нього плагін
/plugin marketplace add ваш-логін/team-tools
/plugin install team-kit@team-tools
/reload-plugins

Ставиться як team-kit@team-tools: ліворуч - ім'я плагіна, праворуч - ім'я marketplace з поля name каталогу, а не ім'я репозиторію. Саме тут плутаються найчастіше.

Або взагалі без команд

Щоб колезі нічого не диктувати, пропишіть каталог і плагін прямо в .claude/settings.json проєкту: extraKnownMarketplaces реєструє сам каталог, а enabledPlugins - це карта "плагін@marketplace": true. Обидва поля їдуть у version control, тому пропозицію встановити отримає вся команда.

{
  "extraKnownMarketplaces": {
    "team-tools": {
      "source": { "source": "github", "repo": "ваш-логін/team-tools" }
    }
  },
  "enabledPlugins": {
    "team-kit@team-tools": true
  }
}

Звідки береться сам team-tools: це ваш marketplace - git-репозиторій із файлом .claude-plugin/marketplace.json, який перелічує плагіни через поля name, source та description, а тека team-kit лежить поруч. Завели, закомітили, запушили - каталог готовий.

Якщо забудете все інше

Деталей сьогодні було багато. Якщо лишити тільки те, що реально знадобиться в роботі, - ось на що я б радив звернути увагу.

Не поспішайте пакувати все в плагіни. Standalone у .claude/ чудово живе для особистого й одного проєкту; plugin діставайте, коли справді треба ділитися й версіонувати.
Тримайте в голові, що плагін треба під'єднати. Це не skill із теки - його ставлять через /plugin install або оголошують у project-налаштуваннях; просто покласти в репо не спрацює.
Ставте з оглядкою на джерело. Плагін виконує код із вашими правами, тому дивіться на автора і на "Will install", а не на кількість зірок.
Менше активних плагінів - здоровіша сесія. Кожен висячий плагін їсть контекст і час від самого старту; зайве спокійно вимикайте через /plugin disable.
Зламалося - це робоча ситуація, а не глухий кут. Плагін завжди можна вимкнути й зазирнути в Errors.

Далі на своїх рівнях ми розберемо agents і subagents, MCP-сервери та hooks - кожен сам по собі, як окремий інструмент. Пакувати їх у плагін ви вже вмієте: механіка та сама, змінюється лише вміст теки. Головне вже є - зібрати свій набір і свідомо поставити чужий. Лишилося зробити це своїми руками.

Практика 1

Теорія закінчилася - далі руками, у своєму темпі. Це не про новий skill з нуля: ви берете два свої skill, git-commit та prompt-improve, і перетворюєте їх на один поширюваний плагін. Робите це у себе в репозиторії, тож реальний коміт від git-commit - нормальна частина перевірки, а не ризик.

Етап 1 - зібрати контейнер

Створіть теку team-kit/, покладіть маніфест у .claude-plugin/, перенесіть обидва skill як є в skills/ і додайте README. Дерево контейнера - на слайді "Плагін - пакувальний контейнер", поля маніфеста - на слайді "Маніфест plugin.json"; звіряйтеся з ними, а не відновлюйте з пам'яті.

Етап 2 - прогнати локально

Публікувати нічого не треба: вантажимо плагін із теки через --plugin-dir, викликаємо skill під namespace і дивимося на результат, а не на команду. Змінили SKILL.md - /reload-plugins підхопить без рестарту. Наприкінці разово проженіть claude plugin validate ./team-kit. Повний прогін з командами - на слайді "Перевірте плагін локально".

Етап 3 (бонус) - роздати через marketplace

Хто дійде - заведіть marketplace-каталог, як на слайді "Роздати команді": у його .claude-plugin/marketplace.json перелічіть team-kit як plugin source, додайте каталог через /plugin marketplace add і поставте team-kit як звичайний плагін. validate ви вже прогнали на етапі 2.

Вийшло, якщо обидва skill з'явилися під namespace - /team-kit:git-commit та /team-kit:prompt-improve, запускаються вручну, а validate не свариться. І ви можете пояснити, чому skills/ лежить у корені плагіна, а не всередині .claude-plugin/.

Три місця, де зазвичай спотикаються: поклали skills/ всередину .claude-plugin/ - плагін вантажиться, але skills мовчки зникають; забули про namespace і звуть /git-commit замість /team-kit:git-commit; плутають назву маркетплейсу та ім'я плагіна - ставиться це як team-kit@назва-маркетплейсу.

Практика 2

Перша практика була про свій плагін. Ця - про чужий, і завдання тут інше. Вам скидають посилання: "постав, корисна штука". Мета не поставити, а вирішити - воно вам треба чи ні. Візьмемо для цього реальний публічний плагін andrej-karpathy-skills і пройдемо весь шлях: від "що це взагалі" до "лишаю / прибираю" - з аргументами.

Етап 1 - зрозуміти, що це

Нічого не встановлюючи, відкрийте репозиторій на GitHub і прочитайте README, CLAUDE.md та SKILL.md. Завдання одне: своїми словами сказати, що плагін робить.

Етап 2 - зважити під себе

Тепер до встановлення прикиньте ціну, користь і довіру - рівно як на слайдах про "Will install", джерело та контекст. Спершу на джерело: дивимося, хто автор (тут forrestchang) і чи є зрозумілий README, а не на зірки. Далі на обсяг: "Will install" у цього плагіна короткий - skills 1, agents/hooks/MCP - нуль, тобто коду він не виконує, ризик низький. Тепер випишіть собі два короткі списки.

за - що конкретно це лагодить у вашій роботі з Claude:
- менше мовчазних припущень;
- менше роздутих дифів;
- питання до реалізації, а не після.
проти - за що платите:
- skill model-invoked: Claude вмикає його сам на всьому кодингу, а оголошення висить у контексті від самого старту. У практиці 1 git-commit був навпаки - disable-model-invocation, викликали вручну;
- правила можуть дублювати ваш CLAUDE.md;
- зсув "обережність замість швидкості" заважає на дрібних правках.

Етап 3 - спробувати в ділі

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

# 1) без плагіна: даємо завдання, дивимося й запам'ятовуємо результат
> ваше завдання за своїм проєктом

# 2) ставимо плагін
/plugin marketplace add forrestchang/andrej-karpathy-skills
/plugin install andrej-karpathy-skills@karpathy-skills
/reload-plugins

# 3) те саме завдання - порівнюємо з першим прогоном
> те саме завдання

Збіглося з тим, що README обіцяє в розділі "How to Know It's Working"? Тоді користь для вас реальна, а не на словах. Не збіглося чи заважає - це теж валідний результат.

Етап 4 - ухвалити рішення

Лишаєте - плагін просто працює далі. Не ваше - /plugin disable (вимкнути, але не втрачати) або /plugin uninstall. Рішення будь-яке, але воно має бути вашим і з причиною.

І зафіксуйте висновок одним рядком - плагін, scope, причина "лишив / прибрав" - у README команди або описі PR. За два тижні ви не згадаєте, чому він узагалі стоїть, а колезі не доведеться проходити перевірку заново.

Вийшло не коли плагін встановлено, а коли ви можете у двох фразах сказати, що він робить, і назвати одну конкретну причину "лишаю" або "прибираю" - зі свого тесту, а не з README. Це і є навичка: чужий плагін порадили, а вирішуєте ви.

Дві пастки. Перша - поставити, бо "радять", і не перевірити ефект на своєму завданні: користь видно лише в порівнянні до/після. Друга - забути, що це model-invoked skill: його оголошення висить у вікні з першої секунди, а спрацьовує він на всьому кодингу, тож "лишити про всяк випадок" - це плата, а не нуль.