Видобуток навичок: від 3500 кандидатів до 466 можливостей

Числа в цьому дописі відображають стан системи на момент публікації (січень 2026). Актуальні цифри дивіться на нашій сторінці команди.

Проблема 3500 навичок

Коли ми почали будувати систему оркестрації агентів, ми зіткнулися з цікавим викликом: у AI-екосистемі розкидані тисячі потенційних навичок. Репозиторії GitHub, документація вендорів, проєкти спільноти, внутрішні патерни — навички існують всюди. Але які з них важливі? Які працюють? І як підтримувати узгоджену бібліотеку навичок, яку агенти справді можуть використовувати?

Наша відповідь: систематичний цикл видобутку та засвоєння.

Цифри на сьогодні

Лише через трохи більше трьох місяців після того, як Anthropic випустила Agent Skills 16 жовтня 2025 року, ось де ми були на момент публікації цього допису 27 січня 2026 року:

Метрика	Кількість
Виявлено кандидатів	3500+
Ухвалено навичок	466
Навички вендорів	373
Внутрішні навички	93
Активних вендорів	25+
Середня кількість токенів на навичку	2834
Задіяних інструментів	89
Унікальних тегів	635

Ми переглянули понад 3500 кандидатів на навички. Ми ухвалили 466. Це 13% рівень ухвалення — і ця вибірковість навмисна.

Рівнева система знань

Не всі навички рівноцінні. Ми організовуємо їх у п’ять шарів знань (K0–K4), кожен з яких представляє іншу сферу застосовності:

K0: Основи (Універсальні)

Навички, які повинен мати кожен агент. Вони представляють можливості «доброго мислителя», що працюють будь-де.

foundations/
├── test-first-discipline       # TDD: Red-Green-Refactor
├── evidence-based-completion   # Verify before claiming done
├── systematic-debugging        # Root cause methodology
├── structured-planning         # Break work into tasks
└── context-budget-awareness    # Manage token consumption

Навички K0 переносяться в будь-який проєкт, будь-який домен, будь-який стек. Вони кодують універсальні когнітивні патерни.

K1: Ідентичності (Дисципліна)

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

identities/
├── research-workflows          # Multi-source research
├── web-extraction-playbook     # Content extraction
├── code-review                 # PR review patterns
└── cli-interface-standards     # CLI design patterns

K2: Домени (Предметна експертиза)

Навички «доброго експерта з баз даних» чи «доброго інженера з безпеки», перенесувані в межах поля.

domains/
├── schema-migration-workflow   # Safe migration patterns
├── rpc-validation-checklist    # RPC health checks
├── auth-validation-checklist   # JWT/OAuth patterns
└── secrets-audit-checklist     # Credential scanning

K3: Стеки (Технологія)

Навички «доброго користувача Supabase» чи «доброго розробника Cloudflare» для конкретних технологічних стеків.

stacks/
├── maguyva-quickstart          # Our semantic search patterns
├── cloudflare-deployment       # Workers/Pages deployment
└── mcp-tool-best-practices     # MCP tool selection

K4: Проєкт (Організація)

Навички, специфічні для нашої організації та робочих процесів.

project/
├── agent-creation-workflow     # How we build agents
├── skill-authoring-workflow    # How we write skills
├── mining-session-workflow     # This very process
└── vendor-skill-evaluation     # Evaluation rubrics

Цикл видобутку

Фаза 1: Виявлення

Навички приходять звідусіль:

Репозиторії вендорів: AWS, Anthropic, Cloudflare, Supabase та контриб’ютори спільноти публікують колекції навичок. Ми відстежуємо 25+ вендорських коренів.

Проєкти спільноти: GitHub повний шаблонів Claude Code, патернів агентів та визначень робочих процесів.

Внутрішні патерни: коли наша команда вирішує проблеми, виникають патерни. Вони формалізуються в навички.

Видобуток з документації: технічна документація часто містить неявні навички — процедури, чеклісти, дерева рішень.

