Vercel опублікував зріз skills.sh: за сім місяців (січень–серпень 2026) registry виріс до одного мільйона agent skills і зафіксував майже 280 мільйонів installs – швидше, ніж ранні GitHub, App Store чи npm досягали зіставних позначок. Цифри варто читати обережно (це aggregate-лічильники, а не унікальні люди), але тренд справжній: інструкції для агентів стають окремим типом software – з версіями, залежностями, багами й жорсткою концентрацією популярності. Розбираємо, що з цього випливає для команд.

Цифри – і що вони насправді означають

Сам звіт чесно уточнює методологію, і це уточнення важливіше за заголовок: мільйон skills і 280 млн installs – агрегатні лічильники registry, а не мільйон унікальних авторів чи 280 мільйонів людей. Install може бути перевстановленням, CI-скриптом, одним користувачем на пʼяти машинах.

Для масштабу Vercel наводить порівняння: до зіставної позначки GitHub ішов 27 місяців, App Store – 63, npm – 117. skills.sh доїхав за сім. Частково це заслуга низького порогу входу (skill – це за суттю Markdown-файл), частково – того, що агенти вже стоять у кожного другого розробника й «встановити інструкцію» коштує одну команду.

Найцікавіша статистика – не про обсяг, а про розподіл:

  • майже половину всіх skills встановили рівно один раз – найчастіше сам автор;
  • 375 skills – 0.04% каталогу – забирають 62% усіх installs;
  • топ-1.2% skills покривають 94% installs;
  • при цьому навіть найпопулярніший skill має менше 1% від загальних установок – монополіста немає, є довгий хвіст і тонка верхівка.

Якщо це звучить знайомо – так, це крива npm. Створити пакет легко. Створити пакет, якому довіряють, – зовсім інша дисципліна.

Попит ≠ пропозиція

Ще один неочевидний зріз. У пропозиції домінують інженери: понад половина листингів вчить software engineering, agent workflows, data, інфраструктуру або security. А от у попиті все рівномірніше: жодна категорія не збирає більше п'ятої частини installs – software engineering лідирує з 18%, agent workflows дають 15%, а business operations, writing і cloud-інфраструктура стабільно отримують непропорційно багато установок відносно своєї частки в каталозі.

Переклад людською: інженери пишуть skills для інженерів, а користуються ними далеко не лише інженери. 87.5% installs припадає на крос-індустрійні задачі – універсальний skill у середньому отримує в 3.6 раза більше установок за вузькогалузевий.

Що таке skill і чому це software

Якщо відкинути маркетинг, skill – це reusable-інструкції для агента:

  • як команда робить release;
  • як ревʼювити дизайн;
  • як створити міграцію;
  • які критерії якості;
  • які tools використовувати і в якому порядку.

Те, що раніше жило в голові сеньйора або на випадковій Notion-сторінці, стає executable context. Ми роками жартували «цей процес знає тільки Саша» – тепер індустрія буквально намагається запакувати Сашу в Markdown.

І тут ключова думка: skill – це software. У нього є версія. Є залежності від конкретних tools. Є поведінковий ефект – агент із ним працює інакше, ніж без нього. А отже, у нього бувають баги й регресії: оновив формулювання – агент почав пропускати крок.

Висновок прямий: skill треба тестувати. Не досить написати:

Always write clean code.

Це не skill, це побажання. Робочий skill має приклади, обмеження і спостережуваний критерій успіху – те саме, що відрізняє специфікацію від гасла. Як ставити такі задачі агенту, я детально розбирав у статті про Claude Code, а формалізований крок далі – Dynamic Workflows у Copilot, де процес стає повторюваним артефактом усієї команди.

З чого почати команді

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

  1. Вибери процес – release preparation, PR review за правилами команди або incident triage.
  2. Запиши його як skill: кроки, tools, приклади гарного й поганого результату, критерій «готово».
  3. Прожени на 20 реальних задачах з історії – так само, як ми робили eval для агентів. Записуй, де агент помилився: це баги твого skill, а не «дурість моделі».
  4. Ітеруй формулювання як код: версія, changelog, перевірка на тих самих 20 задачах після кожної зміни.

Оце вже knowledge engineering, а не промпт-магія. Побічний ефект часто цінніший за автоматизацію: щоб записати процес для агента, команді доводиться вперше чесно домовитись, який у неї процес.

Чому більшість skills ніхто не встановлює

  • Писати skill як есе. Агенту потрібні кроки, приклади й критерії, а не філософія про clean code.
  • Встановлювати чужі skills без читання. Skill – це інструкції, які виконуватиме агент із твоїми правами. 0.04% каталогу з довірою заробили її не випадково; решту читай як незнайомий код із інтернету – бо це він і є.
  • Не версіонувати. «Я трохи підправив формулювання» без перевірки на еталонних задачах – це деплой у production без тестів.
  • Пакувати в skill поганий процес. Автоматизований хаос – досі хаос, просто швидший.

Запакуй один свій процес у skill

Візьми один процес, який ти цього місяця пояснював колезі голосом або в чаті. Запиши його як skill: не більше сторінки, з трьома прикладами (два гарні, один поганий) і явним критерієм готовності. Прожени агента на пʼяти минулих задачах цього типу і порахуй, скільки разів результат збігся з тим, що тоді зробила людина. Це число – версія 0.1 твого першого протестованого skill.