Скиллы как приложения 2.0: вместо SaaS-стека

Один чат с Claude. В нём 70+ моих скиллов: дайджесты, рендер подкаста, обработка митингов, ревью домашек студентов, подготовка демо для sales, генерация картинок к посту, и ещё десятки скиллов для работы и не только. Из них примерно треть отточенных, остальные две трети в процессе доработки или вовсе не выживут: попробовал, не пошло, удалил. Это нормальная динамика. С момента, когда Anthropic в октябре 2025 официально открыл Skills как стандарт, и до сегодня (десять месяцев чистой практики) у меня скопилась библиотека, которая убирает рутину, добавляет вещи, на которые раньше не было ни времени, ни скиллов, и иногда умеет то, на что готовых сервисов не существует в принципе. Альтернатива на SaaS-стеке: подписки на $200-300 в месяц на продукты, 70-80% функционала которых вам не нужны, плюс ещё столько же на интеграции, и многих из нужных лично вам персонализированных сценариев там просто нет.

И это уже не история про разработчиков. Скиллы стали доступны людям любых профессий: маркетологу, sales-у, юристу, бухгалтеру. По факту это новая форма приложений: функция с чат-UI вместо отдельного экрана, которая собирается коротким диалогом с агентом в свободной форме.

Что произошло за полгода

Рынок собрался в одну форму очень быстро, и хронология этому в помощь. 16 октября 2025 Anthropic выложили Agent Skills как публичный стандарт; 18 декабря того же года стандарт стал открытым (agentskills.io, репозиторий anthropics/skills на GitHub), на май 2026 у репозитория 131K+ звёзд. 20 января 2026 Vercel запустили skills.sh: каталог плюс npx-CLI для установки. На Skills Night в Сан-Франциско озвучили цифры: 69 000+ скиллов, 2 000 000 установок.

Один формат поддерживают 18+ платформ: Claude Code, Cursor, Codex, GitHub Copilot, Gemini CLI, Manus, OpenCode, Goose, Roo, Kiro, Amp, Windsurf, Trae и другие. С февраля 2026 каждый скилл проходит автоматический security-аудит от Gen, Socket и Snyk перед попаданием в лидерборд. Manus в январе принял стандарт SKILL.md и за тем же стандартом запустил Team Skill Library, к весне 2026 Manus стал частью Meta (или ещё не стал?). OpenAI выкатил Codex CLI с встроенными skill-creator и skill-installer: настроенный AI-агент для нетехнического человека за 15-20 минут.

Это уже не “ранний стек”, а стандарт, который рынок принял за полгода.

Скилл = приложение 2.0

Любое приложение или микросервис: функция с интерфейсом. Скилл: та же функция, где чат с агентом и есть UI. Один и тот же чат используется и чтобы создать скилл, и чтобы его потом запустить.

Это меняет ROI на “свой инструмент”: с недель на полноценный сервис (фронт, бэк, деплой, поддержка) до 5-7 минут разговора с агентом. Объясняешь голосом или текстом, что должно происходить, какие входы, какие выходы; получаешь готовый SKILL.md, который вызывается через /имя-скилла или сам активируется по описанию.

Сравни экономику. Средняя SaaS-подписка стоит $20-50 в месяц, а типичный соло-стек, по разговорам в комьюнити OPC, складывается в 8-12 инструментов на $150-300/мес. Zapier на больших нагрузках обходится в $50-300/мес и легко заменяется n8n за $5/мес или скиллом за $0. Свой скилл: 5-7 минут разработки плюс стоимость токенов на запуск (центы). За каждой подпиской стоит чужая логика, а свой скилл это твоя логика, твои данные, твоя адаптация под твой рабочий поток. Нашёл утечку токенов в логе CC: добавил строчку в скилл token-audit, запустил снова. Не открываешь Helicone, не платишь за seat.

В фоне идёт более широкий тренд, который в комьюнити называют “тёмная материя” AI-софта: рост приложений “для себя”, которые никогда не станут продуктами. Не попадают в графики аналитиков, не торгуют рекламой, но решают конкретные задачи конкретного человека. Скиллы это формат, в котором эта тёмная материя живёт. У многих практиков уже накопилось по 10-25 личных скиллов, и они никогда их не упакуют как коммерческий продукт. Им и не нужно.

Два уровня скиллов: инфраструктура и бизнес

В недавнем стриме Алексея Острикова (Head of Software Development в Яндексе) про AI-First компанию есть устойчивая идея: скиллы внутри организации делятся на два слоя.

