Майнинг скиллов: от 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) — категориям, определяющим, какие агенты загружают какие скиллы:

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

Паттерн спящей области применения

Один из наших самых мощных паттернов — скиллы «принято, но не загружено». Мы называем их спящими областями применения (dormant scopes).

Рассмотрим скиллы научных вычислений из репозитория 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 символов с триггерными фразами («Используйте, когда…», «Когда вам нужно…»), чтобы Claude Code знал, когда их предлагать.

Мы валидируем непрерывно:

uv run orkestra validate --show-warnings

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

Наши 373 вендорских скилла происходят из:

Провайдер	Скиллов	Домен
AWS Agent	19	Облачные сервисы
Anthropic	12	Генерация документов
Cloudflare	8	Edge-вычисления
Supabase	5	База данных
k-dense	100+	Научные вычисления
silvainfm	4	Data science
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, вендорские скиллы симлинкуются в .claude/skills/vendor/ с пространством имён своего провайдера.

Чему мы научились

Избирательность окупается. Соблазнительно принять всё, что выглядит полезным. Но каждый скилл стоит токенов. При среднем значении 2834 токена на скилл раздувание быстро бьёт по производительности. Наш показатель принятия в 13% удерживает агентов компактными.

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

Спящие области применения масштабируются. Вы можете принять сотни скиллов, не загружая их все. Области применения позволяют строить исчерпывающий реестр, сохраняя окна контекста отдельных агентов управляемыми.

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

Майнинг непрерывен. Число 3500 продолжает расти. Появляются новые вендорские репозитории. Возникают паттерны сообщества. Укрепляются внутренние рабочие процессы. Цикл никогда не останавливается.

Что дальше

Мы работаем над несколькими улучшениями:

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

Цикл майнинга скиллов — это инфраструктура. Не эффектная. Но именно она делает возможной слаженную работу 41 агента с 466 возможностями в рамках ограничений контекста.

Вот история того, как 3500 становится 466. Не игнорированием 3000 — систематической оценкой всех и принятием только того, что работает.

---

Хотите увидеть систему скиллов в действии? Загляните в uv run orkestra skills list, чтобы изучить наш текущий реестр.