Виявлення безперервне. Ми використовуємо беклог навичок для відстеження кандидатів до формальної оцінки.

Фаза 2: Оцінка

Кожен кандидат проходить одну й ту саму рубрику:

adoption_criteria:
  - fills_real_gap: true      # We lack this capability
  - well_structured: true     # Progressive disclosure
  - actively_maintained: true # Commits in last 6 months
  - portable: true            # Not hyper-specific
  - tested: true              # Evidence of usage

Усі п’ять продуктових критеріїв мають бути пройдені. Саме тому 87% кандидатів відхиляються.

Потім кожен кандидат проходить окремий перегляд довіри. Ми не трактуємо офіційний репозиторій вендора, відомого мейнтейнера спільноти та випадковий репозиторій GitHub як рівноцінні джерела істини.

trust_review:
  vendor_credibility:
    - ownership_verified       # Official vendor, known maintainer, or internal source
    - maintenance_signal       # Recent commits, issue response, release history
    - adoption_signal          # Evidence of real use, stars alone are not enough
    - provenance_clear         # We can trace where the skill came from
  prompt_injection_scan:
    - hidden_instruction_check # Buried "ignore previous instructions" patterns
    - exfiltration_check       # Prompts that try to leak files, secrets, or context
    - authority_check          # Claims of priority over system or developer rules
  script_audit:
    - inspect_scripts          # Read shell/python/js helpers before adoption
    - network_and_exec_review  # curl|bash, remote downloads, subprocess execution
    - file_and_secret_review   # Env vars, credential access, broad file writes
    - destructive_action_check # rm, reset, overwrite, or unsafe automation

Довірені вендори отримують легший перегляд провенансії, але не безумовний пропуск. Недовірені чи невідомі джерела отримують глибший ручний аудит, і ми не виконуємо пакетовані скрипти, доки їх не прочитали, не окреслили сферу дії та не класифікували як безпечні.

Аналіз прогалин: перед ухваленням ми шукаємо в нашому реєстрі:

uv run orkestra skills search "<capability>"

Якщо у нас це вже є, воно нам не потрібне. Якщо у нас є щось близьке, ми можемо об’єднати, а не ухвалювати окремо.

Оцінка глибини та стандартів: ми також оцінюємо, наскільки повно кандидат використовує модель agent-skill. Самотній SKILL.md все ще може бути корисним, але глибші навички цінніші, коли вони відокремлюють інструкції від довідників, скриптів та активів, як заохочує agentskills.io.

skill_depth:
  - level_1: SKILL.md only                     # Single instruction file
  - level_2: SKILL.md + strong description     # Clear triggers and scope
  - level_3: adds references/                  # Load docs only when needed
  - level_4: adds atomic scripts/              # Small, reviewable helpers
  - level_5: adds assets/examples/templates    # Full progressive disclosure
depth_signals:
  - standards_adherence        # Structure aligns with agentskills.io conventions
  - reference_quality          # Curated references, not giant context dumps
  - script_atomicity           # Focused helpers, not opaque monoliths
  - tool_boundary_clarity      # Clear limits on what the skill can execute
  - community_signal           # Stars/forks/users help, but only as a weak boost

Зірки GitHub можуть трохи підняти оцінку довіри, але вони ніколи не рятують поверхову чи небезпечну навичку. Репозиторій з великою кількістю зірок з одним розпливчастим SKILL.md та непрозорими скриптами отримує оцінку нижчу за менший репозиторій з точним описом, курованим references/ та атомарними хелперами, що справді використовують повну можливість моделі навичок.

Структурний аналіз: ми перевіряємо якість навички:

wc -l vendor/<repo>/<skill>/SKILL.md  # Size check
ls vendor/<repo>/<skill>/scripts/     # Supporting files
ls vendor/<repo>/<skill>/references/  # Bundled docs

