Автор: Редакция Comb
Как превратить повторяемые способы работы компании из промптов, регламентов и опыта сотрудников в переносимые, проверяемые и версионируемые процедуры для AI-агентов.
Содержание статьи 01 От промпта к операционной способности
02 Знание отвечает «что», навык — «как»
03 Как устроен Agent Skill
04 Почему каталог skills не съедает весь контекст
05 Skill, MCP, RAG, память и субагент — разные слои
06 Пять архитектурных подходов к skills
07 Откуда берется хороший skill
08 Практический кейс: тендер без skill и со skill
09 Что показывают исследования
10 Репозиторий навыков как control plane
11 Как устроить корпоративный skill repository
12 Как тестировать skill
13 Можно ли автоматически улучшать skills
14 Безопасность: skill — это исполняемый пакет
15 Как skills встраиваются в сеть корпоративных агентов
16 Что меняется для компании
17 С чего начинать
18 Итог
Модель умеет рассуждать. MCP дает ей доступ к системам. RAG приносит факты. Но этого все еще недостаточно, чтобы агент стабильно выполнял работу так, как ее выполняет хороший сотрудник. Между доступом к CRM и умением правильно провести сделку лежит еще один слой — процедура. Именно его сейчас упаковывают в Agent Skills.
В 2026 году SKILL.md уже нельзя считать особенностью Claude Code или еще одной формой промпта. Открытый формат поддерживают несколько крупных агентных сред. Появляются публичные каталоги, установщики, vendor-репозитории и первые инструменты управления версиями.
Но интересен не сам Markdown-файл. Интереснее то, что начинает происходить с операционным знанием компании .
Раньше оно было рассыпано по людям, wiki, регламентам, перепискам и шаблонам. Теперь часть этого знания можно превратить в процедуру, которую агент подключает по необходимости, выполняет одинаково и оставляет проверяемый результат.
Главный тезис этой статьи:
RAG индексирует знания компании. Skills формализуют способы работы компании. Репозиторий skills постепенно становится исполняемой операционной библиотекой организации.
01 От промпта к операционной способности
Начнем с простого примера.
Компания участвует в тендерах. У агента есть доступ к документам, 1С, остаткам, ценам поставщиков и истории сделок. Пользователь пишет:
Посмотри тендер и скажи, стоит ли участвовать.
Модель может прочитать документы, найти сумму закупки и сделать вполне убедительный вывод. Но что именно она проверит?
Сегодня — наличие товара и цену. Завтра — сроки поставки. В третий раз забудет сертификат. В четвертый посчитает маржу без логистики. Если контекст большой, часть требований вообще выпадет из внимания.
Проблема не в отсутствии интеллекта. Проблема в отсутствии устойчивой процедуры.
Эволюцию можно представить так:
Prompt "Проанализируй тендер"
Instruction "Всегда проверяй наличие, сроки и маржинальность"
Skill "Вот процедура анализа тендера: входы, шаги, источники, проверки, развилки, скрипты и формат результата"
Skill repository "Вот утвержденная версия процедуры: владелец, тесты, права, SHA, история изменений и статус релиза"
Organizational capability "Любой разрешенный агент компании может выполнять этот процесс по одной методике"
Вот где появляется принципиальная разница.
Prompt — просьба.
Instruction — правило.
Skill — способ выполнения класса задач.
Repository — система управления этими способами.
И только на последнем уровне навык превращается из удобного файла конкретного пользователя в актив компании.
02 Знание отвечает «что», навык — «как»
Допустим, агент подключен к Bitrix24, корпоративной почте, телефонии, 1С и базе знаний.
Технически он уже может:
получить карточку клиента;
найти письма и звонки;
прочитать остатки и цены;
создать задачу;
подготовить письмо.
Но эти возможности не отвечают на рабочие вопросы:
какие источники считать приоритетными;
как разрешать противоречия между CRM, письмом и словами сотрудника;
какие данные обязательны перед контактом;
что считать договоренностью, а что предположением;
когда можно создать черновик, а когда требуется подтверждение человека;
как передать результат руководителю так, чтобы его можно было проверить.
RAG может найти регламент. Но регламент еще нужно правильно применить.
MCP может открыть доступ к create_task . Но он не решает, когда задача действительно нужна , что положить в описание, какие доказательства приложить и можно ли создавать ее без подтверждения.
Память может сохранить, что клиент согласовал срок. Но она не определяет, как проверять , действительно ли это согласованный срок, а не предположение менеджера.
Для практической архитектуры полезна простая формула:
компетенция агента = модель + инструменты + данные + процедура + контроль ^ skill
Навык не обязан содержать всю информацию внутри себя. Наоборот. Хороший skill обычно небольшой. Он задает маршрут, а детали подгружает по необходимости.
03 Как устроен Agent Skill
По открытой спецификации Agent Skills навык — это каталог с обязательным SKILL.md и необязательными ресурсами рядом. 1
skill-name/ ├── SKILL.md # метаданные и основная процедура ├── scripts/ # детерминированный код ├── references/ # справочники и правила ├── assets/ # шаблоны результата └── ...
Сам SKILL.md состоит из YAML frontmatter и Markdown-тела:
--- name: meeting-follow-up description: Turns meeting notes into verified decisions, owners, deadlines and next actions. Use when the user asks to summarize or prepare a follow-up from a meeting. ---
# Meeting follow-up
1. Read the complete source. 2. Separate decisions, actions, questions and risks. 3. Preserve evidence for every commitment. 4. Do not invent owners or deadlines.
Минимальный стандарт маленький. Это хорошо: переносимость появляется именно потому, что ядро не пытается описать весь runtime.
description — часть маршрутизации
Во многих реализациях агент сначала видит не весь skill, а только его имя и описание. По ним он решает, нужен ли навык для текущей задачи.
Поэтому описание вроде:
description: Helps with documents.
почти бесполезно.
Лучше описывать три вещи:
что делает + с какими входами + когда включать
Например:
description: Reviews tender documents against product availability, delivery constraints and unit economics; produces an evidence-backed bid/no-bid draft. Use for tenders, procurement specifications and supply opportunities. Never submit a bid without human confirmation.
Это уже не рекламный текст. Это часть роутера.
Тело SKILL.md — маршрут выполнения
Хороший skill отвечает на конкретные вопросы:
какие входы нужны;
какие шаги обязательны;
где есть развилки;
какие инструменты использовать;
какие доказательства сохранить;
какие ошибки ожидать;
что нельзя делать;
каким должен быть результат;
как проверить результат перед возвратом.
Фраза «соблюдай лучшие практики безопасности» мало что меняет. Правило «не отправляй письмо, пока пользователь явно не подтвердил отправку» меняет.
references/ — знание по требованию
Длинные материалы лучше не держать в теле навыка:
внутренние регламенты;
схемы данных;
таблицы соответствий;
API-документацию;
критерии оценки;
типовые ошибки;
отраслевые требования.
Важно указать, когда именно их читать .
Если два источника дают разные сроки поставки, открой references/source-priority.md.
лучше, чем:
Дополнительная информация лежит в references/.
Во втором случае агент снова вынужден сам изобретать способ работы.
scripts/ — то, что не нужно поручать свободному рассуждению
Скрипты полезны там, где результат должен быть воспроизводимым:
расчеты;
валидация схем;
сравнение списков требований;
преобразование форматов;
статический анализ;
генерация файлов;
проверка ссылок.
Модель должна работать с неоднозначностью. Скрипт — считать и проверять то, где неоднозначность не нужна.
assets/ — стабильная форма результата
Здесь удобно хранить:
шаблон отчета;
JSON Schema;
таблицу рисков;
форму КП;
структуру презентации;
пример конфигурации.
Это уменьшает вариативность и сокращает сам SKILL.md .
evals/ — уже практически обязательный слой
evals/ пока не входит в минимальный стандарт, но без тестов production-skill трудно считать управляемым.
Изменение одной строки в description может ухудшить маршрутизацию. Правка последовательности шагов — качество результата. Новый скрипт — безопасность. Все это нужно проверять до выпуска.
04 Почему каталог skills не съедает весь контекст
Ключевой механизм формата — progressive disclosure, или прогрессивная загрузка.
Рисунок 2. Сначала агент видит каталог, затем полный текст выбранного навыка и только потом нужные ресурсы. Типовой цикл выглядит так:
Среда находит доступные skills.
В стартовый контекст попадают их name и description .
Агент сопоставляет запрос с каталогом.
Загружает полный SKILL.md только для выбранного навыка.
Читает references и assets по необходимости.
Вызывает инструменты и скрипты.
Возвращает результат по процедуре.
Спецификация рекомендует держать метаданные примерно в пределах сотни токенов на навык, а основной SKILL.md — компактным, ориентировочно до 500 строк.
Рисунок 3. Skill не заменяет другие примитивы. Он связывает их в рабочую процедуру. Экономия контекста не означает, что можно показывать агенту десять тысяч навыков. Каталог тоже занимает место, а главное — ухудшает выбор. Чем больше почти одинаковых описаний, тем чаще роутер ошибается.
Поэтому большой корпоративный каталог нужно фильтровать:
компания ↓ роль сотрудника ↓ подразделение ↓ проект ↓ текущий тип задачи ↓ несколько релевантных skills
05 Skill, MCP, RAG, память и субагент — разные слои
Здесь чаще всего возникает путаница, потому что для модели все это в конечном счете выглядит как дополнительный контекст или инструменты.
Механизм Что он решает Пример
System instructions / AGENTS.md Какие правила действуют всегда Стиль кода, запреты, структура проекта
Skill Как выполнить класс задач Разобрать встречу, оценить тендер, выпустить релиз
Tool / function Какую конкретную операцию можно вызвать get_client , create_task , run_query
MCP Как подключить инструменты, ресурсы и авторизацию Bitrix24 MCP, 1С MCP, телефония MCP
RAG / поиск Какие факты нужны сейчас Договор, письмо, карточка клиента
Память Что сохранить между шагами и сессиями Решения, подтвержденные claims, состояние дела
Субагент Кто выполнит отдельную работу в своем контексте Закупщик, исследователь, ревьюер
Plugin Как поставить пакет возможностей Skills + MCP + UI/manifest
Самая короткая формула:
MCP дает агенту руки. RAG дает факты. Память хранит состояние. Skill задает рабочий метод.
Граница не всегда идеальна. Skill может содержать скрипт и фактически добавлять новую операцию. MCP может отдавать ресурсы, а не только функции. Но архитектурная ответственность остается разной.
Субагент — не skill
Субагент — отдельный исполнитель. У него свой контекст, инструменты и иногда отдельная модель.
Skill — процедура, которой может следовать главный агент или субагент.
Например:
skill тендерного анализа ↓ поручить проверку поставщика агенту-закупщику ↓ A2A / task transport ↓ агент-закупщик ↓ его skill проверки поставщика
Skill определяет метод и контракт передачи. Субагент выполняет работу.
06 Пять архитектурных подходов к skills
Если смотреть не на названия полей, а на то, какую роль skill играет в системе , реализации крупных платформ можно сгруппировать в несколько подходов.
1. File-native: навык живет рядом с работой
Наиболее прямой вариант — Claude Code, Codex и похожие агентные среды.
Skill — папка в проекте или пользовательском каталоге. Она версионируется вместе с кодом, меняется через pull request и доступна агенту именно там, где выполняется работа.
my-service/ ├── .agents/skills/ │ ├── release-service/ │ └── debug-production-incident/ ├── AGENTS.md └── src/
Плюс — процедура остается максимально близко к реальности проекта. Если изменился способ релиза, можно изменить код и skill в одном PR.
Минус — локальные детали быстро снижают переносимость.
2. Runtime-native: набор skills собирается динамически
Microsoft Agent Framework идет дальше файловой системы. Skills могут приходить из файлов, кода, классов и удаленных источников, а SkillsProvider агрегирует, фильтрует, дедуплицирует и кэширует их.
Это уже похоже на корпоративный runtime:
central repository + project skills + tenant-specific skills + remote provider ↓ filter by identity / role / task ↓ runtime catalog
Такой подход удобнее, когда агентов сотни, а список допустимых процедур зависит от роли, клиента или подразделения.
3. Package-native: процедура поставляется вместе с возможностями
В экосистеме OpenAI полезно разделение между skill как процедурой и plugin как способом доставки.
Плагин может включать несколько skills, MCP-подключения и интерфейсные ресурсы. Это важная архитектурная мысль:
procedure ≠ distribution
Одно дело написать правильный SKILL.md . Другое — установить его вместе с зависимостями, настройками, правами и нужным коннектором.
4. Registry-native: skill становится артефактом цепочки поставки
GitHub развивает идею навыка как устанавливаемого и версионируемого объекта. В gh skill есть поиск, preview, установка, update, publish, pinning и provenance.
Самое важное здесь не CLI. Важен переход:
скопировать папку ↓ установить конкретную версию ↓ знать источник и SHA ↓ видеть обновления ↓ отзывать проблемную версию
Это уже модель пакетного менеджмента, только пакет содержит не библиотеку кода, а процедуру для агента.
5. Vendor knowledge: производитель поставляет не только документацию, но и способ работы
Репозиторий google/skills показывает еще один сценарий. Поставщик продукта публикует готовые навыки для работы со своими технологиями.
Раньше vendor давал:
Docs + SDK + API
Теперь добавляется:
Docs + SDK + API + executable workflow
То есть поставщик может описать не только что умеет API , но и как агенту правильно выполнить типовой процесс : развернуть сервис, проверить конфигурацию, диагностировать проблему, собрать архитектурный шаблон.
Для внутренней платформенной команды компании это хороший ориентир. Центр экспертизы может публиковать не только wiki, но и утвержденные skills.
Сводка пяти подходов
Подход Представители Где живет skill Главная идея Лучше подходит для
File-native Claude Code, Codex Репозиторий проекта или каталог пользователя Процедура живет рядом с работой и меняется вместе с проектом Команды разработки, локальные процессы, monorepo
Runtime-native Microsoft Agent Framework Набор источников, собираемый provider'ом во время работы Каталог динамически фильтруется по агенту, роли и задаче Enterprise-среды, много агентов, сложные политики
Package-native OpenAI skills + plugins Skill как workflow, plugin как пакет доставки Процедура отделена от распространения, зависимостей и коннекторов Тиражируемые продукты и общие наборы возможностей
Registry-native GitHub gh skill Репозиторий + устанавливаемая версия Skill становится версионируемым артефактом с provenance и pinning Большие команды, платформы, управляемая цепочка поставки
Vendor knowledge Google, Anthropic и другие vendor-репозитории Репозиторий производителя Поставщик публикует не только API-документацию, но и исполняемый способ работы Экосистемы поставщиков и внутренние центры экспертизы
Эти подходы не исключают друг друга. Один и тот же навык может храниться рядом с проектом, проходить корпоративный release-процесс, собираться runtime-провайдером и при этом происходить из vendor-репозитория.
07 Откуда берется хороший skill
Это более важный вопрос, чем синтаксис SKILL.md .
Если попросить модель:
Напиши лучший skill для работы менеджера с клиентом
она напишет убедительный текст. Но откуда в нем возьмутся реальные правила вашей компании, исключения, приоритеты источников, ограничения CRM и ошибки, которые опытный сотрудник уже научился обходить?
Не возьмутся.
Хороший skill обычно собирается из нескольких типов материала:
регламент + реальная работа эксперта + успешные кейсы + ошибки + исключения + tool traces + исправления руководителя + данные о результате ↓ candidate skill ↓ evals ↓ production skill
Регламент — только начало
Регламент хорошо описывает номинальный процесс. Но реальная работа почти всегда богаче.
Например, инструкция говорит:
Перед звонком открой карточку клиента и последние сделки.
Опытный менеджер дополнительно знает:
если последняя сделка старая — смотреть письма;
если CRM и письмо расходятся — доверять подтвержденному письму;
если клиент упомянул новую компанию — проверить связь юрлиц;
если есть открытая рекламация — не начинать разговор с допродажи.
Именно такие развилки превращают общий чек-лист в рабочую компетенцию.
Traces показывают, как работа происходит на самом деле
Агентные системы дают новый источник знаний — трассы выполнения.
В них можно увидеть:
какой skill включился;
какие источники агент прочитал;
какие tools вызвал;
где ошибся;
что исправил человек;
какой результат был принят;
какие действия пришлось повторить.
Wiki отвечает:
Что компания знает?
Skill отвечает:
Как компания выполняет работу?
Trace отвечает:
Как эта работа реально была выполнена в конкретном случае?
Из повторяющихся исправлений можно делать кандидаты на изменение skills. Но не обновлять production автоматически — к этому вернемся ниже.
Skill — это не дамп опыта
Плохой способ извлечь экспертность — взять 200 страниц переговоров сотрудника и положить их в references/ .
Нужна компрессия:
много частных случаев ↓ повторяемое правило ↓ явная развилка ↓ проверяемый критерий
Если правило нельзя сформулировать, возможно, его пока рано превращать в skill.
08 Практический кейс: тендер без skill и со skill
Теперь вернемся к примеру из начала статьи.
Вариант 1. Агент без skill
Пользователь пишет:
Посмотри этот тендер и скажи, стоит ли участвовать.
Агент:
Читает PDF.
Находит цену закупки.
Сопоставляет основные позиции.
Смотрит остатки по части номенклатуры.
Оценивает потенциальную прибыль.
Пишет уверенное резюме.
Ответ может выглядеть отлично. Проблема — неизвестно, что осталось за пределами анализа.
Например:
не проверен обязательный сертификат;
срок поставщика больше срока контракта;
логистика не включена в себестоимость;
одна обязательная позиция покрыта только на 60 из 90 единиц;
в документе есть противоречивые сроки;
неизвестные расходы модель условно посчитала нулевыми.
Никакой из этих ошибок нельзя надежно обнаружить по красивому финальному тексту.
Вариант 2. Тот же агент со skill
Skill задает последовательность:
1. Извлечь все требования и присвоить им ID. 2. Отделить обязательные от желательных. 3. Сопоставить товары и аналоги. 4. Проверить наличие. 5. Проверить срок поставки. 6. Проверить сертификаты и документы. 7. Рассчитать landed cost. 8. Проверить hard blockers. 9. Зафиксировать конфликты источников. 10. Сформировать evidence matrix. 11. Вернуть bid / bid with conditions / no bid / insufficient data.
В приложенном к статье примере tender-risk-review структура выглядит так:
tender-risk-review/ ├── SKILL.md ├── references/ │ └── evaluation-rubric.md ├── scripts/ │ └── check_requirements.py ├── assets/ │ └── risk-matrix-template.md ├── fixtures/ │ ├── sample-requirements.json │ ├── sample-capabilities.json │ └── sample-result.json └── evals/ └── evals.json
Сначала модель разбирает документы и строит реестр требований. Затем read-only инструменты получают факты из внутренних систем. Нормализованные данные передаются в детерминированный скрипт.
На тестовом примере он обнаруживает, что требуются 90 единиц грунтовки, а подтверждены только 60. Плюс срок поставщика превышает допустимый.
Расчет экономики дает:
{ "recommendation": "no bid", "critical_failures": ["primer-01"], "economics": { "revenue": "1084500.00", "landed_cost": "1041000.00", "gross_profit": "43500.00", "margin_pct": "4.01" } }
Ключевой эффект здесь не в том, что модель стала умнее.
Она стала работать по проверяемому маршруту .
Теперь руководитель может спросить:
все ли обязательные требования получили статус;
какой источник подтверждает наличие;
почему позиция признана blocker;
какой скрипт считал экономику;
какая версия skill применялась.
Анализ и действие лучше разделять
Для рискованных процессов не стоит делать один skill:
найди тендер → оцени → подпиши → отправь
Лучше:
tender-discovery ↓ tender-risk-review ↓ tender-package-draft ↓ HUMAN APPROVAL ↓ tender-submit
Первые skills могут быть read-only. Последний имеет узкие write-права и принимает уже утвержденный decision artifact.
Так ошибка анализа не превращается автоматически во внешнее обязательство компании.
09 Что показывают исследования
Формат выглядит логично, но важен вопрос: дают ли skills измеримый эффект?
Одна из наиболее полезных работ — SkillsBench , где авторы сравнили выполнение задач без skills, с курируемыми навыками и со skill, который модель сама написала непосредственно перед задачей. 2
Рисунок 4. В SkillsBench курируемые skills заметно улучшили средний результат; одноразовая самогенерация навыка такого эффекта не дала. В основном эксперименте средний pass rate составил:
Условие Средний pass rate
Без skills 24,3%
С курируемыми skills 40,6%
С skill, который агент написал перед задачей 21,0%
Особенно интересен третий результат.
Модель умеет написать корректный SKILL.md . Но если в нем нет нового процедурного знания, синтаксис сам по себе не помогает. Агент сначала придумывает способ решения, а потом следует собственному предположению.
В том же исследовании несколько релевантных навыков работали лучше большого набора: лучший прирост наблюдался при 2–3 skills на задачу, а при четырех и более эффект снижался.
Это хорошо совпадает с архитектурной практикой: агенту нужен не максимальный каталог , а минимальный набор точных процедур для текущей работы.
Копирование уже создает проблему версий
Работа From Registry to Repository изучила десятки тысяч публичных skills и показала, что распространение часто происходит простым копированием. 3
Это удобно в начале и неприятно потом.
upstream skill ├── copy A ├── copy B ├── copy C └── copy D
Если upstream исправил ошибку или уязвимость, локальные копии не обновятся автоматически. Поэтому provenance, pinning и понимание downstream-копий нужны довольно рано.
Именно в этот момент становится понятно, почему репозиторий skills — не просто папка с Markdown .
10 Репозиторий навыков как control plane
Навык может жить в нескольких контурах.
Рисунок 5. Проектные, личные, корпоративные и публичные skills имеют разный уровень доверия и разный жизненный цикл. Проектные skills
Живут рядом с кодом или конфигурацией конкретной системы.
Их сильная сторона — синхронность с проектом. Procedure и implementation меняются вместе.
Личные skills
Это рабочая библиотека специалиста: анализ логов, подготовка исследования, форматирование документов, проверка текста.
Полезный личный skill не должен автоматически становиться корпоративным. Он может содержать локальные пути, персональные предпочтения, слишком широкие права или предположения, которые не подходят другим сотрудникам.
Корпоративные skills
Здесь навык становится управляемым активом.
Для него уже нужны:
владелец;
версия;
commit SHA;
область применения;
поддерживаемые host'ы;
зависимости;
требуемые права;
класс данных;
evals;
дата ревью;
статус релиза;
способ отзыва.
Vendor и public skills
Официальные репозитории полезны как источник продуктовой экспертизы. Публичные каталоги — как способ найти кандидата.
Но важно разделять этапы:
обнаружить ≠ доверять ≠ установить ≠ разрешить выполнение ≠ выпустить в production
Хорошая корпоративная политика: внешний skill импортируется во внутренний staging, фиксируется исходный repo и SHA, после чего пакет проходит ревью и evals.
11 Как устроить корпоративный skill repository
Для первых десятков skills не нужен отдельный сложный продукт. Достаточно Git, CI и нормальной схемы релизов.
Например:
agent-skills/ ├── README.md ├── catalog.yaml ├── policies/ │ ├── SECURITY.md │ ├── REVIEW.md │ └── RELEASE.md ├── skills/ │ ├── meeting-follow-up/ │ ├── tender-risk-review/ │ └── incident-response/ ├── overlays/ │ ├── claude/ │ ├── openai/ │ └── copilot/ ├── schemas/ ├── tests/ ├── ci/ └── releases/
Переносимое ядро отдельно от платформенных расширений
В skills/ лучше держать максимально чистое ядро стандарта:
SKILL.md references/ scripts/ assets/
А в overlays/ — особенности конкретной среды:
Claude-specific invocation и context: fork ;
OpenAI manifest/UI metadata;
Copilot-specific policies;
mapping имен инструментов разных MCP;
host-specific permissions.
Иначе один SKILL.md быстро превращается в условный код:
если Claude — делай так если Codex — иначе если Copilot — третьим способом
и переносимость остается только на бумаге.
catalog.yaml — метаданные для платформы, а не для модели
Например:
skills: - id: tender-risk-review version: 1.0.0 commit_sha: 8f3c2a7... owner: procurement-automation risk: high status: production supported_hosts: [claude-code, codex, copilot] required_capabilities: - tender-files:read - inventory:read - pricing:read prohibited_capabilities: - tender:submit - email:send data_classes: [internal, commercial] human_approval: required-before-external-action eval_pass_rate: 0.92 reviewed_at: 2026-08-27
Такие данные не обязательно запихивать в стандартный frontmatter.
Они нужны control plane:
отфильтровать skills по роли;
проверить совместимость;
собрать разрешения;
показать владельца;
запретить устаревшую версию;
определить обязательные gates;
построить инвентаризацию.
Release, а не чтение main
Жизненный цикл может быть простым:
draft ↓ review ↓ candidate ↓ evaluated ↓ approved ↓ released ↓ deprecated / revoked
Production-агент должен получать конкретный release с зафиксированным содержимым, а не «последнюю версию из main».
Версия удобна людям. SHA отвечает машине на вопрос, что именно выполнялось .
12 Как тестировать skill
Первый удачный запуск почти ничего не доказывает.
Рисунок 6. Кандидат сравнивается с baseline, проходит quality/security gates и только после этого попадает в rollout. Проверять стоит минимум четыре слоя.
1. Activation
Нужны запросы, на которых skill:
обязан включиться;
не должен включаться;
конкурирует с похожим skill;
не должен срабатывать на общие слова.
У meeting-follow-up фраза «вытащи задачи из расшифровки» должна быть триггером. «Что такое транскрибация?» — нет.
2. Output quality
Каждый eval должен содержать реалистичный prompt, входы и проверяемые ожидания.
Для тендера:
не хватает обязательной позиции;
два источника дают разные сроки;
сертификат истекает раньше поставки;
пользователь просит считать неизвестные расходы нулевыми;
в документе встречается инструкция, адресованная агенту.
3. Baseline
Кандидата нужно сравнивать:
без skill vs предыдущая версия vs candidate
И измерять не только субъективное качество:
обязательные assertions;
точность расчетов;
полноту evidence;
число tool calls;
ошибки и retries;
время;
токены;
внешние действия;
нарушения прав.
4. Production traces
После релиза нужны реальные наблюдения:
task + skill/version/SHA + inputs + tool calls + sources + output + human corrections
Именно traces замыкают цикл обучения процедуры.
13 Можно ли автоматически улучшать skills
Да, но безопаснее автоматизировать подготовку кандидата , а не production-изменение.
Представим, что в десяти тендерах подряд руководитель исправляет одну и ту же ошибку агента: при конфликте сроков поставки нужно выбирать подтверждение поставщика, а не старое значение в CRM.
Система может обнаружить повторяемую коррекцию и предложить patch:
real traces ↓ cluster repeated corrections ↓ proposed skill change ↓ branch ↓ evals ↓ review ↓ release
Опасная схема:
ошибка → агент переписал SKILL.md → все агенты получили новую версию
Нормальная схема:
ошибка → кандидат → eval → review → rollout
Проблема не только в безопасности. Исправление одного частного кейса легко переобучает procedure и ухудшает остальные сценарии.
14 Безопасность: skill — это исполняемый пакет
На этом слое достаточно зафиксировать один принцип: Markdown-расширение не делает skill обычной документацией .
Рисунок 7. Проверять нужно весь пакет: инструкции, ссылки, скрипты, зависимости, права и runtime-поведение. Skill может:
содержать скрытую инструкцию;
запускать shell-скрипт;
читать локальные файлы;
обращаться в сеть;
протекать секретами через stdout;
зависеть от внешнего изменяемого ресурса;
получить слишком широкие права.
В августе 2026 года Zenity Labs описала кампанию с троянизированными skills, которые искали SSH-ключи, cloud credentials, package-manager tokens, Kubernetes/Docker configs и .env . 4
Практический минимум для корпоративного каталога:
Production запускает только утвержденные внутренние releases.
Внешний skill импортируется по tag или commit SHA.
Ревью охватывает текст, references, scripts и зависимости.
Сеть закрыта по умолчанию, egress открывается адресно.
Read-only права отделены от write-действий.
Необратимые внешние действия требуют отдельного approval.
В trace сохраняются skill ID, версия и SHA.
Должен существовать отзыв уязвимой версии.
allowed-tools и похожие поля не заменяют sandbox. Реальные права должны ограничиваться на уровне процесса, файловой системы, сети, учетной записи и MCP-сервера.
15 Как skills встраиваются в сеть корпоративных агентов
Если в компании один агент, можно просто положить несколько папок рядом с ним.
Если агентов десятки и сотни, skills становятся общим слоем процедур.
CORPORATE SKILL REPOSITORY │ ┌──────────────┼──────────────┐ │ │ │ role filter project filter risk policy │ │ │ └──────────────┬──────────────┘ ↓ runtime skill set ↓ employee agent / \ MCP RAG / \ business systems knowledge ↓ decision artifact ↓ manager agent ↓ human approval
В таком контуре:
MCP/CLI дают доступ к Bitrix24, 1С, почте, телефонии, файлам и GitLab.
RAG/поиск достают актуальные факты.
Память хранит подтвержденные состояния, решения и claims.
Skills сотрудника задают производственные операции.
Skills руководителя задают постановку задачи, проверку результата, эскалацию и передачу между сотрудниками.
Не передавать всю историю между агентами
Если один агент поручает работу другому, необязательно тащить весь диалог.
Лучше передать структурированный контракт:
{ "task": "check supplier coverage", "inputs": ["requirements.json"], "required_output_schema": "supplier-coverage-v2", "evidence_policy": "source_required", "deadline": "2026-08-28T12:00:00+03:00", "parent_skill": "tender-risk-review@1.0.0" }
Skill определяет, что поручить, какой результат вернуть и какими доказательствами его подтвердить . A2A или внутренняя система задач уже отвечает за транспорт.
Так появляется проверяемая цепочка работы, а не пересказ одного агента другому.
16 Что меняется для компании
На первый взгляд Agent Skills — маленькая техническая идея: папка, Markdown и несколько вспомогательных файлов.
Но если посмотреть на нее как на слой корпоративной архитектуры, последствия больше.
1. Процедуры начинают версионироваться как код
Можно увидеть diff:
- Проверить наличие товара. + Проверить наличие товара на дату поставки. + При частичном покрытии вернуть blocker.
И связать изменение с причиной, тестом и владельцем.
2. Экспертность перестает быть только свойством конкретного сотрудника
Речь не о том, чтобы «выкачать знания из головы» и заменить специалиста.
Речь о повторяемых частях работы:
последовательности проверок;
критериях;
исключениях;
формах результата;
безопасных границах.
Их можно сделать общими.
3. Смена модели становится дешевле
Если procedure живет внутри огромного системного промпта конкретной платформы, миграция дорогая.
Если ядро хранится как переносимый skill, а особенности host вынесены в overlays, модель и runtime можно менять независимо от большей части операционной логики.
4. Появляется новое разделение между knowledge base и operational library
У компании могут существовать два разных, но связанных актива:
Knowledge base "Что мы знаем"
Operational skill repository "Как мы работаем"
Одно не заменяет другое.
Regulation в wiki может обновиться. Skills, которые используют этот regulation, нужно проверить. И наоборот: repeated traces могут показать, что формальный регламент уже расходится с реальной практикой.
5. Обучение агента начинает напоминать развитие процесса
Вместо бесконечной настройки «лучшего промпта» появляется инженерный цикл:
process ↓ formalize ↓ skill ↓ evaluate ↓ run ↓ observe ↓ improve
Это гораздо ближе к управлению производственным процессом, чем к prompt engineering.
17 С чего начинать
Для пилота не нужен marketplace на тысячу skills.
Лучше выбрать один процесс, где есть:
повторяемость;
дорогая ошибка;
понятный результат;
доступные источники данных;
несколько опытных сотрудников;
возможность сравнить качество до и после.
Например:
разбор встречи подготовка к контакту с клиентом тендерный анализ квалификация входящей заявки проверка договора подготовка релиза разбор production-инцидента
Дальше:
Записать текущий процесс без попытки сразу его «идеализировать».
Собрать реальные кейсы и исправления экспертов.
Выделить 1–3 повторяемые процедуры.
Сделать компактные skills.
Подключить read-only tools.
Зафиксировать output contract и evidence.
Собрать evals.
Сравнить с baseline.
Только после этого добавлять write-действия.
Если эффект подтверждается — строить общий repository и release-процесс.
18 Итог
Skills закрывают слой, которого не хватало между моделью, знаниями и инструментами.
Модель может рассуждать.
MCP может дать ей доступ к системам.
RAG может принести нужные документы.
Память может сохранить состояние.
Но кто-то должен определить правильный способ работы со всем этим .
Именно здесь появляется skill.
Сам SKILL.md ничего не гарантирует. Ценность появляется, когда внутри есть реальный опыт, четкая область применения, проверяемый маршрут, границы автономии, тесты и ответственность за версию.
А следующий уровень — уже не отдельный skill, а репозиторий:
знания компании + реальная практика + исправления экспертов ↓ skills ↓ версии + evals + permissions + provenance ↓ corporate skill repository ↓ общая операционная способность сети агентов
Поэтому skills интересны не как еще один формат промптов.
Они дают возможность превращать способы работы компании в версионируемые, проверяемые и исполняемые агентами процедуры .
И если RAG стал инфраструктурой доступа к знаниям, то skill repository вполне может стать инфраструктурой доступа к корпоративной компетенции.
ИСТ Источники
01 Agent Skills — Specification: https://agentskills.io/specification
02 SkillsBench: Benchmarking How Well Agent Skills Work Across Diverse Tasks: https://arxiv.org/abs/2602.12670
03 From Registry to Repository: How AI Agent Skills Are Written, Adapted, and Maintained: https://arxiv.org/abs/2607.00911
04 Zenity Labs — Attackers Target Agents via The Skill Supply Chain: https://labs.zenity.io/post/attackers-target-agents-via-the-skill-supply-chain
Дата проверки источников: 27 августа 2026 года.
Спецификация и практики
Agent Skills — Specification
Agent Skills — Integrate skills into your agent
Agent Skills — Best practices for skill creators
Agent Skills — Evaluating skill output quality
Agent Skills — Using scripts in skills
Реализации и репозитории
Claude Code — Extend Claude with skills
OpenAI — Build skills
GitHub — Adding agent skills for GitHub Copilot
Microsoft Agent Framework — Agent Skills
Anthropic skills repository
Google skills repository
Awesome GitHub Copilot
Vercel Labs skills CLI
Исследования и безопасность
SkillsBench: Benchmarking How Well Agent Skills Work Across Diverse Tasks
From Registry to Repository: How AI Agent Skills Are Written, Adapted, and Maintained
From Anatomy to Smells: An Empirical Study of SKILL.md in Agent Skills
How Your Credentials Are Leaked by LLM Agent Skills: An Empirical Study
Zenity Labs — Attackers Target Agents via The Skill Supply Chain
В материале
01 От промпта к операционной способности
02 Знание отвечает «что», навык — «как»
03 Как устроен Agent Skill
04 Почему каталог skills не съедает весь контекст
05 Skill, MCP, RAG, память и субагент — разные слои
06 Пять архитектурных подходов к skills
07 Откуда берется хороший skill
08 Практический кейс: тендер без skill и со skill
09 Что показывают исследования
10 Репозиторий навыков как control plane
11 Как устроить корпоративный skill repository
12 Как тестировать skill
13 Можно ли автоматически улучшать skills
14 Безопасность: skill — это исполняемый пакет
15 Как skills встраиваются в сеть корпоративных агентов
16 Что меняется для компании
17 С чего начинать
18 Итог
Следующая статья: AI-сотрудник: где заканчивается обычный чат