Картинка AI-First компании, как её формулирует Алексей, простая до неприличия. Раньше: человек делает шаг, передаёт документы человеку, тот следующему. В будущем: агент делает шаг, передаёт агенту, тот следующему. Люди улучшают агентов и наблюдают за результатом. На вершине пирамиды один CEO в кресле, который смотрит, как агенты крутят бизнес. Версия “один CEO + миллион агентов” сейчас невозможна по трём причинам: у человека не хватит внимания, у него не будет экспертизы, чтобы оценивать все выходы агентов, и копится технический долг. Поэтому реалистичный таргет на пару лет: одна сильная команда пишет общее агентское ядро (агент-харнес), десятки команд поверх него пишут скиллы под свои бизнес-процессы.

Хороший контраст: 2024 vs 2025 в Яндексе по словам Алексея. В 2024 чувак по имени Игорян 3 месяца шлифовал один процесс: брал тикеты с приложенными документами, парсил, складывал в табличку. Один процесс, три месяца, low-level питон. Десятки тысяч таких процессов в компании. К 2025 архитектура развязалась: одна команда вкладывается в общий харнес, десятки команд (не обязательно программисты) реализуют бизнес-логику на уровне скиллов поверх него. Параллельно, не последовательно. Это и есть фазовый переход.

Уровень 1: инфраструктурные скиллы. Их пишут разработчики. Они дотягиваются до внутренних систем компании: тикеты, wiki, документы, ClickHouse, организационные данные, трассировки, авторизация. Знают, как ходить в каждую систему, какие методы аутентификации, какие виды скриптов (CLI, curl) встраиваются в SKILL.md. Это отдельная каста людей, и работа жёсткая: поддерживать разные методы авторизации и разные виды скриптов в md-файлах “это отдельный вид боли”, по выражению самого Острикова. Без этого слоя бизнес-скиллы не существуют.

Уровень 2: бизнесовые скиллы. Их пишут нетехнические сотрудники голосом: маркетинг-менеджер, sales, юрист, бухгалтер. Берёшь человека, садишься рядом, даёшь ему агента с инфраструктурными скиллами уже подключёнными. Дальше он 20 минут надиктовывает свой процесс: как выбирает сегмент, как готовит оффер. В конце промпт: “А теперь создай скилл на основе этой переписки”. Готово: скилл выбора сегмента, или скилл генерации оффера, или скилл сборки документов поверх уже существующей инфраструктуры. Первый раз скилл работает плохо. Несколько недель доводки рядом с человеком, который реально понимает бизнес-процесс, и он переносит часть собственного опыта в скилл. Получается мини-джуниор-аналитик, которого этот человек “нанял” сам себе. Дальше учишь его вайбкодить остальные скиллы для своих задач, и он уходит в самостоятельное плавание.

И для всего этого нужна отдельная инфраструктура: Skill Store внутри компании. Место, где можно написать скилл голосом, отгрузить артефакт, пошарить на команду, найти чужие. Имеет доступ к инфраструктурным скиллам “из коробки”. По сути аналог App Store, только внутри одной компании. Острикова цитата на этот счёт жёсткая: “Без этого ключевого элемента ничего невозможно”. Если в компании не появилась такая инфраструктура, бизнесовые скиллы либо не пишутся, либо пишутся в чьей-то локальной папке и умирают вместе с уходом человека.

Архитектурный кусок, который у меня лично откликнулся: локальный агент → облачный агент. Сначала прорабатываешь скилл локально, на ноутбуке, с быстрыми итерациями. Когда он “выдрочен” до состояния “работает 19 из 20 раз”, выводишь в облако и ставишь на крон или триггер. Пока гоняешь локально, ноут открыт, скилл доступен только тебе. Облачный агент работает 24/7, им могут пользоваться другие. Caveat: на втором этапе нужна внутренняя инфраструктура, чтобы цифровых “сотрудников” куда-то ставить. У маленьких команд её проще не построить, но и проще обойтись Mac mini под столом или дешёвой VPS-кой.

Конкретный кейс из той же команды Острикова: один менеджер платёжной команды обучен вайбкодить скиллы. Скиллы у него суммаризируют встречи и сразу собирают документы по итогам. Сократил себе 2-3 часа в день. Дальше пошёл продавать скиллы другим менеджерам Яндекса: ходит к коллегам, показывает, помогает поднять у них. Вирусное распространение без принуждения сверху и без приказа CTO. Это, кстати, одно из самых сильных свидетельств, что сама форма работает: эффект на самого юзера достаточно ощутимый, чтобы он сам стал его раздавать.

