أطلق Harry Tan مشروع gstack — نظام workflow لـ Claude Code مع QA والمراجعة والإصدار

Гарри Тан выложил в open source gstack — набор навыков для Claude Code, который превращает работу с AI-агентом для кода в более жёсткий и предсказуемый процесс. Идея простая: не смешивать планирование, инженерную проверку, QA и релиз в один бесконечный промпт, а разнести их по отдельным режимам с понятными ролями.

Что такое gstack В основе gstack не новая модель и не ещё один

агентный фреймворк, а workflow-слой поверх Claude Code. Проект упаковывает типичные этапы поставки софта в отдельные команды и задаёт для каждой свой режим мышления. Вместо импровизации в духе «сделай фичу и сам себя проверь» разработчик получает последовательность шагов: сначала продуктовая формулировка, потом инженерный план, затем ревью, браузерная проверка и только после этого подготовка релиза. То есть gstack пытается добавить в AI-разработку не магию, а процессную дисциплину.

«Eight opinionated workflow skills for Claude Code» — так проект описывает себя сам.

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

Восемь режимов работы

На момент релиза в репозитории было восемь основных команд, и каждая отвечала за отдельный участок процесса, а не за «всё сразу». В этом и есть главная ставка gstack: качество повышается не новым интеллектом, а дисциплиной вокруг уже существующего coding-агента. Отдельная команда проверяет продуктовую идею, отдельная — архитектуру и тесты, отдельная — риски в коде, а ещё одна отвечает за последний этап перед merge и релизом.

`/plan-ceo-review` — продуктовая проверка идеи и приоритетов `/plan-eng-review` — архитектура, data flow, edge cases и тесты `/review` — поиск рисков в проде и проблем в коде `/ship` — синхронизация ветки, прогоны тестов и подготовка PR * `/browse`, `/qa`, `/setup-browser-cookies`, `/retro` — браузер, QA, импорт cookies и ретроспектива Такой разбор на роли выглядит особенно логично на фоне типичной проблемы AI-кодинга: агент быстро пишет happy path, но часто пропускает пограничные сценарии, регрессии и UX-сбои. В gstack эти проверки вынесены в отдельные режимы, чтобы они не конкурировали с задачей «написать код как можно быстрее». Это не гарантирует отсутствие ошибок, но делает сам процесс ближе к обычной инженерной практике, где дизайн, реализация, проверка и выпуск не свалены в один шаг.

Браузер, QA и стек

Самая интересная часть gstack — не markdown-навыки, а постоянный браузерный рантайм. Вместо запуска нового браузера на каждое действие система поднимает долгоживущий headless Chromium daemon и общается с ним по localhost HTTP. Это нужно и для скорости, и для сохранения состояния между шагами.

По данным из описания проекта, холодный старт браузерного инструмента занимает около 3–5 секунд, а следующие вызовы после запуска укладываются примерно в 100–200 миллисекунд. За счёт этого между командами сохраняются cookies, вкладки, localStorage и состояние логина. Отдельно важно, как этот браузер встроен в QA-поток.

Команда `/browse` даёт агенту возможность зайти в приложение, прокликать интерфейс, сделать скриншоты и посмотреть, где всё ломается. А `/qa` идёт дальше: анализирует diff ветки, определяет затронутые маршруты и проверяет именно те страницы и сценарии, которые могли пострадать от изменений. В примере из репозитория этот режим разобрал восемь изменённых файлов, нашёл три затронутых маршрута и прогнал их против локального инстанса приложения, то есть связал кодовые изменения с реальным поведением интерфейса.

С технической стороны gstack тоже сделан прагматично. Для работы нужны Claude Code, Git и Bun 1.0+, а в репозитории на момент публикации использовались Playwright и пакет `diff`, причём команда `/browse` собиралась в отдельный исполняемый бинарник.

Набор можно установить в `~/.claude/skills/gstack` или положить в локальную `.claude/skills/gstack` внутри проекта, чтобы вся команда использовала один и тот же процесс.

Выбор Bun авторы объясняют простыми причинами: компилируемые бинарники, нативный доступ к SQLite, выполнение TypeScript без лишней обвязки и встроенный HTTP-сервер через `Bun.serve()`.

Что это значит gstack интересен не как «ещё один набор промптов», а

как попытка превратить AI-кодинг в повторяемый конвейер с проверками на каждом этапе. Если такой подход приживётся, рынок будет двигаться не только к более сильным моделям, но и к более жёстким операционным слоям поверх них — с отдельными режимами для планирования, ревью, QA и релиза. Главный сдвиг здесь в том, что доверие к AI пытаются строить не обещаниями модели, а этапами проверки.