Почему Skill Creator V2 понадобилась более глубокая таксономия, прежде чем он сможет создавать надёжные skills.

Коротко

  • Skill нельзя честно классифицировать одним ярлыком: теряется слишком много важной информации.
  • Одно и то же действие, например research или review, встречается в инфраструктуре, праве, дизайне, SEO, browser work и meta-skill creation.
  • Названия инструментов обычно не являются классами. Это tool surfaces или tags.
  • Риск — не просто тема. Он меняет evidence, approvals, rollback и правила тестирования.
  • Поэтому Skill Creator V2 использует многоосевую модель: действие, домен, инструментальная поверхность, риск, доказательства и форма workflow.
Многоосевая таксономия

Эта заметка — очищенная публичная версия исследовательского слоя за статьёй «Скилл, который создаёт скиллы». Сырой исследовательский материал был полезен для архитектуры, но публичная версия не должна быть выгрузкой внутренних заметок. Для читателя важнее логика: зачем skill creator вообще нужна таксономия, почему плоские категории ломаются и как классификация влияет на качество создаваемых skills.

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

Самый простой способ классифицировать agent skills — сделать список:

  • SEO;
  • Figma;
  • Browser;
  • Security;
  • Legal;
  • Infrastructure;
  • Writing;
  • Research.

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

Security audit skill — это не только "security". Это ещё review, analysis, risk assessment, evidence collection и часто infrastructure work. Figma implementation skill — это не только "Figma". Это может быть design review, GUI operation, asset export, code handoff или visual QA. Legal defense skill — это не только "writing". Там есть факты, даты, юрисдикция, цитаты, сроки и human approval gates.

Один ярлык не может всё это удержать.

В итоге получается смешанная гранулярность. Название инструмента вроде Figma оказывается рядом с доменом вроде law, действием вроде research и рисковым ярлыком вроде security. После этого система уже не может надёжно решить, какие доказательства нужны, какие инструменты допустимы и где агент должен остановиться и спросить разрешение.

Шесть осей

Исследовательский проход привёл к простому архитектурному решению: не выбирать один класс, а собирать classification packet.

Skill Creator V2 использует шесть осей.

| Ось | Вопрос | Зачем нужна | | --- | --- | --- | | Activity type | Что делает агент? | Research, analyze, create, implement, review, monitor, remediate и coordinate требуют разных доказательств. | | Domain | В какой профессиональной области происходит работа? | Infrastructure, legal defense, design, discoverability, media, knowledge management, browser work и meta-skill creation имеют разные failure modes. | | Tool surface | Где происходит работа? | CLI, browser, files, API, database, GUI, version control или device interface меняют execution и evidence. | | Risk profile | Что может пойти не так? | Чем выше риск, тем сильнее checks, rollback, human approval и privacy boundaries. | | Evidence profile | Чем доказывается успех? | Logs, diffs, screenshots, tests, citations, browser traces, database rows и public URLs доказывают разные вещи. | | Workflow shape | Как организована работа? | One-pass task, pipeline, reviewer loop, orchestrator-worker system и monitoring loop требуют разной структуры skill. |

Это главный ход. Skill — это не "SEO" и не "Figma". Это набор свойств.

Примеры

Infrastructure deployment skill может выглядеть так:

  • activity: implement and verify;
  • domain: infrastructure operation;
  • tool surface: CLI, filesystem, server SSH, version control;
  • risk: production-impacting;
  • evidence: command output, config diff, service status, smoke test, rollback path;
  • workflow: plan, apply, verify, rollback-ready.

Figma-to-code skill может выглядеть так:

  • activity: inspect, translate, implement, review;
  • domain: design and visual creation;
  • tool surface: GUI/design canvas plus code;
  • risk: public UX regression;
  • evidence: node IDs, screenshots, generated files, responsive checks;
  • workflow: design read, code change, visual verification.

