Скилл, который создаёт скиллы: Skill Creator V2

Как Skill Creator V2 стал мета-скиллом для превращения экспертной работы в переиспользуемые возможности агента.

Краткие тезисы

Хороший skill — это не просто prompt. Это повторяемый рабочий процесс с доказательствами, тестами, границами и понятной моделью ошибок.
Skill Creator V2 сначала классифицирует человеческую работу, которую мы хотим превратить в skill, и только потом пишет сам skill.
Главная архитектурная идея — многоосевая таксономия: действие, домен, инструментальная поверхность, риск, доказательства и форма workflow.
Поэтому это зрелее, чем обычные шаблоны в стиле "сгенерируй мне SKILL.md".
Публичный репозиторий: sergekostenchuk/skill-creator-v2.
Отдельное исследование: Глубокая таксономия классов скиллов для Skill Creator V2.

Есть момент, когда полезного трюка уже недостаточно.

Сначала agent skill кажется простой вещью. Ты пишешь SKILL.md, объясняешь, когда его использовать, добавляешь инструкции, иногда кладёшь рядом scripts или references — и агент становится заметно лучше в конкретном типе работы. Это действительно работает. Skill может научить агента настраивать роутер, проверять SEO, работать с Figma, анализировать юридические документы или собирать видео.

Но когда таких скиллов становится много, появляется другая проблема. Сложность уже не в том, чтобы написать ещё один файл с инструкцией. Сложность в том, чтобы понять, каким должен быть этот skill: какие у него границы, какие риски, какие доказательства результата, какие тесты, когда нужен человек, а когда агент может действовать сам.

Так появился Skill Creator V2.

Я стал называть его "отцом скиллов". Полушутя, но по сути точно. Это не потому, что он должен быть магическим. Наоборот: его задача — убрать магию из создания скиллов. Skill должен быть инженерным артефактом, а не просто красивым prompt.

Почему недостаточно "просто сгенерировать skill"

Самый простой путь выглядит соблазнительно:

> "Вот домен. Напиши мне skill."

LLM умеет так делать. Она может выдать аккуратный SKILL.md, придумать workflow, добавить слова про best practices и создать ощущение готового продукта.

Проблема в том, что аккуратный текст ещё не означает зрелый skill.

Он может срабатывать слишком широко. Может использовать не те инструменты. Может не требовать проверки результата. Может предлагать менять production-инфраструктуру без rollback-плана. Может относиться к юридическим выводам как к обычному копирайтингу. Может назвать screenshot доказательством, но не объяснить, что именно он доказывает. Может создать script, который никто не проверил. Такой skill может помочь один раз, но быть опасным как повторяемая возможность.

Поэтому Skill Creator V2 начинает не с написания. Он начинает с классификации.

Перед генерацией skill он спрашивает: какую человеческую работу мы пытаемся зафиксировать?

Это исследование? Анализ? Настройка? Публикация? Мониторинг? Юридическая защита? Визуальный дизайн? Browser automation? Knowledge management? Или это meta-skill, который сам создаёт другие skills?

Ответ важен, потому что разные виды работы требуют разных доказательств.

Skill — это workflow, а не ярлык

Один из самых сильных исследовательских вкладов пришёл из KIMI taxonomy pass, который разобран в отдельной заметке «Глубокая таксономия классов скиллов для Skill Creator V2». Главная мысль там простая:

плоская классификация скиллов ломается.

Если пытаться классифицировать skill одним ярлыком, очень быстро смешиваются вещи, которые должны быть разделены. Например:

Figma — это не класс скилла. Это инструментальная поверхность.
Browser обычно тоже не класс. Это инструмент, если только сама работа не заключается в управлении браузером.
Security не всегда домен. Часто это риск, тип проверки или требование к hardening в другом домене.
Legal — это не просто "написать текст". Юридическая защита включает сроки, цитаты, юрисдикцию, доказательства и human approval.
Infrastructure слишком широкая категория, если внутри неё спрятать VPS, VPN, DNS/SSL, роутеры и deployment.

Исследование KIMI предложило многоосевую модель. Именно она стала центром архитектуры Skill Creator V2.

Вместо вопроса "к какому классу относится этот skill?" система формирует classification packet:

activity type: что делает агент;
domain: в какой профессиональной области происходит работа;
tool surface: через какие инструменты или интерфейсы идёт действие;
risk profile: что может пойти не так и насколько это дорого;
evidence profile: чем доказывается, что результат корректен;
workflow shape: это один проход, pipeline, reviewer loop или orchestrator-worker система.

Это меняет всю архитектуру.

Skill для WireGuard — это не просто "инфраструктура". Это работа с приватной сетью, терминалом, SSH, конфигами, production/security риском. Ему нужны tunnel status, routing evidence, leak checks, config diff и rollback notes.

Skill для Figma canvas — это не просто "дизайн". Он работает с конкретной инструментальной поверхностью. Ему нужны node IDs, before/after screenshots, evidence выбранного frame и ограничения области изменений.

Юридический defense skill — это не просто "написать документ". Ему нужны факты отдельно от предположений, датированные источники, юрисдикция, процессуальные сроки и human decision gate.

Такой же подход работает по всей библиотеке.

Почему это зрелее обычного prompt-шаблона

Prompt templates полезны. Они экономят время. Они задают модели голос, структуру и базовое поведение.

Skill Creator V2 идёт дальше. Он пытается создавать не красивые ответы, а повторяемые способности, которые выдерживают многоразовое использование.

Для этого нужно несколько слоёв.

Первый слой — границы skill. Хороший skill должен ясно говорить, что он делает и чего не делает. Это не даёт агенту превращать любую задачу в один огромный процесс.