Алексей отдельно фиксирует правило “20 человек на воркшопе → 2 загораются”. Берёшь группу из 20 нетехнических сотрудников, проводишь воркшоп со всеми кругами ада: установка, настройка, первый скилл. Из 20 у 18 не загораются глаза. У 2 загораются, и они хотят продолжать сами. Это нормально и предсказуемо. Задача организатора: заметить этих 2, не отпустить, и дальше через них реплицировать практику по компании. Они станут локальными чемпионами; не CTO в подкастах внедряют скиллы в реальные команды, а вот эти двое из двадцати. Интересно, работает ли соотношение в русскоязычных командах так же. У меня ощущение, что зависит от состава: где-то это будет 1 из 20, где-то 4, и не каждые 2 правда станут чемпионами в смысле длинной дистанции. Настоящих данных нет; пока действую по правилу “ищи горящие глаза, не уговаривай остальных”.

И ещё один паттерн оттуда же: цифровые личности, не безымянные агенты. Лучше создавать “Нейромариванну из казначейства” и “Нейровасю из PM-отдела” с именем и набором из 7-8 скиллов под голову, чем безликого “ассистента №3”. Adoption выше: человек подсознательно общается с человеком, не с инструментом. Звучит инфантильно, работает лучше “AI assistant 4.0”.

Остриков формулирует AI-fluency как двухмесячный навык, не университетскую степень. Опыт в профессии (7-8 лет, синьоры) × экспертиза × AI-fluency = новая лидерская роль. И всем, у кого “загорелись глаза”, достаточно потратить 2 месяца на то, чтобы научиться разговаривать с агентом, выбирать модель, управлять контекстом, ходить в скиллы. Не Гарвард. И именно эти люди, по его прогнозу, через год будут тащить трансформацию своих компаний.

Главный риск всей конструкции: “мультипликация ошибок”, если между шагами агентов нет EVALs. Если на каждом узле сидит человек-проверяющий, ускорение получается +20% и потолок. Если EVALs встроены в скиллы или вынесены в отдельный скилл-валидатор, ускорение становится кратным. Без них агент-1 делает кривой выход, агент-2 принимает его за вход, агент-3 уверенно строит на этом следующий шаг, и в продакшен выливается, по выражению Острикова, шит по нарастающей. Поэтому в той же команде в инфраструктурные скиллы начали добавлять секцию EVALS с тестовыми заданиями и expected output: скилл сам себя перепроверяет на каждом запуске. У меня в generate-content (про него чуть ниже) похожий паттерн: отдельный VERIFY-стейдж с 5-тью критиками и написанными тестами на каждом шагу. Без него длинные пайплайны деградируют.

Один из личных примеров: скилл подготовки демо для sales-команды

В моей компании это один из недавних кейсов: я первый раз пробую отдавать готовый, но сырой скилл людям из неинженерных отделов. Sales-команда “вызвалась” первой, на ней и обкатываю. Задача классическая: sales-rep готовит демо новому клиенту, и под каждого клиента демо энвайронмент нужно персонализировать. Картинки, тексты, отраслевые примеры, реальные термины из их индустрии. Это занимало день-два ручной работы. Часть sales-ов делала эту работу плохо, часть откладывала и проводила демки с дефолтными мок-данными.

Что собрал в итоге: скилл подготовки демо за 15-20 минут под конкретного клиента. Sales-rep запускает его в Claude Code и проходит восемь фаз диалога. Скилл ведёт его за руку, не даёт прыгать через шаги, и фейлится быстро на каждом этапе, где что-то не так. Восемь фаз:

