Скиллы и воркфлоу: как не изобретать каждый процесс заново

Я разобрал официальные гайдлайны Anthropic по построению AI-агентов — те самые, по которым устроен Claude Code. Там есть концепция, которую я теперь применяю в своей работе и советую всем, кто серьёзно строит AI-систему под себя.

Называется: скилл и воркфлоу. Звучит технически — на деле это просто способ думать о том, когда стоит автоматизировать и как именно.

Большинство людей, которые начинают работать с AI всерьёз, сталкиваются с одним и тем же: одинаковые задачи решаются каждый раз немного по-другому. Пишешь один и тот же отчёт — каждый раз заново объясняешь контекст, заново выправляешь формат, заново получаешь результат «почти то что нужно».

Это не проблема инструмента. Это отсутствие системы.

Скиллы и воркфлоу — это способ систему выстроить.

Они звучат похоже, но отвечают на разные вопросы.

Скилл отвечает на вопрос: что агент умеет и насколько хорошо. Это кодификация экспертизы и стандарта. «Клиентский отчёт по нашему формату», «бриф по нашей структуре», «пятничное ретро по этим правилам» — всё это скиллы. Внутри описано: что читать, какие вопросы задавать, как выглядит хороший результат, что проверить перед отправкой.

Воркфлоу отвечает на вопрос: в каком порядке идут шаги. Это оркестрация. Не «что умею», а «как организую последовательность». «Собери данные → напиши черновик → проверь по чеклисту → собери финальный файл» — воркфлоу.

Они вкладываются друг в друга. Воркфлоу — конвейер, скиллы — станции на нём. Шаг «написать раздел отчёта» внутри воркфлоу вызывает скилл «клиентский отчёт». Один без другого работает. Вместе — работает лучше.

Гайдлайны Anthropic дают чёткую лестницу:

1. Промпт → разовая задача, один раз
2. Скилл → повторяется 3-5+ раз в месяц, нужен стандарт
3. Воркфлоу → несколько зависимых шагов, нужна надёжность
4. Мульти-агент → шаги требуют полной изоляции друг от друга

Главное правило: начинай с простейшего уровня. Попробуй задачу одним промптом. Если устраивает — готово. Если нет — разбери в чём именно провал, и он подскажет следующий уровень.

Не строй воркфлоу, если справляется скилл. Не строй скилл, если справляется промпт. Усложнение ради усложнения — потеря времени без прибавки качества.

Если до воркфлоу дошло, вот три паттерна:

Последовательный — шаги в фиксированном порядке. Каждый шаг передаёт результат следующему. Это default. Используй когда есть явные зависимости: черновик → ревью → финал.

Параллельный — независимые куски идут одновременно, потом агрегация. Ускоряет и даёт разные точки зрения. Но важный вопрос до старта: как я объединю результаты? Без ответа — не запускай параллель.

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

Здесь я расхожусь с популярным советом «найди готовые скиллы и используй».

Готовый скилл написан под чужие процессы, чужой стиль, чужие задачи. Он работает «в целом», но не работает точно. Когда вы пишете скилл под себя — вы описываете свой реальный процесс: как именно вы делаете отчёт, какие вопросы важны именно вашему клиенту, что именно проверить перед отправкой.

Второе: скилл — это живой документ. Он эволюционирует вместе с вашей работой. Сегодня написали — через месяц поняли что не хватает примера вывода, добавили. Через три месяца изменился формат — обновили скилл. Это ваша система, она знает ваш контекст и растёт вместе с вами.

Готовый скилл этого не даёт. Вы используете чужое — и либо принимаете чужие ограничения, либо всё равно переписываете. Лучше написать с нуля на своём материале.

Пара вещей из гайдлайнов Anthropic, которые меня удивили:

Description решает больше, чем инструкции. Это поле определяет, сработает ли скилл вообще. Если описание размытое — скилл не будет активироваться в нужный момент. Формула простая: что делает + когда триггерится (фразы, ситуации, типы задач). Вкладывай в description столько же, сколько в само тело скилла.

Объясняй зачем, не только что. Не «используй такой формат», а «используй такой формат — потому что клиент читает с телефона и видит только первый экран». Причина помогает агенту правильно обобщать в граничных случаях.

Минимализм побеждает. Короткий точный скилл работает лучше длинного и «исчерпывающего». Чем больше правил — тем хуже агент справляется в нестандартных ситуациях. Пиши ровно то что нужно, не больше.

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

Прежде чем строить — один вопрос: «Сколько раз в месяц это повторяется и сколько времени съедает?»

Если задача повторяется реже 3-5 раз в месяц — скорее всего скилл не нужен. Время на создание и поддержку не окупится. Используй промпт каждый раз.

Если задача не двигает ни метрику, ни деньги, ни скорость — автоматизация не нужна вообще. Это правило работает жёстче всего остального.

Скилл и воркфлоу — не про технологии. Это про то, что вы знаете свой процесс достаточно хорошо, чтобы описать его явно. Когда вы пишете скилл — вы сами понимаете что делаете и почему. Это ценность само по себе.

Начинать легко: возьми задачу, которую делаешь каждую неделю. Опиши её: что на входе, что на выходе, по каким правилам. Это и есть черновик первого скилла. Запусти — посмотри что не работает — улучши.

Ваша AI-система должна быть заземлена на вас. Не на чужие шаблоны.

В канале — мои реальные скиллы из проектов: как выглядят изнутри, как эволюционировали, где сломались на первой версии.