Второй слой — evidence contract. Доказательство — это не просто лог, картинка или утверждение. Нужно понимать, что собрано, почему это важно, где лежит артефакт, как он проверяется и что нужно очистить перед публикацией.

Третий слой — risk-derived gates. Human review не должен быть декоративной галочкой. Он должен появляться потому, что задача юридически чувствительная, публичная, destructive, security-related или связана с production-инфраструктурой.

Четвёртый слой — evals и regression checks. Если skill претендует на production-ready, его нужно как-то проверять. Не каждый skill можно идеально измерить, но у серьёзного skill должны быть negative cases, edge cases и sanity checks.

Пятый слой — skill groups. Некоторые workflow нельзя честно упаковать в один огромный skill. Если этапы требуют разных ролей, разных инструментов или независимого reviewer, правильная архитектура — orchestrator и worker skills с понятными handoff contracts.

"Отец скиллов" на самом деле ещё и reviewer

По названию кажется, что это generator. На практике Skill Creator V2 должен быть ещё и reviewer.

Он должен смотреть на предложенный skill и задавать неудобные вопросы:

Не срабатывает ли skill слишком широко?
Не занижен ли риск?
Доказательства обязательны или просто упомянуты?
Проверены ли scripts?
В правильном ли месте агент просит пользователя подтвердить действие?
Не пытается ли skill заменить целый отдел вместо одной переиспользуемой способности?
Не должен ли это быть skill group вместо одного skill?
Не называем ли мы работу завершённой без доказательств?

Это важно, потому что агенты отлично генерируют уверенно выглядящие артефакты. Задача зрелой системы скиллов — замедлить этот процесс там, где цена ошибки высокая.

Цель не в бюрократии. Цель — управляемая автономность.

Низкорисковые skills должны оставаться быстрыми. Маленькому внутреннему помощнику для черновиков не нужен тяжёлый governance pipeline. Но skill для production deployment, роутера, юридической защиты или meta-skill, который создаёт другие skills, требует более строгих gates.

Главный принцип простой: чем выше риск, тем сильнее должны быть доказательства.

Как развивалась работа

Проект не начался как чистая теория.

Он вырос из практической боли. Я создавал всё больше skills: для SEO и LLM discoverability, UI/UX, инфраструктуры, browser operations, юридического анализа, media generation и поддержки Obsidian-подобной базы знаний.

Каждый новый skill поднимал одни и те же вопросы:

Что должно быть в SKILL.md?
Что лучше вынести в references?
Что должно стать deterministic script logic?
Как это тестировать?
Когда нужно спрашивать разрешение у пользователя?
Когда задача слишком широкая для одного skill?
Как не выдать фейковую уверенность за готовность?

Параллельно я использовал task plans, чтобы держать работу наблюдаемой. Это оказалось принципиально. Без task plan модель легко уходит в сторону, повторяется или объявляет работу завершённой слишком рано. С task plan решения, gates, открытые вопросы и статус done становятся видимыми.

Skill Creator V2 стал meta-версией этого подхода. Он задаёт один и тот же вопрос для каждого будущего skill:

что должно быть правдой, прежде чем этому можно доверять?

Чем он отличается от аналогов

Большинство генераторов скиллов фокусируются на результате:

> "Вот ваш skill."

Skill Creator V2 фокусируется на системе вокруг результата:

classification до генерации;
risk до разрешений;
evidence до статуса done;
evals до заявлений о зрелости;
reviewer gates до release;
packaging и sanitation до публикации;
regression checks до будущих изменений.

Поэтому это ближе к маленькому production pipeline, чем к prompt writer.

Меняется и разговор о качестве. Вместо "этот skill хороший" система должна уметь сказать:

для какой работы он создан;
что он намеренно не делает;
какие доказательства подтверждают результат;
какие тесты были пройдены;
какие риски остались;
когда агент должен остановиться и позвать человека.

Это более честный стандарт.

Почему это важно сейчас

Agent skills становятся реальным интерфейсным слоем между универсальными моделями и конкретной работой. В них живут процедуры, инструментальные предположения, правила домена, safety boundaries и память проекта.

Это делает skills мощными. И одновременно рискованными.

Слабый skill может незаметно научить агента неправильной привычке. Слишком широкий skill может сработать не там. Отсутствие evidence rule может заставить агента считать задачу выполненной только потому, что он сгенерировал текст. Опасный script может стать supply-chain проблемой. Meta-skill, который создаёт другие skills, может размножить собственные ошибки.

Поэтому "отец скиллов" не должен быть просто большим prompt. Он должен быть дисциплинированным creator, classifier, reviewer, packager и critic.

Публичный репозиторий развивается здесь:

github.com/sergekostenchuk/skill-creator-v2

Он ещё дополняется, но архитектурное направление уже понятно: skills должны проектироваться как переиспользуемые рабочие системы, а не как файлы с инструкциями.

Что добавляет companion research

В отдельной заметке разобрано, почему система использует несколько осей вместо одного класса, почему имена инструментов не должны становиться классами, почему security часто является измерением риска, почему legal work требует high-stakes gates и почему skill groups нужно создавать только там, где есть реальная граница по evidence, роли или ответственности.

Если объяснить совсем коротко:

Skill Creator V2 — это попытка сделать agent skills честнее.

Не идеальными. Не магическими. Не автоматической экспертизой.

Просто более зрелыми.

Он заставляет каждый раз спросить:

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

Именно такой skill creator мне был нужен.

Не фабрика prompt-ов.

А skill, который ответственно создаёт skills.