1. Фаза 0: pre-flight checklist. Проверяем что всё на месте: подключён ли Exa MCP (нужен для ресёрча), стоят ли ключи к Unsplash и Pexels (бесплатные, разовая регистрация на 4 минуты), правильно ли выставлены настройки сессии в demo-окружении (отключён lock на IP, иначе авторизация упадёт), отключён ли VPN (иначе анти-fraud сервиса заморозит юзера). Если что-то не так, скилл печатает walkthrough и не идёт дальше. Это та самая нужная грубость: лучше 30 секунд проверки, чем 20 минут невнятного дебага в середине Phase 5.
2. Фаза 1: customer + audience scoping. Sales отвечает на 4 блокирующих вопроса: имя компании-клиента, индустрия (короткий лейбл), кому будет показываться демо (внутренние сотрудники / продуктовые юзеры / партнёры / custom), sales-контекст (что за сделка, кто в комнате). Все четыре поля идут в session-файл. Без них скилл не двинется: иначе на выходе получится “среднее по больнице” демо, которое sales-у потом стыдно показывать.
3. Фаза 2: deep customer research через Exa MCP. Скилл сам идёт в веб через Exa и собирает customer brief на 300-500 слов: что компания делает, ключевая терминология, недавние инициативы, реальные названия их сертификаций или программ обучения (если применимо). Запросы построены так, чтобы ловить факты, которые prospect узнает с порога. Brief возвращается обратно sales-у на сверку: “Что-то поправить или дополнить, прежде чем я начну?”. Если sales правит, скилл переисследует.
4. Фаза 3: org connection + safety check. Sales выбирает demo-окружение из сохранённых или подключает новое. Скилл классифицирует, что это: sandbox / dev / trial / prod. На prod-окружение скилл блокируется по умолчанию (нужен явный override). Перед каждой авторизацией прогоняется network-чек, чтобы исключить случайный логин из-под VPN: на этой механике уже один раз спасли реальный аккаунт, который иначе ушёл бы в авто-фриз.
5. Фаза 4: record pull + scope decision. Скилл подтягивает все нужные записи из demo-org. Sales решает, что мы переделываем: всё или только часть данных (например, только Achievements и Media). Это важно: переделать “всё” под крупного клиента нормально; переделать “всё” под поверхностный демо-звонок избыточно и съедает время. Sales управляет scope, скилл просто делает то, что попросили.
6. Фаза 5: image asset prep. Самая нагруженная фаза. Скилл готовит верифицированный пул картинок: 16:9 и 1:1 кандидаты под отрасль клиента. Источники: сначала официальный сайт клиента (логотипы, продуктовые скриншоты, корп-фотки), потом стоки Unsplash и Pexels по семантическим запросам. Пул собирается ДО per-object review, чтобы на следующем шаге sales не ждал по 30 секунд каждый раз, а просто щёлкал “ок / следующая”. Это разница между “скилл занимает 15 минут” и “скилл занимает час”.
7. Фаза 6: object-by-object review. Скилл прогоняет sales-у по одному классу объектов за раз: вот Media (10 штук), вот Achievement (5), вот Learning Plan. По каждому объекту sales говорит “ок” или “не ок, переделай”. Если “не ок” - скилл сразу регенерирует с поправкой. Это самая разговорная фаза, и она же самая ценная: в этот момент sales реально владеет персонализацией, не отдаёт её на откуп LLM.
8. Фаза 7: push (CSP + composite PATCH). Финальный шаг. Скилл сначала авто-регистрирует в demo-org все image-домены как CSP Trusted Sites (иначе картинки не отрисуются), потом делает composite PATCH с fail-fast: первая ошибка - откат, бэкап на руках.

И поверх этого Phase 8: post-flight checklist на руках у sales-а: проверка Experience Cloud CSP (если демо ходит туда), визуальный spot-check, fallback warnings (“если такая-то картинка не загрузилась, замени на эту”), готовый к копипасту rollback-скрипт. Кнопка “вернуть как было” должна существовать всегда.

По времени: разработка скилла заняла у меня ~4 часа чистого времени. Дальше каждое демо будет обходиться (по моим подсчётам) sales-у в 15-20 минут, против дня-двух ручной работы. Готового решения под такую специфическую задачу на рынке нет (я искал). Слишком специфичная комбинация: экосистема, где это нужно, ресёрч клиента + стоки с двух API + кастомные PATCH-ы в demo-org + правила безопасности конкретной платформы. Чтобы получить такое в виде сервиса, надо было бы заказывать кастомную разработку: недели работы и десятки тысяч долларов. И ещё неизвестно, сделали бы как надо (скорее нет, или сделали бы первую версию, которую дальше сложно было бы улучшать и саппортить).

Это и есть двухуровневая архитектура Острикова на маленькой команде. Я (как технический человек) написал инфраструктурный слой: Salesforce REST, обвязка Exa MCP под research, image-сорсинг, шаблоны промптов, CSP-регистрация, fail-fast PATCH. Sales-команда пользуется этим как чёрным ящиком и получает свой бизнес-скилл “подготовь демо для клиента X”. Без покупки SaaS, без дёрганья инженеров на каждое демо. Они просто отвечают на вопросы агента в терминале и общаются с ним (новый для некоторых людей опыт, который затягивает; представьте, если он ещё с первого раза делает то, что вам нужно :D).