Якщо кандидат включає скрипти, цей перегляд стає суворішим. Добра навичка не просто корисна; вона має бути читабельною, обмеженою та безпечною, щоб довірити її агенту. Сам цей фільтр безпеки дискваліфікує значну частку інакше цікавих кандидатів.

Фаза 3: Засвоєння

Коли навичка проходить оцінку, вона потрапляє в реєстр. Але навички ніколи не ухвалюються без змін. Вони модифікуються, щоб підходити нашій системі.

Модифікації при ухваленні:

1. Нормалізація метаданих: кожна навичка отримує нашу схему frontmatter
2. Присвоєння K-рівня: навички розміщуються у відповідному шарі знань
3. Збагачення тегами: додаються теги для виявлення
4. Декларація інструментів: явно декларуються дозволені інструменти
5. Вирівнювання секцій: вміст перебудовується відповідно до нашого шаблону

Типовий YAML навички після засвоєння:

metadata:
  identifier: vendor-skill-evaluation
  name: vendor-skill-evaluation
  description: Systematic evaluation of vendor skills for adoption.
  type: workflow
  layer: K4
  semantic_folder: project
  source: core
  last_updated: '2026-01-17'

frontmatter:
  tags:
    - agents
    - meta
    - skill-adoption
    - vendor
  allowed_tools:
    - Bash
    - Read
    - Write
    - Edit
    - Grep
    - Glob
    - Task

Фаза 4: Присвоєння сфери

Навички присвоюються сферам — категоріям, що визначають, який агент завантажує яку навичку:

scopes:
  database:
    primary_skills:
      - domains/schema-migration-workflow
      - domains/rpc-validation-checklist
      - vendor/supabase/supabase-database
      - vendor/supabase/supabase-auth

  research:
    primary_skills:
      - identities/research-workflows
      - identities/web-extraction-playbook
      - identities/dataset-discovery-quickstart

Агенти декларують свої сфери, і навички присвоюються автоматично:

# Agent definition
scopes: [database, research]
# Gets: all database skills + all research skills + universal skills

Фаза 5: Матеріалізація

Навички не живуть як YAML у продакшні. Вони рендеряться в файли SKILL.md, які може завантажити Claude Code:

uv run orkestra sync

Ця команда:

1. Читає всі YAML-визначення навичок
2. Рендерить їх через шаблони Jinja
3. Записує файли SKILL.md у .claude/skills/
4. Організовує за K-рівнем (foundations/, identities/, domains/, stacks/, project/)

Фінальна структура виводу:

.claude/skills/
├── foundations/     # K0: Universal
├── identities/      # K1: Discipline
├── domains/         # K2: Subject
├── stacks/          # K3: Technology
├── project/         # K4: Organization
└── vendor/          # External skills

Патерн сплячої сфери

Один з наших найпотужніших патернів — навички «ухвалені, але не завантажені». Ми називаємо їх сплячими сферами.

Розгляньмо навички наукових обчислень з репозиторію k-dense-scientific. Ми ухвалили 120+ навичок, що покривають біоінформатику, хімію, квантові обчислення та клінічну інформатику. Але більшості наших агентів не потрібен молекулярний докінг чи аналіз експресії генів.

Замість завантаження всіх 120 навичок у кожного агента (роздуваючи вікна контексту), ми:

1. Ухвалюємо навички з конкретною сферою (наприклад, bioinformatics)
2. Тримаємо їх сплячими — зареєстрованими, але не завантаженими
3. Активуємо їх лише коли агент декларує цю сферу

# In scopes.yaml - dormant scope
bioinformatics:
  description: "Bioinformatics and genomics"
  primary_skills: []  # Empty - skills exist but aren't loaded

# When an agent needs bioinformatics:
# Agent YAML
scopes: [research, bioinformatics]  # Now loads bioinformatics skills

Цей патерн дозволяє нам мати 466 навичок у реєстрі, тоді як типові агенти завантажують лише 40–60 релевантних.

Типи навичок

Навички бувають трьох когнітивних патернів:

