GoLive — агентный навык, который выводит собранное агентом приложение в продакшен

GoLive — открытый агентный навык (agent skill) и CLI на Node.js, который закрывает самую неприятную часть работы с кодом, написанным агентом. Программу собрали за вечер. Дальше нужны учётные записи, хостинг, база данных, домен, почта и платежи — и всё это руками, в браузере, по одному сервису за раз. GoLive берёт на себя эту часть: он смотрит, что приложению нужно, составляет точный план, просит одобрения и применяет изменения вашими же логинами. Всё происходит на ваших аккаунтах, без аккаунта GoLive, без его бэкенда и без телеметрии. Лицензия MIT, проект написан на TypeScript, сейчас выходит 0.1.0-alpha.8 и набирает больше 1200 звёзд на GitHub.

Что именно он умеет

Восемь направлений, которые обычно и съедают день деплоя:

• Хостинг. Vercel и Netlify. На этих двух хостингах есть готовые сценарии.
• База данных. Supabase и Neon.
• Аутентификация. Настройки Supabase Auth: регистрация, подтверждение по почте, минимальная длина пароля, почтовый сервер, адрес сайта и список разрешённых переходов.
• Платежи. Stripe, пока в тестовом режиме.
• Письма. Resend: настройка домена отправки, записи DNS, проверка домена, реальная отправка.
• Домен и DNS. Привязка домена к хостингу. Записи DNS автоматизированы у Cloudflare, GoDaddy и Porkbun.
• Аналитика и мониторинг. PostHog и Sentry — есть адаптеры и проверки.
• Обратный демонтаж. Всё, что он создал, можно удалить одной командой.

Важная деталь архитектуры: у рантайма нет внешних зависимостей. К провайдерам он ходит через их собственные CLI и по HTTPS через их API. MCP-сервер не нужен.

Как это устроено

GoLive — это пара: агент и CLI.

Агент ведёт разговор, задаёт вопросы и спрашивает одобрение. CLI делает операции у провайдеров, держит секреты внутри процесса и записывает доказательства того, что сделал. Каждая команда печатает один JSON-документ. Код возврата 2 означает «отработал, но что-то требует внимания» — в этом случае нужно читать JSON.

Схема работы выглядит так:

detect → menu → init → doctor → plan → apply → verify → report

• detect сканирует приложение и сообщает фреймворк, провайдеров, которые код уже использует, и имена переменных окружения, которые ожидает.
• menu показывает список провайдеров с пометками «автоматизировано» или «вручную».
• init записывает конфигурацию в golive.yaml.
• doctor проверяет доступ к аккаунтам.
• plan наблюдает за состоянием провайдеров и возвращает список шагов и пунктов «передать человеку».
• apply применяет одобренный план.
• verify прогоняет живые проверки и пишет отчёт.
• status отвечает на другой вопрос: что изменилось мимо инструмента с тех пор, как он всё записал.

Путь, который нужно одобрить

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

Кроме --yes есть три дополнительных флага, и каждый закрывает свою категорию риска:

Про первый продакшен-деплой стоит сказать отдельно. Раньше одного одобрения плана хватало, чтобы впервые записать в продакшен. Теперь для этого нужен ещё и --confirm-live. Логика такая: одобряя план, вы соглашаетесь с тем, что внутри этого деплоя, а флаг — это отдельное согласие на саму первую запись в живое окружение. Неудачная попытка деплой не записывает, поэтому флаг остаётся. После первого успешного деплоя последующие деплои того же проекта дополнительного флага не требуют.

Есть ограничение, которое честнее назвать, чем спрятать. Эти флаги — аргументы командной строки, которые агент передаёт от вашего имени. Агент, который уже вошёл в ваш провайдер, может писать туда и вообще без плана GoLive. Границу между тем, что код запрещает, и тем, что агент просто обязан соблюдать, разбирают в документе Trust, access and control.

Куда деваются секреты

Значения ключей читаются только внутри процесса. Они не печатаются и не попадают ни в аргументы командной строки, ни в планы, ни в состояние, ни в отчёты — вместо значений хранятся отпечатки.

Хранилище — ~/.config/golive/credentials: обычный текстовый файл с правами 0600, лежит вне репозитория приложения. Это не системная связка ключей. Всё, что запущено от вашего пользователя, может прочитать этот файл.

На macOS для ручного ввода ключа есть нативное диалоговое окно со скрытым вводом: оно объясняет, зачем спрашивает, и где будет сохранён ключ. Значение уходит сразу в локальный файл — в чат и в вывод команды оно не возвращается. На других платформах остаётся редактор.

Отдельно стоит правило про чат: секреты не должны проходить через переписку. Единственное исключение — публичные ключи Stripe с префиксом pk_. Ключи с префиксами sk_, rk_ и whsec_ в чат не принимаются. Если человек всё равно вставил такой ключ, его не используют: ключ теперь в истории диалога, и его нужно перевыпустить.

Проверки, и что они на самом деле доказывают

verify пишет файл GOLIVE_REPORT.md с результатами четырёх типов: успех, провал, предупреждение и пропуск. Ключевая формулировка проекта: пропуск — это не успех. Пропущенная проверка означает «заблокировано или неприменимо», и в её доказательстве будет написано, чем именно она заблокирована.

Состав проверок длинный. Среди них:

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

Что проверяли на живых прогонах

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

Проверка изоляции аккаунтов, предварительные деплои, продвижение релизов, чтение живых платежей и Sentry пока в статусе «реализовано и покрыто подставными ответами, но не проверено вживую». Про Cloudflare DNS тоже сказано прямо: это ещё не подтверждённый маршрут alpha-версии. Полный список с датами прогонов и ссылками на конкретные дефекты лежит в validation record, границы по каждому провайдеру — в provider scope.

