# Один мільйон Agent Skills: README для AI перетворюється на новий тип software

> skills.sh за сім місяців виріс до мільйона skills і майже 280 млн installs. Розбираємо, що насправді кажуть ці цифри, чому skill – це software з версіями й багами, і з чого почати команді.

- Автор: Юра Скиба (https://cookiesoftware.io)
- Опубліковано: 2026-10-15
- Категорія: AI в роботі розробника
- Canonical: https://cookiesoftware.io/blog/agent-skills-one-million

---

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](/blog/claude-code-dlia-react), а формалізований крок далі – [Dynamic Workflows у Copilot](/blog/github-copilot-dynamic-workflows), де процес стає повторюваним артефактом усієї команди.

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

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

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

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

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

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

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

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