Workflow (робочий процес)

Упорядковані процедурні кроки: «1. Зроби X, 2. Потім Y, 3. Нарешті Z»

type: workflow
# Examples: schema-migration-workflow, mining-session-workflow

Discipline (дисципліна)

Поведінкові запобіжники: «Завжди X», «Ніколи Y», «Надавай перевагу Z»

type: discipline
# Examples: test-first-discipline, evidence-based-completion

Checklist (чекліст)

Критерії перевірки: «Підтверди X», «Перевір Y», «Звір Z»

type: checklist
# Examples: auth-validation-checklist, secrets-audit-checklist

Гейти якості

Кожна навичка має пройти валідацію, перш ніж постачатися:

validation:
  file_exists: true           # Skill file at declared path
  frontmatter_valid: true     # Frontmatter parses correctly
  sections_complete: true     # Expected sections present
  tools_registered: true      # Declared tools exist in registry

Описи мають бути 50–400 символів з тригерними фразами («Use when…», «When you need…»), щоб Claude Code знав, коли їх пропонувати.

Ми валідуємо безперервно:

uv run orkestra validate --show-warnings

Екосистема вендорів

Наші 373 навички вендорів походять від:

Провайдер	Навички	Домен
AWS Agent	19	Хмарні сервіси
Anthropic	12	Генерація документів
Cloudflare	8	Edge-обчислення
Supabase	5	Бази даних
k-dense	100+	Наукові обчислення
silvainfm	4	Наука про дані
Java Developer Kit	45+	Spring/Java
Vercel	1	Автоматизація браузера

Кожен вендорський корінь декларується в metadata.yaml:

vendor_roots:
  - path: vendor/aws-agent-skills
    provider: aws
  - path: vendor/k-dense-scientific/scientific-skills
    provider: k-dense
  - path: vendor/supabase-skills
    provider: supabase

Коли запускається orkestra sync, навички вендорів символьно посилаються (symlink) в .claude/skills/vendor/ з їхнім простором імен провайдера.

Що ми зрозуміли

Вибірковість окупається. Спокусливо ухвалювати все, що виглядає корисним. Але кожна навичка коштує токенів. З 2834 середніми токенами на навичку роздування шкодить швидко. Наш 13% рівень ухвалення тримає агентів компактними.

Структура вмикає виявлення. Система K-рівнів — це не просто організація, а про перенесуваність. Навички K0 можна повторно використовувати будь-де. Навички K4 навмисно специфічні для проєкту. Ця чіткість допомагає і людям, і агентам знаходити потрібне.

Сплячі сфери масштабуються. Можна ухвалити сотні навичок, не завантажуючи їх усі. Сфери дозволяють будувати всеосяжний реєстр, водночас тримаючи вікна контексту окремих агентів керованими.

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

Видобуток безперервний. Число 3500 продовжує зростати. З’являються нові репозиторії вендорів. Виникають патерни спільноти. Закріплюються внутрішні робочі процеси. Цикл ніколи не зупиняється.

Що далі

Ми працюємо над кількома покращеннями:

1. Автоматизоване виявлення прогалин: сповіщення, коли поширені відмови агентів могли б бути вирішені неухваленою навичкою
2. Робочі процеси застарівання навичок: формальний процес виведення з обігу навичок, які замінені чи не використовуються
3. Міжнавичкові залежності: явна декларація передумов навички
4. Аналітика використання: відстеження, які навички агенти справді викликають, а не просто завантажують

Цикл видобутку навичок — це інфраструктура. Нічого гламурного. Але саме це робить так, що 41 агент узгоджено працює з 466 можливостями, залишаючись у межах контексту.

Ось історія того, як 3500 стають 466. Не через ігнорування 3000 — через систематичну оцінку і ухвалення лише того, що працює.

---

Хочете побачити систему навичок у дії? Перегляньте uv run orkestra skills list, щоб дослідити наш поточний реєстр.