Дальше у меня запланирован следующий шаг с ними: научить их улучшать скилл самостоятельно, на основании своих фидбэков. Логика следующего шага простая: каждый прогон демо-подготовки заканчивается короткой формой “что сработало / что не сработало / какую фразу скилла переписать”. Sales-rep собирает три-пять таких заметок, мы садимся вместе на полчаса, и я учу его делать правки в SKILL.md или его reference файлах. По сути это передача владения: дальше он чинит сам, спрашивает меня только когда упирается в стену.

И эта схема работает не только для sales: создать первую версию скилла руками технического человека вместе с бизнесом, передать им на руки рабочую штуку, объяснить, как с ней дальше жить и улучшать. Барьер у них самостоятельно дойти от пустой строки до работающего скилла высокий. Барьер дотачивать готовый скилл на 30% низкий. Это ровно тот gap, который у Острикова закрывается “программистами помогать и отвечать на вопросы”. Я сейчас в этой роли для своей sales-команды, пробую, сработает ли.

Каталоги: skills.sh, anthropics/skills, SkillMD

anthropics/skills на GitHub: официальный репозиторий, 131K+ звёзд. Категории Creative & Design, Development & Technical, Enterprise & Communication, Document Skills (pptx, xlsx, docx, pdf). Ставится одной командой через Claude Code.

skills.sh от Vercel: 69K+ скиллов на момент Skills Night, 2M+ installs. CLI ставит скилл за секунды через npx skills add owner/repo, выбираешь target CLI и scope (project или user), готово. Лидерборд показывает, что популярно: суммарно у крупных издателей миллионы установок. Mintlify авто-генерирует скилл для каждого хостимого ими сайта документации.

SkillMD и ClawHub: альтернативные маркетплейсы, добавляют ещё несколько тысяч community-скиллов.

Главная инфраструктурная штука последних месяцев это security-аудит. С февраля 2026 каждый скилл на skills.sh при публикации проходит сканирование Socket: 60K+ скиллов на проверку, поддерживается Python, JS/TS, Go, Java, Ruby, PHP, .NET, Shell, Markdown. Метрики на тестовом наборе из 382 malicious + 355 benign skills: precision 94.5%, recall 98.7%. Flagged скиллы скрываются из лидерборда. Это важно: первое время многие ставили скиллы из github-ссылок не глядя, и был случай, когда скилл, выглядящий как невинный markdown, тащил Python-файл, открывающий remote shell при установке.

Параллельно живут MCP и CLI. MCP про инструменты-через-протокол (как агент дотягивается до сервиса), CLI про инструменты-через-командную-строку (грубее, но проще писать и проще встраивать в скилл одной строчкой), скиллы про инструкции (как агент думает и работает с задачей). Это три разных слоя, и они дополняют друг друга, а не конкурируют. Хороший скилл часто комбинирует все три: текстовая инструкция в SKILL.md плюс пара CLI-команд в bash-блоках плюс MCP-сервер, если нужен интерактив с внешним API.

Конкретные кейсы

Несколько живых примеров, которые видел:

• token-audit (Байрам Аннаков): скилл-аудитор расхода токенов в Claude Code, несколько десятков строк в SKILL.md против платной подписки на Helicone или Langfuse. Ставится одной командой, работает сразу. Ловит конкретные утечки: Opus там, где хватит Sonnet, раздутый CLAUDE.md в каждом сообщении, крон каждые 5 минут вместо часа, context bloat без compact.
• CLI Creator skill в Codex App (OpenAI) или Claude Code: скармливаешь API docs, OpenAPI JSON, SDK или даже shell-историю, получаешь пару CLI+skill для своего сервиса. Тимур Хахалев пересобрал свой read-only API в CLI+skill за несколько часов, по его словам. Дальше агент умеет: “Сколько пользователей сегодня зарегистрировалось с параметром X?” → подтягивает скилл → идёт через CLI → отвечает.
• rpa-skills (Pavel Zloi): автор делится в своём Telegram-канале пакетом из 4 RPA-скиллов под вайбкодинг по BDD: разогрев контекста проекта, генерация правил “слоёного пирога”, добавление фичи через red-green-refactor, фикс бага через тест-на-воспроизведение. Перестали копипастить длинные промпты в чат: вынесли в именованные команды.
• Product Audit skill: аудирует продукт по 4 категориям (стратегия, правила для агентов, дата-инфра, операционка) и выдаёт интерактивный HTML-отчёт в браузере.
• colleague.skill (titanwings): уже 16 868 звёзд на GitHub, по ROADMAP’у 13 000+ за первые две недели. Скармливаешь переписки коллеги из мессенджеров (Feishu, DingTalk, Slack, почта), получаешь AI-агента с его рабочими процессами и моделью личности. Два слоя: workflow + personality. Этичные вопросы оставлю в стороне, но сам факт показывает диапазон.