Обратный демонтаж

teardown строит обратный план: он перечисляет только те ресурсы, которые GoLive может доказать, что создал сам. Это DNS-записи, зарегистрированные вебхуки, выданные ключи отправки и проект хостинга с совпавшим маркером создания.

Всё остальное, включая проекты Supabase и Neon и домен отправки Resend, становится пунктом «сделать руками» — с указанием, что осталось и как это удалить. Проект формулирует это аккуратно: «ничего не остаётся молча» не то же самое, что «ничего не остаётся».

Удаление, о котором провайдер подтвердил, что ресурса больше нет, стирает записанный для него базовый снимок. Иначе следующий запуск status принял бы собственную уборку GoLive за расхождение.

Кто владеет результатом

После выкатки в бой остаётся вопрос, что делать дальше. На него отвечает status — только на чтение, без записи отчёта, состояния и изменений у провайдеров. Он сравнивает то, что GoLive записал (записи DNS, имена переменных окружения, зарегистрированный вебхук, привязку домена, проект базы, домен отправки, платёжный аккаунт), с тем, что провайдеры отдают сейчас. Каждая позиция помечена: expected (recorded by golive <time>) против observed (read now).

Тонкость, о которой стоит сказать: расхождения намеренно не являются блокировкой. Команды plan, apply и verify их не читают. Сравнение, требующее неутверждённого решения, заблокировало бы нормальное намерение человека. Пересобрать базовый снимок можно только новой одобренной записью.

handoff --write пишет документ о владении — GOLIVE_HANDOVER.md в корне и его JSON-версию в .golive/handover.json. В нём по именам указаны аккаунты и способ входа, каждый созданный ресурс с доказательством принадлежности, что осталось ручным, что повторяется со временем, как всё удалить и какой командой перепроверить. Каждая строка помечена одним из четырёх ярлыков: проверено GoLive, записано ранее, не проверяемо GoLive или неизвестно. Секретов в документе нет, но названия аккаунтов и ресурсов там есть — перед тем как делиться, его стоит прочитать.

Установка

Нужны Node.js 20+, npm/npx, Git и агент, умеющий загружать навыки и выполнять команды. Проверено на Codex и Claude Code, остальные клиенты не проверялись.

Глобальная установка из любой директории:

npx skills add https://github.com/mikehasa/golive-skill --skill golive --global

Чтобы пропустить выбор агента:

# Codex
npx skills add https://github.com/mikehasa/golive-skill --skill golive --global --agent codex --yes

# Claude Code
npx skills add https://github.com/mikehasa/golive-skill --skill golive --global --agent claude-code --yes

Убрать --global, чтобы поставить навык в один проект.

Тот же навык доступен через npm — golive@0.1.0-alpha.8, ставится без Git и без Skills CLI:

# Codex
npx golive@alpha install --agent codex

# Claude Code
npx golive@alpha install --agent claude

Пакет npm также даёт CLI в терминале: help, version, update-check, credentials, detect, menu, init, doctor, plan, teardown, apply, verify, status, handoff, а также команды установщика install, install-status, update, rollback, update-policy, recover-lock.

Для пользователей OpenClaw есть третий канал — ClawHub:

npx clawhub@latest install golive     # into ./skills, recorded in .clawhub/lock.json
npx clawhub@latest update golive      # later updates stay with ClawHub

После установки перезагрузите навыки или начните новую сессию, если GoLive не появился. В Claude Code навык вызывается как /golive, в Codex — как $golive. Можно и обычной фразой: «Use the golive skill to take this app live. Keep the providers it already uses. Show me the destination accounts and plan before changing anything.» Подробности про каналы установки и обновления — в DISTRIBUTION.md.

Что осталось за рамками alpha

Обратный откат есть, но он узкий и включается только по запросу. Флаг release.rollback: true просит вернуть продакшен на более ранний деплой, который GoLive сам создал и записал. Деплой, собранный через панель, обычным git push или pull request'ом, целью отката не станет. Данные, DNS, платежи и почту откат не трогает. Работает это пока только на Netlify: у адаптера Vercel нет чтения состояния того, что отдаёт продакшен, поэтому там исправление делают в панели, а GoLive вмешиваться не будет. Провалившаяся проверка никогда не запускает откат сама по себе.

Дальше — список задач, а не релизный план. Backend на постоянных серверах, миграции схемы, файловое хранилище, OAuth и SSO, SMS и пуш-уведомления, фоновые задачи, кеш с поиском, безопасность, мониторинг с алертами, бэкапы, бюджеты и квоты — всё это в дорожной карте как «запланировано». Проверка метаданных страницы, Sentry и аналитика на PostHog находятся в промежуточном состоянии. Проект отдельно говорит, что сроков не называет. Возможность переходит из экспериментальной только после того, как на настоящем аккаунте отработали подключение, проверка и откат.

Редкость, из-за которой этот навык и стоит посмотреть, в том, что проект сам перечисляет свои пределы. Он не обещает «запустить любой проект в продакшен» — он перечисляет семь живых маршрутов, честно отделяет их от покрытых подставными ответами и зовёт присылать отчёты об ошибках вместе с описанием реального места, где запуск застрял. Архитектура и разбор границ доверия собраны в ARCHITECTURE.md и TRUST.md, порядок работы при сбое разобран в RECOVERY.md, а условия участия — в CONTRIBUTING.md. Лицензия MIT: LICENSE.