Legal defense skill может выглядеть так:

  • activity: analyze, draft, review, communicate;
  • domain: legal reasoning and defense;
  • tool surface: documents, citations, maybe court or agency portals;
  • risk: high-stakes human decision;
  • evidence: dated sources, jurisdiction notes, fact/assumption separation, citation trail;
  • workflow: draft with mandatory human review.

Это не декоративные различия. Они меняют то, что skill имеет право делать.

Class, subclass, tag и tool surface

Таксономии нужны правила: что становится настоящим классом, а что нет.

Domain становится class только тогда, когда у него есть отдельный workflow fingerprint: другие действия, evidence, failure modes и review gates.

Специализация становится subclass, если она наследует workflow родителя, но требует других доказательств или процедур. Например, tax defense и traffic defense могут жить внутри legal defense: они разделяют юридическое мышление и document workflow, но отличаются процедурой, форумом и доказательствами.

Ярлык становится tag, если он полезен, но не меняет workflow. VPS, VPN, DNS и router часто являются infrastructure tags. Они важны, но не должны раздувать верхний уровень таксономии.

Название инструмента становится tool surface, а не class, если один и тот же инструмент появляется во многих доменах. Browser, Figma, Terraform, Playwright, SQLite и GitHub обычно являются surfaces или tags. Они влияют на execution, но сами по себе не определяют профессиональную задачу skill.

Так таксономия не превращается в склад названий продуктов.

Почему риск должен быть отдельным

Security хорошо показывает, почему плоские ярлыки ломаются.

Иногда security — это domain: например, security audit skill действительно занимается безопасностью.

Иногда security — это risk profile: deployment skill может быть инфраструктурной задачей с security-последствиями.

Иногда security — это review requirement: изменение публичного сайта может требовать privacy и header checks, даже если страница не про security.

Поэтому security не всегда должен быть class. Часто это risk dimension, который меняет gates.

Та же логика работает для legal, financial, production, privacy и public-reputation risk. Чем выше цена ошибки, тем больше evidence должен требовать skill перед словом "done".

Что это меняет в Skill Creator V2

Эта таксономия меняет сам workflow генерации.

Перед тем как писать SKILL.md, Skill Creator V2 должен классифицировать работу.

После этого он должен вывести:

  • что skill делает;
  • что skill явно не делает;
  • какие evidence обязательны;
  • какие tools и files ожидаются;
  • какие действия требуют approval пользователя;
  • какие tests или evals нужны;
  • должен ли это быть один skill или skill group;
  • что reviewer должен оспорить перед release.

Это делает систему зрелее, чем prompt template.

Prompt template спрашивает: "Что агент должен сказать?"

Skill Creator V2 спрашивает: "Какую работу мы фиксируем, что может пойти не так и чем доказать успех?"

Почему это важно для skill groups

Некоторые работы слишком широкие для одного skill.

Если workflow включает strategy, implementation, review, testing, publication и monitoring, один огромный skill становится хрупким. Он будет срабатывать слишком широко и прятать слишком много ответственности.

Таксономия помогает разделить работу:

  • orchestrator отвечает за sequence и handoff;
  • specialist отвечает за один domain;
  • reviewer отвечает за gates и quality;
  • tester отвечает за evidence;
  • publisher отвечает за sanitation и release.

Разделять нужно только там, где есть реальная граница: разный evidence, разный risk, разный tool surface или разный approval owner. Иначе система просто создаёт бюрократию.

Практический стандарт

Практический стандарт простой:

нельзя называть skill production-ready только потому, что файл выглядит аккуратно.

Он готов только тогда, когда taxonomy, evidence, risk, tests и boundaries соответствуют работе, которую он обещает автоматизировать.

Именно поэтому Skill Creator V2 нужна глубокая таксономия.

Не ради красивой схемы.

А ради более безопасной автономности.

Ради skills, которые можно проверять, улучшать, тестировать и использовать повторно.