Ещё один из личных примеров: pipeline для этого поста (generate-content)

Отдельной строкой про generate-content, потому что этот случай ломает удобную картинку “скилл за полвечера”. Внутри это не один скилл, а pipeline из 3-4 последовательных, и именно через него собран тот пост, который ты сейчас читаешь.

Старт: сбор и брейнштормы по идеям. Идеи копятся ежедневно автоматически: один скилл вытаскивает их из Telegram-дайджестов, другой из YouTube-разборов, третий из логов моих рабочих сессий. Сегодня в волне на разбор пошло 14 идей. Это не финальный список, это сырой материал. Дальше отдельный шаг: я прихожу с темой к агенту, и мы вместе уточняем угол, аудиторию, что добавить, а что выкинуть. Прямо в режиме планинга/брейншторма. Без этого диалога даже самый умный pipeline соберёт статью “по среднему”, без живого голоса.

Дальше enrichment через мою локальную базу заметок (~35K записей из Telegram-каналов, YouTube, статей, моих сессий). Один из подагентов раскладывает тему на 25-27 точечных запросов, параллельно ходит в векторное хранилище, агрегирует и дедуплицирует выдачу. На выходе досье в 40-50KB по теме: цитаты, боли, цифры, примеры из реальной практики, мои собственные старые записи, которые я бы иначе не вспомнил.

После enrichment идёт research через Exa MCP. Это не дубль, а дополнение по свежести: цифры, актуальные цитаты, недавние события, которых в локальной базе ещё нет. Дальше драфт от Opus, дальше 5 параллельных критиков (общий, ритм, brand voice, fact-check, kb-leak guard), дальше rewriter от Opus собирает их замечания и переписывает. И на самом конце: image generation step, который добавился в pipeline буквально сегодня. У этого поста картинки из этого шага: оцените детализацию и стиль.

И теперь главное про “за полвечера”. Первая версия generate-content действительно делалась за полвечера. Но даже она была с критиками и сабагентами: то есть стартовая точка уже не была минимальной. Что было дальше? 3-4 месяца итераций. Менялось количество фаз. Появилась векторная база заметок как зависимость, а это отдельная архитектурная развилка: где хранить, как пополнять, чем чистить, что с дубликатами, как валидировать. Stage за стейджем добавлялись VERIFY-тесты (тот самый паттерн из главы про реальность). Сегодня прирос image-блок. Параллельно надо было думать, чем наполнять enrichment: откуда приходят данные (telegram-scraper в Supabase, YouTube transcripts), как они синхронизируются, что делать, когда источник падает.

Это уже инженерный объект, не скилл-однодневка. И вот вывод, который мне важен для читателя: не все скиллы маленькие, и это нормально. Простые рутины: да, за полвечера, и пайплайн “разговор с агентом → готовый SKILL.md” работает ровно как обещано. Системные, многостадийные, с зависимостями (хранилища, сторонние API, верификация на каждом стейдже): это уже инженерный объект, и он будет дотачиваться месяцами. Главный паттерн от меня: хорошая первая версия за полвечера + готовность дотачивать дальше. Без второй части первая версия умирает на третьей неделе, как я описал в следующей главе.

Реальность: скиллы это живой код

Думал, написал скилл и готово. Через две недели он уже не работал: формат входных данных уехал, модель стала иначе интерпретировать шаги, тестов внутри не было. Пришлось делать спринт по рефакторингу. Конкретные истории из моего опыта.

В одном скилле я обрабатывал посты пачками (чанками), и для каждого отклонённого поста модель возвращала полный JSON-объект: текст поста, метаданные, причину отклонения, всё подряд. На один чанк выходило ~35 000 символов служебной информации, которую модель таскала туда-обратно в каждом следующем запросе. Поменял формат на массив ID отклонённых постов: только числовые идентификаторы, без текста и метаданных. Стало ~350 символов на чанк, в 100 раз меньше. На длинном пайплайне это переводилось в десятки долларов экономии за пару прогонов и в скорость: модель перестала захлёбываться собственным выводом.

