Workflows 2.0

НОВОЕ (Supercode 2.0.4+)

Workflows Maker Skill теперь доступен: генерируйте Supercode Workflows при помощи ИИ. Установите скилл из меню Supercode → Tweaks.
Затем попросите ИИ создать воркфлоу для вас.

Важно: Cursor поддерживает Skills только в nightly builds. Antigravity поддерживает Skills во всех версиях. Вы можете установить этот скилл в Claude Code.

В конце 2025 года самыми популярными темами в ИИ разработке стали Skills и Workflows. Skills - простой в реализации, но крайне мощный механизм, который уже поддерживается большинством ИИ-агентов. При помощи расширения Supercode, вы теперь можете создавать и использовать Workflows любой сложности и гибкости в вашей IDE.

Спустя 6 месяцев с момента выпуска Smart Actions, мы увидели сотни примеров удивительно длинных и ветвистых цепочек действий, которые создают наши пользователи: от интеграций с таск-трекерами и мессенджерами до полностью автоматизированных циклов разработки с пошаговым рефакторингом, выделением абстракций и модулей, дедупликацией кода, и полным покрытием кода тестами.

Мы гордимся этим результатом, и за это время мы получили огромное количество фидбека и запросов на улучшения. Сегодня мы рады представить обновлённый механизм: Workflows.

Это обновление содержит 3 ключевые фичи:

1. Workflows UI: теперь все шаги Workflow создаются в одном UI (или файле), в пару кликов, в десятки раз быстрее и проще.
   
2. Workflow State: вы в реальном времени видите процесс выполнения и информацию по каждому шагу
3. Smart Conditions: теперь вы можете создавать условия для шагов через JavaScript, http-запросы, shell-команды, и даже запросы к ИИ, чтобы он решал на основе входных данных, проходит ли проверка.
   

Зачем нужны Workflows?

Почему Workflows мощнее Skills? Чем workflow отличается от просто предоставленного агенту списка шагов? Чем shell-команды в workflow удобнее, чем хуки? Зачем нужны условные шаги, выполняющиеся только в определённых случаях? Давайте разберёмся.

Два главных столпа workflows это детерминизм (гарантированность) и инкапсуляция (изоляция) будущих шагов. За этими длинными пугающими словами скрываются простые идеи: давайте разберём их на примерах.

Гарантированность

Допустим, мы отправляем следующий промпт, модель - Auto (то есть Composer-1), в Next.js фронтенд-проект:

Естественно, агент сразу же добавил все шаги в todo-лист, и начал работу. Первый и второй шаг неплохо нагрузили контекст - вычитка ~30 файлов съела под 100k токенов. Допустим, с третьим шагом были сложности: агенту пришлось сделать несколько итераций исправлений и проверок через встроенный браузер, прежде чем таблица заработала как надо. В процессе он создавал тестовые страницы, чтобы проверять на них работу таблицы. На этот момент контекст уже забит под 80%.

Как вы считаете, какова вероятность, что после завершения работы над таблицей, агент сам перейдёт к созданию страницы /users? А к созданию /products?

К счастью, нам не приходится гадать: мы проводили буквально этот эксперимент с тестовым Next.js проектом на 7 моделях: Sonnet 4.5, Opus 4.5, Haiku 4.5, GPT-5.2, Composer-1, Gemini 3 Pro, Gemini 3 Flash, по 5 прогонов на каждую модель. Критерий простой - были ли успешно выполнены все шаги после единственного запроса от пользователя.

Средний результат для Opus 4.5 и GPT-5.2 - 80% (8 успешных тестов из 10), Sonnet и Gemini 3 Pro - 60%, средний в группе "Haiku, Composer-1 и Gemini 3 Flash" - 46% (7 из 15).

Нетрудно заметить - даже флагманские модели, в 1 случае из 5 не довели задачу до конца с одного запроса. Последняя группа из популярных недорогих моделей в половине случаев не доделала работу. При этом, сама задача и описанный сценарий проблем - довольно типовые. А если в рабочем процессе пользователя 20 шагов, часть из которых должны выполниться только при определённых условиях?

Гарантированность (детерминизм) - это базовое свойство Workflows: если в workflow есть шаг (отправка задачи агенту, запуск скрипта, и т.д.), то он гарантировано будет выполнен.

Изоляция будущих шагов

Когда вы даёте модели набор действий, которые ей надо совершить, она заранее знает все действия, и не может не обращать внимание на последние во время выполнения первых.

Этот концепт понятен людям: если мы заранее знаем, какого результата от нас ждут, мы можем попытаться адаптировать нашу работу так, чтобы быстрее к нему прийти. Иногда это прекрасно, и может сэкономить время. Но есть процессы, в которых кропотливое следование инструкциям необходимо, без них не получится хорошего результата.

