Библиотека из 200 отдельных навыков быстро превращается в мусорный контейнер, если у компании нет правил, какие из них обязательны, кто ими владеет и когда они обновлялись в последний раз. Как пишет The New Stack, именно так и выглядит новая операционная головная боль вокруг skills ИИ-агентов: они рождаются на ноутбуках разработчиков, а потом незаметно становятся частью корпоративного контура.
В основу заметки лег кейс, который 27 апреля 2026 года описал Зохар Эйни, сооснователь Port. Наблюдение было почти бытовым: инженеры в компании пользовались одинаково свежими моделями, но разными локальными skill-файлами. Кто-то написал свои инструкции, кто-то утащил старую версию, кто-то поставил шаблоны, найденные в сети. Проблема оказалась не в качестве LLM, а в том, что сами инструкции жили как локальный конфиг IDE, то есть вне инвентаризации, ревью и нормального жизненного цикла. В такой схеме компания не понимает даже базового: какие правила агент реально читает, по каким стандартам он пишет код и откуда взялись его представления о безопасности, triage и доступе к данным.
Речь не о мистических суперспособностях. В этом контексте skill — это, по сути, markdown-файл с описанием процедуры: как оформлять PR, как реагировать на prompt injection, как вести incident triage, как устроены внутренние кодстайлы и чеклисты. Такие файлы предлагают хранить в Git и связывать с командами, сервисами и ролями, потому что они меняются часто и обычно оказываются важнее, чем кажется на этапе локального эксперимента. Источниками для новых навыков становятся не только красивые демо, но и куда более приземленные вещи: комментарии в code review, ADR, постмортемы, онбординг-доки и повторяющиеся замечания, которые все уже устали печатать вручную.
Отдельный неприятный вывод: просто собрать папку со знаниями недостаточно. В примере из статьи библиотека из 200 файлов оказалась почти бесполезной без группировки. Поэтому навыки предложено делить на обязательные и опциональные. В обязательный слой входят security-правила, coding conventions и правила управления самими skill-файлами: где они лежат, как именуются и как версионируются. Опциональные подключаются по контексту: frontend-командам — инструкции по React-компонентам и Web Vitals, платформенным инженерам — triage инцидентов с привязкой к деплоям и affected services, data-командам — свои рабочие сценарии. Иначе компания получает не базу знаний для агентов, а бесконечный маркетплейс локальных привычек.
Дальше начинается то, что знакомо любому platform engineer: дистрибуция и контроль обновлений. Инженер не должен вручную копировать файлы между ноутбуком, IDE и вики. В описанном подходе он запускает одну команду, CLI подтягивает обязательные группы автоматически, а затем предлагает выбрать опциональные наборы под роль или проект. Файлы попадают прямо в конфиг IDE, например в каталог вроде .cursor/. Когда skill меняется, автоматизация разносит новую версию дальше без шаманства с чатами и сообщениями в духе «обновитесь, пожалуйста». Автор кейса отдельно подчеркивает, что саму такую библиотеку один platform engineer может собрать за несколько часов. Для DevEx это мелочь. Для управляемости — граница между пилотом и production.
Самая интересная часть здесь не раздача, а обратная связь. В кейсе есть даже meta-skill, который замечает повторяющиеся коррекции: если человек дважды за сессию исправил агента на одном и том же месте, система предлагает сразу оформить это как новый навык. Параллельно работает уже нормальная observability: дашборд показывает, кто и когда инициализировал библиотеку, какие группы подключил, когда последний раз синхронизировался. Если кто-то живет на полугодовой версии файла или вообще не запускал инициализацию, это видно. Если skill не трогали 90 дней, его помечают как потенциально устаревший. Отдельно отслеживаются повторяющиеся комментарии к AI-сгенерированным PR: если одно и то же замечание всплывает снова и снова, оно превращается в кандидата на новый skill.
Для бизнеса здесь важен сдвиг акцента. Корпоративный риск теперь сидит не только в модели, токенах или доступе к API, но и в слое инструкций, который размазан по рабочим станциям. Именно поэтому главный тезис публикации звучит жестко: нереалистично ждать, что один администратор будет понимать, как должен оптимально работать каждый skill в компании. Когда у вас десятки команд, сотни сервисов и разные IDE, skills ИИ-агентов быстро превращаются в новую форму shadow IT. А вместе с ними — prompt-файлы, MCP-серверы, локальные плагины и самодельные агенты, которые уже что-то знают о вашей инфраструктуре, но формально нигде не числятся.
Для русскоязычных команд это хороший холодный душ. Пока многие обсуждают, какой ассистент лучше пишет код, более приземленный вопрос звучит полезнее: кто владеет инструкциями, по которым этот ассистент вообще работает. Похоже, следующая зрелость в AI tooling будет измеряться не количеством купленных лицензий, а тем, умеет ли компания версионировать, распространять, отзывать и проверять свои skills ИИ-агентов так же строго, как Terraform-модули или CI-шаблоны. Кто поймет это раньше, получит ускорение. Кто нет, просто унаследует локальный бардак в масштабе enterprise.