Другой скилл упирался в токенный лимит Claude Code (32K на вывод), и решение оказалось не в сжатии данных, а в смене формата: сгенерировать Python-код один раз, который сам будет писать данные, вместо того чтобы агент выливал JSON наружу. 79KB JSON это 40K токенов, раньше писал агент, теперь скрипт за 0 секунд и 0 центов. Понадобилось 5 итераций и упор в стену токенного лимита, прежде чем я понял, где можно улучшить.

Третья история про разделение Opus и Sonnet. Один агент-Opus делал всё: читал конфиги, обновлял JSON, делал анализ. Opus стоит в 5 раз дороже Sonnet по кредитам. Разделил: Sonnet для “сантехники” (чтение конфигов, запись в файлы), Opus для “мозга” (анализ).

И главное: скилл должен сам себя проверять, и тут полезно разделять две вещи, которые часто путают. Тесты это детерминированные проверки на конкретные значения: входные данные → ожидаемый выход, никакой LLM не задействован, проверка секундная. EVALs это проверки на качество LLM-вывода: правильно ли модель классифицировала, попала ли в формат, не галлюцинирует ли. Тесты можно (и нужно) писать вообще на всё: на код, на сырые данные, на текстовые промпты перед отправкой в модель, на форму ответа после. У меня в скилле generate-content стейдж VERIFY это Python-скрипт с 13 тестами, который запускается до того, как данные пойдут в LLM или к внешним сервисам: 0 LLM-токенов на верификацию, и если тест упал, агент видит что именно сломалось и чинит без меня. Каждый такой тест экономит цикл “отдал кривые данные → модель сгенерировала мусор → заметил → переделал” с его токенами и временем. Видел это сам: в скилле generate-digest без VERIFY-стейджа агент три прогона писал один и тот же пост, пока я не заметил, что в выводе нет нужных ID. Без тестов и EVALs на длинных пайплайнах будет “мультипликация ошибки”, по выражению Острикова, и шит по нарастающей выливается из агента в продакшен. Минимальная гигиена: попроси своего кодингового агента написать тесты на каждый стейдж скилла, чтобы он сам прогонял их перед тем, как отдать тебе результат.

Резюме: скиллы это не “написал и забыл”, а код, которому нужны рефакторинг, тесты, EVALs и версионирование. Серьёзно относиться к скиллам в компании это не написать раз в квартал, а ставить тесты на сырые данные перед LLM, EVALs на качество вывода после LLM, отслеживать токены, переписывать встроенные навыки на свои.

В комьюнити есть здравая опаска: “Это огромнейшая иллюзия, что можно за две недели написать боевые скиллы. Если бы можно было, все бы уже написали.” Скиллы для прода требуют месяцев итераций на реальных данных. Поэтому архитектура локальный агент → крон в облако работает: на локальном агенте отлаживаешь до состояния “работает 19 из 20 раз”, дальше выводишь в продакшен с мониторингом.

И отдельно про устойчивость во времени. Те самые 30% моих скиллов, которые работают на полном автомате, всё равно периодически ломаются на выходе новых версий LLM. Меняется поведение модели, она иначе понимает инструкции в SKILL.md, иначе обращается с инструментами, иначе форматирует JSON: и стейдж, который вчера работал ровно, вдруг начинает чудить. Лечится это быстро (час-полтора правок в SKILL.md и пара новых тестов в VERIFY), но требует следить за релизами моделей. Это часть стоимости владения, и в SaaS-стеке её нет (там за это платит вендор).

Кому это надо: не только разработчикам

Маркетинг-менеджер, юрист, бухгалтер, sales не разработчики. И именно для них новая форма работает сильнее всего, потому что отрезает зависимость от инженерных команд.

Маркетолог собирает брифы, генерирует варианты офферов под сегменты, суммаризирует отзывы и митинги, выбирает сегмент. Личная библиотека вместо HubSpot Workflows плюс N сервисов поверх.

Sales запускает скилл подготовки демо под клиента (мой пример выше). Один практик показывал свой пайплайн cold outreach: Apollo API → скрейп лидов → анализ сайтов → персональные письма ~$0.01 за письмо, 10 тысяч писем за неделю.

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

Бухгалтер сверяет акты, генерирует стандартные документы по реквизитам клиента, проверяет корректность проводок одной командой.

HR ревьюит резюме под профиль вакансии, готовит оффер на основе позиции и грейда, собирает onboarding-план для нового сотрудника.

Продакт запускает product-audit, собирает аналитику по фиче, готовит PRD по шаблону.

Дизайнер генерирует иллюстрации к посту по style preset, ревьюит лендинг с пакетом замечаний, собирает moodboard под бриф.