Чтобы было проще, вот пример. Допустим, мы даём модели задачу (десктопное Electron-приложение):

Скажем, в этих файлах два типа утечек:

1. вместо удаления таймера, он выключается: setInterval(() => { if (!active) return; ... })
2. некорректная очистка глобального кеша (top-level const map = new Map())

И в первых 5 файлах в src/watchers встречаются только ошибки первого типа.

Нередко, агент, который заранее знает, что от него ждут именно исправления утечек, попытается "срезать путь": обнаружив одну и ту же проблему 5 раз подряд, он напишет "Давайте сразу проверим все файлы regexp-поиском", сделает поиск по setInterval, и обнаружит только те файлы, в которых были проблемы первого типа, и при этом совершенно упустит второй тип.

Проблема "expected result bias" не решается ростом интеллекта или ценой модели, ей подвержены даже люди. В ситуациях, когда пошаговое предоставление информации улучшает качество результата (глубокий анализ файлов перед рефакторингом, полная вычитка документации перед имплементацией), workflows гарантируют, что в контекст агента не попадает информация о следующих действиях до момента, когда их надо будет выполнять.

Сравнение со Skills

Создаём Workflow

Workflow хранятся в yml/json файлах внутри .supercode/workflows/ (локальные - в корне проекта, глобальные - в пользовательской директории).
В одном файле вы можете описать как один, так и несколько workflow. Они могут храниться в любой вложенной папке, к примеру, нам кажется удобным выделять workflow в отдельную директорию, и хранить описание workflow сразу рядом с используемыми скриптами (аналогично Skills).

Глобальные настройки

У workflow есть две группы глобальных настроек - Triggers и Advanced Configuration.

В группе триггеров вы можете настроить как вы хотите запускать workflow: по нажатию на кнопку в UI, и/или на основе голосовой команды. Обратите внимание - даже если вы не выбрали ни один из вариантов, ваш workflow всегда доступен по клику из меню Supercode > Workflows, и его всегда можно запустить из другого Workflow.

В группе Advanced Configuration вы можете настроить стандартные модель и режим работы агента, которые будут выбраны при запуске workflow. Обратите внимание: если какой-то из шагов workflow явно переопределяет модель или режим - то это переопределение (у конкретного шага) будет иметь приоритет над стандартными настройками.

Шаги Workflow

Workflow состоит из последовательности действий (шагов), которые будут выполнены по очереди.

Шаг может быть командой (промптом) для ИИ-агента в вашей IDE. Шаг может быть вызовом скрипта. Или он может динамически формировать новый промпт или системный промпт (при помощи скрипта или запроса к ИИ). Он может переопределять текущую активную модель или режим работы агента. Шаг может содержать условие, которое определяет - будет ли он выполнен или пропущен. А также он может содержать неограниченное количество вложенных шагов или ссылок на другие Workflow. Давайте подробно разберём каждую из этих возможностей.

Три типа шагов

В каждом workflow, а также во всех вложенных действиях, вы можете создавать шаги трёх типов:

1. Add Step: стандартный вариант, создаёт обычный шаг, который вы можете настроить под ваши задачи.
2. Select Existing Action: создаёт шаг-ссылку на существующий Workflow или Smart Action.
3. Add "Run Shell" action: создаёт шаг, который выполняет shell-команду (к примеру, запускает Node.js или Python скрипт).

Стандартный шаг

Это основной тип шагов, из которых состоят Workflow. У каждого шага есть:

• Название
• Должен ли этот шаг запускать ИИ-агента в вашей IDE (иконка Run с переключателем)
• Статус активности (икнока глаза, при помощи которой вы можете временно помечать неиспользуемые шаги как неактивные)
• Набор настроек (промпт, сис. промпт, модель, режим агента, IDE-команда, условие выполнения)
• Набор вложенных шагов

Промпт и системный промпт

Есть 5 способов обновить промпт или системный промпт:

1. Текст
2. ИИ-генерация
3. Shell-команда
4. HTTP-запрос
5. JavaScript-код

Текст

Это самый простой вариант: вы можете просто задать статический текст нового промпта, который будет передан в ИИ-ИИ-агента. Или вы можете использовать доступные переменные, которые будут автоматически заменены на значения из текущего контекста.

ИИ

Это мощная механика, которая позволяет вам сгенерировать текст нового промпта при помощи запроса к отдельной ИИ-модели Supercode. Вы также можете использовать доступные переменные (к примеру, текущий промпт через $prompt), и попросить ИИ переработать задачу: разбить её на этапы, перевести на другой язык, удалить лишнее, структурировать или добавить упущенные детали, учесть ньюансы безопасности и многое другое. Представьте, что вы как будто можете автоматически улучшить ваш промпт через ChatGPT, прежде чем передавать его в работу агенту Cursor. Именно это позволяет сделать этот тип генерации промпта.

