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

Canonical source: https://maguyva.ai/uk/blog/skill-mining-3500-and-counting

License: text under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/); code samples under [MIT-0](https://opensource.org/license/mit-0); the Maguyva name, logos, brand assets and other code are not covered. Details: [maguyva.ai/license](https://maguyva.ai/license).

Date: 2026-01-27 · Author: Maguyva Team

> Ми перевірили 3500 кандидатів на навички й відібрали 466. Систематичний цикл видобутку та засвоєння для побудови узгодженої бібліотеки навичок ШІ-агентів у масштабі.

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

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

Коли ми почали будувати систему оркестрації агентів, ми зіткнулися з цікавим викликом: у ШІ-екосистемі розкидані тисячі потенційних навичок. Репозиторії 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: Оцінка

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

```yaml
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 як рівноцінні джерела істини.

```yaml
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
```

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

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

```bash
uv run orkestra skills search "<capability>"
```

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

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

```yaml
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/` та атомарними хелперами, що справді використовують повну можливість моделі навичок.

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

```bash
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 навички після засвоєння:

```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: Присвоєння сфери

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

```yaml
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
```

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

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

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

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

```bash
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. **Активуємо** їх лише коли агент декларує цю сферу

```yaml
# 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»

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

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

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

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

### Checklist (чекліст)

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

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

## Перевірки якості

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

```yaml
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 знав, коли їх пропонувати.

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

```bash
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:

```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`, щоб дослідити наш поточний реєстр.*