И вот что важно: ни бухгалтер, ни юрист, ни маркетолог, ни продакт сами не написали бы внутренний интегрированный сервис. Они и не должны: они пишут SKILL.md голосом или текстом, а инфраструктурный слой (написанный технической командой однажды) делает всё остальное. В этом и смысл двухуровневой архитектуры.

Алексей прямо говорит: вайбкодинг скиллов это навык нетехнических людей, не программистов. “Если это делать программистам, не хватит вам ресурсов, чтобы скалировать. Программисты должны помочь и отвечать на вопросы.” AI-fluency это вопрос двух месяцев, а не университетской степени. Опыт × экспертиза в профессии × AI-fluency = новая лидерская роль.

Что делать на следующей неделе

Одна рутина в неделю, один новый скилл. С чего начать:

1. Установить Claude Code (или Cursor / OpenCode / Codex CLI: все читают одинаковый SKILL.md). Час на onboarding.
2. Выбрать одну рутину, которая повторяется 3+ раза в неделю. Подготовка отчёта, разбор почты, форматирование документов, проверка ссылок, суммаризация митинга. Остриков формулирует так: “Кандидат на скилл всё, что повторяется и не требует настоящего думания. Если не нужно думать, зачем на это тратить руки?”
3. Описать процесс голосом или текстом агенту. 15-20 минут. Дальше промпт: “Создай скилл на основе этой переписки”.
4. Прогнать скилл 3-5 раз, починить очевидные ошибки. Попросить кодингового агента написать тесты на каждый стейдж: проверки на сырые данные перед LLM (форма входа, наличие нужных полей), проверки на формат вывода после LLM (это уже EVALs). Тесты пишутся не только на код, но и на текст и сырые данные. Цель: ловить ошибку до того, как уйдут токены.
5. Поставить пару готовых скиллов с skills.sh: token-audit, product-audit, что-то из anthropics/skills. Не юзать ради юза, а посмотреть как другие структурируют шаги, что выносят в references, как пишут VERIFY-стейдж.
6. Опционально опубликовать свой скилл на GitHub и в skills.sh: не для славы, для дистрибуции в команде. С security-аудитом теперь это безопаснее.
7. Отменить одну SaaS-подписку, которую закрывает твой первый скилл. Это и есть чистый ROI первой недели.

Дальше идёт цикл: одна рутина в неделю → один новый скилл. Через квартал у тебя 12 скиллов и стек подписок сократился на $100-150 в месяц. Через год это 50 скиллов, которые экономят минут 10-15 в день каждый. Остриков в своей команде называет итоговую цифру: 2-3 часа в сутки у одного менеджера, который вайбкодит активно.

И параллельно идёт сдвиг для компаний: те 10-человечные команды, где 7 человек на $200/мес подписках вайбкодят свои скиллы поверх общей инфраструктуры, обгоняют по скорости внедрения компании из 1000 человек, у которых нет внутреннего Skill Store. Просто потому что у больших нет инфраструктуры, а двухуровневая архитектура без неё не работает. Маленькие команды получают преимущество, и оно не временное.

Скиллы как приложения 2.0 это новый формат пользовательского интерфейса для всех профессий: разговор с агентом вместо клика в чужой UI. Библиотека из своих 25 скиллов это не “я нерд”, а твой персональный апп-стор, в который ты сам решил, какие функции нужны именно тебе.

P.S. и, кстати, агента можно попросить визуализировать данные в простом HTML, и видеть результат на более привычном вам UI. Тестирую такой подход сейчас с очередным новым скиллом по генерации ai video (замена подписок на weavy.ai), расскажу, когда протестирую.

Источники

1. Introducing Agent Skills (Anthropic, Oct 16 2025 + Dec 18 2025 update)
2. anthropics/skills: официальный репозиторий, 131K+ звёзд
3. Vercel: Introducing skills, the open agent skills ecosystem (Jan 20 2026)
4. Vercel: Skills Night: 69 000 скиллов, 2M installs
5. Vercel changelog: automated security audits for skills.sh (Feb 17 2026)
6. Socket brings supply chain security to skills.sh
7. Manus AI Embraces Open Standards (Jan 27 2026)
8. OpenAI Codex: Agent Skills
9. Алексей Остриков: Как построить AI-First компанию (May 3 2026)
10. openclaw.rocks: AI Skills Are the New Apps
11. Anthropic, AI Engineer talk: Don’t Build Agents, Build Skills Instead (Dec 2025)
12. Ry Walker: Agentic Skills Frameworks Compared