Shell-команда

Этот тип позволяет вам выполнить любую shell-команду (или цепочку команд) и использовать стандартный вывод команды (stdout) в качестве нового промпта.
В том числе, в качестве команд может выступать запуск скриптов: node ./my-script.js или python ./get-data.py. При помощи этой механики вы можете выгружать текст задач из таск-трекеров, подтягивать актуальные баги из Sentry, обращаться к API, БД, получать информацию из логов, и многое другое. Как и в остальных случаях - вам доступны текущие переменные.

Запрос к URL

Этот тип позволяет вам выполнить POST-запрос к любому URL и использовать ответ (JSON) в качестве нового значения. Текущие переменные отправляются в теле запроса (application/json).

JavaScript-код

Этот тип позволяет вам выполнить любой JavaScript-код и использовать его результат в качестве нового значения. Текущие переменные доступны в виде глобальных переменных (для обращения к ним не нужен префикс в виде знака доллара, просто prompt, model, response, etc).

Доступные переменные

При любом типе переопределения промпта или системного промпта, вы можете использовать переменные, в которых находится состояние текущего контекста:

• $prompt - Текущий текст промпта
• $systemPrompt - Текущий текст системного промпта
• $response - Последний ответ ИИ-ИИ-агента. Обратите внимание: это буквально последнее написанное агентом текстовое сообщение, если агент выполнял несколько действий (редактировал файлы, думал, выполнял команды в терминале, etc), то в этой переменной будет хранится именно самый последний блок текста, который был написан агентом, а не все его текстовые сообщения с момента вашего последнего запроса. Эта переменная удобна, когда вы просите агента завершить его работу каким-то текстовым ответом: в таком случае, этот ответ как раз окажется в этой переменной.
• $packedResponses - Все текстовые сообщения, которые были отправлены агентом с момента вашего последнего запроса, упакованные в XML-like формат (...<message from="ai-assistant">...</message>...). Эта переменная подходит, когда вы хотите проанализировать все действия агента с момента вашего последнего запроса.
• $model - Текущая выбранная модель
• $mode - Текущий режим работы агента (agent/plan/debug/etc/или название Custom Mode)
• $initialPrompt - Промпт, который был в поле ввода в момент запуска workflow.
• $initialModel - Модель, которая была выбрана в момент запуска workflow.
• $initialMode - Режим, который был выбран в момент запуска workflow.

Режим и модель

Каждый шаг workflow может переключить текущую модель и режим работы агента. Этот механизм позволяет вам гибко адаптировать работу: использовать более умные модели для планирования изменений, и дешевые для редактирования кода. Вы можете использовать аналитические режимы для исследования кодовой базы и поиска ответов на ваши вопросы, после чего автоматически включать режим Debug для поиска и исправления багов.

Условные шаги (ветвление)

Для каждого шага вы можете задать условие, которое будет проверено _прежде_ чем шаг начнёт выполняться. Механизм работы условий очень похож на механизм обновления промптов: вам также доступны все переменные, и почти все варианты запуска (кроме текстового): JavaScript, Shell-команда, HTTP-запрос и запрос к ИИ.

Ключевая разница заключается в том, какой ответ ожидается от выполнения условия:

• JavaScript: должен вернуть boolean значение (или явное true/false или truthy-falsy значение).
• Shell-команда: должна завершиться с кодом 0 в случае успеха (шаг выполнится), и ненулевое значение в случае ошибки (шаг будет пропущен).
• HTTP-запрос: должен вернуть статус 2xx в случае успеха (шаг выполнится), и любой другой статус в случае ошибки (шаг будет пропущен).
• Запрос к ИИ: должен вернуть текст "true", "yes" или "1", тогда шаг выполнится, иначе - будет пропущен.

Комбинация условий и вложенных шагов позволяет вам создавать ветвления и циклы любой сложности.

IDE-команда

Вы можете задать IDE-команду, которая будет исполнена в момент выполнения этого шага. Этот механизм позволяет вам управлять средой в рамках вашего workflow: открывать новый чат, таким образом сбрасывая контекст, запускать компиляцию проекта через npm tasks, создавать новые файлы и многое другое.

Вложенные шаги

Вы можете создавать вложенные шаги, которые будут исполняться в конце выполнения текущего шага (после того, как его основные действия по перезаписи промптов, запуску ИИ-агента, и так далее уже выполнены). Этот механизм устроен абсолютно так же, как и основные шаги в workflow: вы можете создавать дополнительные действия, ссылки на другие workflow, запускать скрипты, и так далее. Благодаря возможность создавать сколь угодно много вложенных шагов (и вкладывать их друг в друга), вы можете описать любой задуманный вами сценарий при помощи workflow.