gstack: стек искусственного интеллекта для разработки ПО

ИИ-агенты для программирования уже способны писать функции, модифицировать репозитории, запускать тесты и создавать pull request’ы. Более сложная задача — заставить агента следовать повторяемому инженерному процессу до, во время и после написания кода.

gstack — проект Гэри Тана (Garry Tan), изначально созданный вокруг Claude Code, — идёт по другому пути: вместо замены вашего агента для программирования другой платформой, он оборачивает уже используемого агента специализированными навыками, браузерными инструментами, ревью, механизмами безопасности и процессами релиза. Проект описывает результат как виртуальную инженерную команду — двадцать три специалиста и восемь мощных инструментов, все в виде slash-команд, всё в формате Markdown, лицензия MIT.

Сопоставляемые цели зависят от того, какая часть gstack вам нужна: коллекции навыков, такие как Superpowers, системы спецификаций, такие как OpenSpec и GitHub Spec Kit, методологии, такие как BMAD, платформы оркестрации, такие как Ruflo, или собственный поддерживаемый набор навыков агента. Некоторые из них комбинируются с gstack, а не заменяют его, а более широкая экосистема, частью которой они все являются, отображена в хабе AI Developer Tools этого сайта.

Что такое gstack?

gstack — это open-source-коллекция рабочих процессов инженерии на базе ИИ. В концепции gstack разработка программного обеспечения состоит из нескольких различных видов рассуждений, и ожидание, что одно универсальное промпт-задание выполнит все их, — плохая абстракция; поэтому проект предоставляет специализированные навыки:

• исследовательские сессии (office-hours)
• ревью на уровне продукта и CEO
• ревью архитектуры
• ревью опыта разработчика (DX)
• ревью дизайна
• ревью реализации
• браузерное QA
• расследование и отладка
• анализ безопасности
• документация
• бенчмаркинг
• подготовка к релизу
• развёртывание (деплой)
• ретроспективы

Проект представляет эти роли как виртуальную инженерную команду: CEO, который переосмысляет продукт; инженерный менеджер, который фиксирует архитектуру; дизайнер, который ловит «AI slop»; ревьюер, который находит продакшен-баги; QA-лид, который открывает реальный браузер; офицер безопасности, который проводит аудиты по OWASP и STRIDE; и инженер по релизам, который отправляет PR. Инструментальная цепочка вокруг определений навыков — это TypeScript и Bun: сценарий установки, генерируемая документация навыков, сессионные хуки, состояние в ~/.gstack/, встроенный браузер и набор автономных CLI-инструментов.

gstack — это не фундаментальная модель и не замена Claude Code; это уровень процессов, работающий поверх харнеса агента:

Два структурных свойства определяют, где встает gstack. Во-первых, проект описывает его как процесс, а не как коллекцию инструментов: навыки выполняются в том порядке, в котором идет спринт — думать, планировать, строить, ревьюить, тестировать, шипить, рефлексировать — и каждый навык передает свои артефакты следующему, так что /office-hours пишет дизайн-документ, который читает /plan-ceo-review, а /plan-eng-review пишет план тестирования, который подбирает /qa. Во-вторых, gstack не ограничен только Claude Code: ./setup автоматически обнаруживает установленные на машине агенты, а ./setup --host <name> нацеливается на Codex CLI, OpenCode, Cursor, Factory Droid, Kiro, Slate, OpenClaw и Hermes, тогда как 2КБ digest с только инструкциями в репозитории покрывает агенты, читающие правила, которым вообще не требуется установка.

Зачем существует gstack

Пустая сессия Claude Code чрезвычайно гибка, и эта гибкость — одна из её слабостей. Рассмотрим запрос фичи, такой как:

Добавить API-токены на уровне организации в приложение.

Способный агент может сразу исследовать репозиторий и начать модифицировать код аутентификации, тогда как старший инженер сначала спросит, кто владеет токенами, могут ли пользователи принадлежать к нескольким организациям, как отзываются токены, наследуются ли разрешения, что происходит с существующей аутентификацией, должны ли токены истекать, как отображаются секреты и какие события аудита требуются. Агент может обнаружить некоторые из этих вопросов в конце концов, но нет гарантии, что он обнаружит их до реализации. gstack переносит эту дисциплину в повторяемые рабочие процессы: вместо идея -> агента -> код, изменения проходят ревью продукта, техническое планирование, ревью архитектуры, реализацию, ревью кода, браузерное QA и релиз как именованные этапы, каждый со своей командой (полная последовательность в Практическом рабочем процессе gstack ниже).

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

Как gstack превращает Markdown-навыки в процесс

Большинство возможностей gstack исходят из определений навыков в Markdown. Навык агента может описывать:

• когда он должен выполняться
• какой контекст он должен проверять
• какие вопросы он должен задавать
• какие инструменты он может использовать
• какие команды он должен выполнять
• какие доказательства он должен собрать
• какие проверки должны пройти
• как должен быть структурирован результат

Такой навык действует где-то между документацией, повторяемым промптом, стандартной операционной процедурой и конфигурацией рабочего процесса. Базовые механики описаны в Claude Skills и SKILL.md для разработчиков; gstack добавляет инфраструктуру поверх этого примитива: генерируемые определения навыков, хуки запуска и завершения, управление состоянием под ~/.gstack/, браузерную автоматизацию, механизмы безопасности, инспекцию репозитория, опциональную телеметрию, память между сессиями, управляемую /learn, и опциональную постоянную базу знаний через отдельный проект GBrain, который /setup-gbrain может развернуть как локальную базу данных PGLite, проект Supabase или удаленный MCP-эндпоинт.

Самые важные навыки gstack

Точный коллекция быстро меняется, но несколько рабочих процессов иллюстрируют, как система предназначена для использования.

office-hours

/office-hours находится в начале проекта или фичи. Он выполняет шесть наводящих вопросов о проблеме до написания кода, и в практическом примере в README он переформулирует запрос «приложения для ежедневного брифинга» в личного ИИ-штаба, а затем пишет дизайн-документ, который читают все последующие навыки. Для размытого входа, такого как «нам нужен лучший поиск проектов», выходом является требование, а не код.

plan-ceo-review

/plan-ceo-review рассматривает продуктовые допущения, лежащие в основе плана. Он работает в четырех режимах охвата — Expansion, Selective Expansion, Hold Scope, Reduction — и может оспаривать объем, идентифицировать упущенные возможности, сокращать ненужную работу или предлагать по-другому сформулировать проблему. Он выполняется до того, как требования будут зафиксированы, на этапе, которого нет у большинства инструментов для агентов.

plan-eng-review

/plan-eng-review смещает перспективу в сторону инженерии: архитектура, поток данных, диаграммы, граничные случаи, матрица тестирования, режимы отказов и проблемы безопасности. Он остается отделенным от продуктового ревью, потому что объединение обоих в один большой промпт заставляет модель смешивать продуктовые решения с решениями по реализации.

plan-design-review и design-review

gstack рассматривает визуальный дизайн и дизайн взаимодействия как отдельную дисциплину. /plan-design-review оценивает каждое измерение дизайна от 0 до 10, описывает, что выглядит как 10, и редактирует план, чтобы закрыть разрыв, с детекцией «AI slop» как именованной проверкой. Позднее /design-review проводит тот же аудит против фактической реализации и исправляет найденное атомарными коммитами и скриншотами «до/после». Для веб-приложений оба сочетаются с браузерной автоматизацией gstack.

review

/review выполняет инженерное ревью изменений в репозитории с точки зрения staff-инженера: он автоматически исправляет очевидные находки, помечает остальные на утверждение и сохраняет рекомендательную перспективу упрощения для чрезмерно сложенного кода. Успешно написанный код не обязательно должен быть смержен.

investigate

/investigate применяет систематическое правило отладки, которое проект называет Железным законом: никаких исправлений без расследования. Он прослеживает поток данных, тестирует гипотезы и останавливается после трех неудачных попыток исправления, а не продолжает биться головой о стену. Он также автоматически активирует /freeze, который блокирует редактирование модуля под расследованием.

qa и qa-only

/qa заставляет агента управлять браузером, взаимодействовать с приложением, находить баги, исправлять их атомарными коммитами, повторно верифицировать и генерировать регрессионный тест для каждого исправления. /qa-only выполняет ту же методологию, но только в режиме отчета. Многие агенты останавливают верификацию на «тесты прошли»; для веб-приложения браузер — это то место, где обычно проявляются ошибки интеграции, проблемы с макетом, некорректные потоки, сбои аутентификации и исключения JavaScript.

ship, land-and-deploy и canary

Цепочка релиза — это три навыка, а не один. /ship синхронизирует main, запускает тесты, аудиторит покрытие, пушит и открывает pull request, создавая фреймворк тестов, если его нет в проекте. /land-and-deploy мерджит, ждет CI и деплоя и проверяет здоровье продакшена. /canary затем запускает цикл мониторинга после деплоя, следя за ошибками консоли, регрессиями производительности и сбоями страниц.

autoplan, spec, learn и retro

/autoplan автоматически выполняет конвейер ревью CEO, дизайна, DX и инженерии — инженерия всегда последней, чтобы гейт шипинга ревьюил финальный скорректированный план — и выносит на утверждение только решения по вкусу. /spec превращает размытое намерение в точную, исполняемую спецификацию в пять фаз (почему, охват, техническая с обязательным чтением кода, черновик, файл) с гейтом качества внешнего ревью перед подачей. /learn управляет тем, что gstack узнал между сессиями — паттерны, подводные камни и предпочтения — с ревью, поиском, обрезкой и экспортом. /retro производит осведомленную о команде недельную ретроспективу; /retro global выполняет её для всех ваших проектов и ИИ-инструментов.

Браузерная автоматизация в gstack

На поддерживаемых системах macOS (macOS 15+) gstack в первую очередь управляет браузером Aside — вашим настоящим браузером, с вашими реальными активными сессиями, в вкладках, которые агент открывает сам для себя и закрывает, когда закончит. Если Aside недоступен, gstack переключается на собственный движок на базе Chromium, который собирается через ./setup и который запускает постоянный демон, а не новый браузер для каждой команды:

Постоянное состояние браузера позволяет куки, сессиям аутентификации и вкладкам сохраняться между операциями, что делает браузерное QA практичным. /open-gstack-browser открывает fallback-движок с видимым интерфейсом, с сайдбар-агентом, который направляет быстрые действия (клик, навигация, скриншот) к Sonnet, а чтение или анализ к Opus. Когда агент наталкивается на CAPTCHA, стену авторизации или запрос MFA, $B handoff открывает видимый браузер на той же странице с куками и вкладками; вы решаете это, и $B resume продолжает с того места, где остановился агент. Агент автоматически предлагает handoff после трех последовательных неудач. /pair-agent делит браузер с другими агентами — OpenClaw, Hermes, Codex, Cursor или любым, кто может делать curl — с токенами ограниченной области, изоляцией вкладок, ограничением скорости и атрибуцией активности по вкладкам.

Постоянный движок также увеличивает поверхность безопасности, поскольку агент с доступом к аутентифицированным сессиям обладает значимыми привилегиями. gstack предоставляет многоуровневую защиту от промпт-инъекций для этого: контент-фильтры (datamarking, удаление скрытых элементов, очистка ARIA, блок-лист URL) при каждом чтении страницы, плюс локальный ML-классификатор в sidecar-субпроцессе, который сканирует контент, полученный из страницы, перед тем, как агент его увидит, с комбинатором вердиктов, который требует согласия классификатора перед блокировкой. Контент страницы рассматривается как недоверенный ввод — агент берет синтаксис со страницы, но никогда не инструкции. Проверки перед и во время использования браузерного QA:

• Заранее решите, в каких аутентифицированных средах агент может работать, и предпочитайте изолированный профиль для QA-работы, если используется fallback-движок.
• Знайте аварийный выключатель: GSTACK_SECURITY_OFF=1 отключает слой безопасности — не оставляйте его установленным.
• Постоянный демон сохраняет куки и сессии между запусками, поэтому останавливайте его, когда закончите, и убеждайтесь, что ничего не осталось запущенным, например ps aux | grep -i chrom.
• Прочитайте хуки и механизмы безопасности в склонированном репозитории перед их включением — это обычные файлы, поэтому ревьюйте их так, как ревьюите конфигурацию CI.
• После обновления клона повторно запустите ./setup, чтобы сгенерированные компоненты оставались в синхроне с определениями навыков.

Ограждения безопасности и второе мнение

Три мощных инструмента действуют как сессионные переключатели безопасности. /careful предупреждает перед разрушительными командами — rm -rf, DROP TABLE, force-push, git reset --hard — и активируется фразой «будь осторожен»; рекурсивное удаление корня или домашнего каталога и force-push в ветку по умолчанию жестко запрещаются. /freeze ограничивает редактирование файлов одним каталогом, чтобы агент не мог «чинить» нерелевантный код во время отладки, и /guard активирует оба сразу.

Ревью с вторым мнением пересекают харнесы: на Claude Code /codex отправляет работу в OpenAI Codex CLI для независимого ревью, оспаривания или консультации; на других харнесах /claude-code делает обратное. Каждый отчет идентифицирует провайдера, который фактически завершил ревью.

Практический рабочий процесс gstack

Вам не нужны все навыки gstack для каждого изменения. Разумный рабочий процесс фичи:

1. /office-hours
2. /plan-ceo-review
3. Создать план реализации
4. /plan-eng-review
5. Реализовать
6. /review
7. /qa
8. /ship

Какие навыки ревью добавить, зависит от того, для кого создано ПО:

Для тривиального исправления бага, как правило, достаточно сразу перейти к расследованию, реализации, ревью и тестам. Нейтральная по инструментам версия той же формы — спецификация, дизайн, задачи, реализация, верификация — находится в Рабочий процесс Spec-Driven Development от требований к коду. README проекта описывает запуск десяти-пятнадцати таких спринтов параллельно, каждый в собственном изолированном рабочем пространстве; структура спринта — это то, что, по словам проекта, не дает параллельным агентам стать источником хаоса.

Установка gstack

Текущая установка предполагает рабочее окружение Claude Code, Git, Bun v1.0+ и, на Windows, Node.js — у Bun есть известный баг с pipe-транспортом Playwright на Windows, поэтому браузерный сервер переключается на Node.js там. Если вы еще не настроили Claude Code, начните с обзора Claude Code в первую очередь. На macOS для браузерных навыков рекомендуется браузер Aside (macOS 15+); без него используется встроенный демон Chromium.

1. Проверьте свои зависимости: git --version и bun --version (инструментальная цепочка основана на Bun).

2. Склонуйте gstack в каталог навыков Claude:

   git clone --single-branch --depth 1 \
     https://github.com/garrytan/gstack.git \
     ~/.claude/skills/gstack
   

3. Запустите сценарий установки из склонированного каталога:

   cd ~/.claude/skills/gstack
   ./setup
   

   Установка устанавливает и генерирует компоненты, необходимые для поддерживаемых навыков, и собирает встроенный браузер; неудача установки Chromium — это best-effort, установка записывает причину, завершает регистрацию всех навыков и печатает, какие навыки затронуты.

4. Добавьте секцию ## gstack в CLAUDE.md проекта. Инструкции по установке проекта включают этот шаг, и именно это заставляет Claude Code маршрутизировать навыки: используйте /browse из gstack для всего веб-серфинга, никогда не используйте инструменты mcp__claude-in-chrome__* и перечислите доступные навыки.

5. Проверьте установку: убедитесь, что сгенерированные файлы присутствуют в склонированном каталоге, запустите сессию Claude Code и выполните /office-hours на тестовом проекте, чтобы подтвердить, что навык распознан.

Командный режим

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

(cd ~/.claude/skills/gstack && ./setup --team) && \
  ~/.claude/skills/gstack/bin/gstack-team-init required && \
  git add .claude/ CLAUDE.md && \
  git commit -m "require gstack for AI-assisted work"

required блокирует работу с ИИ в репозитории без gstack; замените на optional, чтобы подталкивать коллег, а не блокировать их. Файлы не вендорятся в репозиторий: каждая сессия Claude Code начинается с быстрой проверки авто-обновления (ограниченная до одного раза в час, устойчивая к сетевым сбоям, тихая), что устраняет расхождение версий в команде. Личная настройка улучшает одного разработчика; конфигурация на уровне репозитория создает общую инженерную конвенцию.

Другие харнесы, обновления и удаление

• Другие агенты: ./setup --host codex, --host opencode, --host cursor, --host factory, --host kiro, --host slate, --host openclaw и --host hermes устанавливают навыки в собственный каталог навыков каждого агента. 2КБ digest с только инструкциями в agents-digest/gstack-AGENTS.md покрывает агентов, которые только читают файлы правил.
• Именование команд: навыки регистрируются с короткими именами по умолчанию (/qa, /review); ./setup --prefix переключает на именованные пространства (/gstack-qa), что важно, если вы запускаете другие пачки навыков наряду с gstack.
• Обновления: повторно запустите ./setup после git pull (обязательно на Windows, где установки являются копированием файлов), или используйте навык /gstack-upgrade; установка auto_upgrade: true в ~/.gstack/config.yaml автоматически поддерживает установку в актуальном состоянии.
• Телеметрия по умолчанию выключена и спрашивает разрешение при первом запуске. Если вы разрешаете, она отправляет имя навыка, длительность, успех/сбой, версию gstack и ОС — никогда не код, пути к файлам, имена репозиториев или промпты. gstack-config set telemetry off отключает это в любой момент.
• Удаление: ~/.claude/skills/gstack/bin/gstack-uninstall удаляет навыки, символические ссылки, состояние ~/.gstack/, локальное состояние проекта, браузерные демоны и регистрации хуков.

Проверка установки и исправление частых сбоев

• ./setup не сработало — убедитесь, что Bun в вашем PATH с помощью bun --version; сгенерированные компоненты собираются инструментом Bun.
• Навыки не распознаются Claude Code — убедитесь, что клон действительно находится в ~/.claude/skills/gstack, что в CLAUDE.md проекта есть секция gstack, и повторно запустите ./setup.
• /browse сообщает NEED_ASIDE или ASIDE_NOT_RUNNING — зонд говорит вам, что он будет использовать fallback-браузер. Это нормально на Linux и Windows; на macOS это означает, что Aside не открыт или не авторизован.
• Fallback-браузер не работает — cd ~/.claude/skills/gstack && bun install && bun run build.
• Устаревшая установка после обновления — запустите /gstack-upgrade, или установите auto_upgrade: true в ~/.gstack/config.yaml.

Попробовать gstack без внедрения всего

Используйте gstack на реальной, но не критичной фиче, а не мигрируйте весь свой процесс разработки. Быстрый старт проекта — та же проба, и она заканчивается фразой «остановитесь здесь»:

1. /office-hours — определение проблемы
2. /plan-ceo-review — продуктовое рассуждение
3. /review — инженерная верификация, после реализации
4. /qa — верификация в рантайме, для веб-проектов

Если эти этапы выявят находки, которые ваш обычный рабочий процесс Claude Code пропускает, остальная часть системы заслуживает изучения; если они в основном производят дополнительный текст, не изменяя инженерных решений, принятие всего стека, вероятно, не поможет.

Что gstack делает хорошо

Разделенные инженерные роли. Вместо одной гигантской инструкции «будь старшим инженером», продуктовая стратегия, архитектура, UX, QA, безопасность и инженерия релизов получают свой собственный режим рассуждений.

Верификация, а не только генерация. Ревью, браузерное QA с генерацией регрессионных тестов, аудиты безопасности, бенчмаркинг и цепочка ship-deploy-canary — первоклассные рабочие процессы в gstack, а не необязательные после main.

Инспектируемость. Большая часть поведенческого слоя — это обычные Markdown-файлы, которые разработчики могут читать и модифицировать, в отличие от внутренних рабочих процессов проприетарного автономного агента. Репозиторий также предоставляет инструменты аудита для самого стека: gstack-context-bill сообщает, сколько токенов стоит установленное дерево навыков, а gstack-egress пишет receipt с цепочкой хэшей для каждой отправки за пределы машины, включая телеметрию.

Командная инфраструктура. Навыки могут кодировать инженерные конвенции — вместо ввода

Не забудь проверить совместимость API, запустить интеграционные тесты,
проверить консоль браузера и обновить changelog.

в каждой сессии, требования живут в повторяемом рабочем процессе, а командный режим делает этот рабочий процесс требованием репозитория.

Где gstack может быть избыточным

gstack намеренно Opinionated (убежден), и это ограничивает его применимость: зрелая организация может уже иметь процедуры ревью архитектуры, инструменты релизов, гейты CI, автоматизацию QA, сканирование безопасности, конвенции ADR, шаблоны спецификаций и политики ревью кода, и добавление еще одной полной методологии сверху создает дублирование, а не ясность.

Также есть стоимость контекста и токенов: каждый дополнительный этап ревью добавляет инспекцию репозитория, рассуждения модели и потенциально больше внешних вызовов модели. Цель — минимальный надежный процесс, необходимый для шипинга корректного ПО, а не максимальное количество ИИ-ревью; gstack-context-bill может количественно оценить, сколько на самом деле стоит ваш установленный набор навыков за сессию, прежде чем вы решите, сколько его сохранять.

gstack лучше всего работает как набор инструментов, рабочие процессы которого вы выбираете и адаптируете, а не как церемония для каждого коммита.

Альтернативы и комбинации с gstack

Ближайшие альтернативы и слой, который каждый занимает:

gstack + Superpowers: дисциплина реализации внутри ролей

Оба — фреймворки навыков, поэтому они больше всего перекрываются. Разделение труда при их комбинации: gstack предоставляет окружающие роли — продукт, дизайн, QA, релиз — тогда как Superpowers предоставляет дисциплину внутри фазы реализации (TDD, планирование до реализации, систематическая отладка, subagent-ревью). Установите оба набора навыков, затем обрежьте перекрывающиеся навыки, чтобы агент никогда не видел два противоречащих указания для одной и той же фазы; если имена команд конфликтуют, установите gstack с ./setup --prefix, чтобы его навыки регистрировались как /gstack-* и сосуществовали с другой пачкой. Детали установки и рабочего процесса в быстром старте Superpowers.

gstack + OpenSpec: долговечные спецификации, живые ревью

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

Конкретная последовательность: запустите /office-hours и /plan-ceo-review, зафиксируйте результат как изменение OpenSpec, реализуйте на его основе, затем запустите /review и /qa. Обратите внимание, что gstack также предоставляет свой собственный навык /spec, который архивирует спецификации под ~/.gstack; если OpenSpec владеет спецификацией, держите /spec из gstack вне цикла, чтобы два не разошлись. Быстрый старт OpenSpec подробно описывает цикл explore-propose-apply-archive.

gstack + GitHub Spec Kit: выберите один планировочный каркас

Базовый рабочий процесс Spec Kit — это последовательность явных этапов — constitution, specify, plan, tasks, implement, converge — и он расширился в отладку, оценку идей, расширения, пресеты и интеграции. Поскольку и Spec Kit, и gstack центрируют этап планирования, запуск обоих полных рабочих процессов дублирует работу. Если важна прослеживаемость требований и формальные этапы, дайте Spec Kit владеть каркасом спецификации и используйте gstack для тех слоев, которые Spec Kit не принуждает — продуктовое ревью, ревью дизайна, браузерное QA и шипинг. Более широкое сравнение spec-ориентированных конфигураций, включая Kiro и Claude Code, в GitHub Spec Kit vs Kiro vs Claude Code SDD Workflows.

BMAD и Ruflo: разные оси

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

Ruflo нацелен на мультиагентную оркестрацию: координированные рабочие узлы, общая память, рои. gstack применяет несколько специализированных перспектив к одному инженерному рабочему процессу; платформа оркестрации применяет несколько исполняющих агентов к одной инженерной цели. Граница размывается — gstack может вызывать внешние инструменты и дополнительные модели, а оркестраторы могут реализовывать структурированные инженерные роли — но решение независимо: если проблема в том, что агент пропускает инженерную дисциплину, фреймворк навыков — прямое исправление; если она в том, что десять агентов работают параллельно по многим задачам и репозиториям, оркестратор находится выше рабочего процесса, похожего на gstack, а не заменяет его.

Кастомные навыки: самый настраиваемый слой

Вы также можете пропустить фреймворк полностью и создать небольшой набор навыков для процедур, которые ваша команда уже выполняет:

skills/
  architecture-review/
  api-review/
  database-migration-review/
  incident-analysis/
  release-check/
  security-review/

Каждый навык кодирует организационно-специфические знания, которые универсальный фреймворк не может знать. Навык миграции базы данных может требовать анализа отката, анализа блокировок таблиц, ревью влияния на индексы, оценки длительности миграции, порядка деплоя и совместимости с предыдущей версией приложения; навык ревью API может требовать обратной совместимости, проверок аутентификации, согласованности пагинации, анализа идемпотентности, поведения rate-limit и изменений OpenAPI. Практический путь: начните с навыков gstack, которые вы действительно используете, скопируйте их структуру в собственный каталог skills/ и перепишите проверки вокруг ваших конвенций.

Четыре слоя: Навыки, Спецификации, Методологии, Оркестраторы

Четыре слоя покрывают большинство этих инструментов, и они показывают, как вышеперечисленные комбинации складываются:

Навыки отвечают на вопрос «как должен вести себя агент?»

gstack, Superpowers и кастомные навыки агента.

Системы спецификаций отвечают на вопрос «что именно мы строим?»

OpenSpec и GitHub Spec Kit; базовые концепции и терминология spec-ориентированного развития определены в Что такое Spec-Driven Development?.

Методологии отвечают на вопрос «как проект должен двигаться от идеи к ПО?»

BMAD, Superpowers и части gstack.

Оркестраторы отвечают на вопрос «как несколько агентов должны выполнять работу?»

Ruflo и другие мультиагентные рантаймы.

Слои комбинируются; среда разработки может содержать все четыре:

gstack уже пересекает несколько из этих границ.

Стоит ли использовать gstack?

README проекта описывает аудиторию как технических фаундеров и CEO, которые все еще хотят шипить, первых пользователей Claude Code, которые хотят структурированные роли, а не пустой промпт, и технических лидов и staff-инженеров, которые хотят строгое ревью, QA и автоматизацию релизов для каждого PR. gstack стоит попробовать, если вы интенсивно используете агентов для программирования, и ограничивающим фактором больше не является сама генерация кода. Типичные симптомы:

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

Если ваша автоматизация уже обеспечивает сильные детерминистические гейты, а агент обрабатывает только малые, четко специфицированные задачи, gstack добавляет мало.

gstack и направление ИИ в разработке ПО

Сдвиг, в котором находится gstack, отслеживается в поколениях: дополнения кода (2022-2023), агенты для программирования (2024-2025), спецификации и рабочие процессы агентов (2025-2026) и программируемые ИИ-инженерные организации. Продукты будут меняться, но модель остается одной компонентой; качество инженерии все больше зависит от окружающего систем:

• персистентные спецификации
• повторяемые навыки
• знание репозитория
• доступ к браузеру
• тесты
• детерминистические инструменты
• циклы ревью
• средства контроля безопасности
• память
• границы человеческого утверждения
• оркестрация

Заключение

gstack — это инженерный процесс вокруг агента для программирования, упакованный как инспектируемые, версионно-контролируемые навыки, и его ценность заключается в принуждении этого процесса к агенту, а не в каком-либо отдельном навыке.

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

Ссылки

• репозиторий gstack — исходники, определения навыков и установка
• подробный разбор навыков gstack — философия, примеры и рабочий процесс для каждого навыка
• браузер Aside — браузер, которым gstack управляет в первую очередь на macOS
• репозиторий Superpowers — исходники, навыки и манифесты плагинов
• репозиторий OpenSpec — исходники, доки и пакет CLI
• документация GitHub Spec Kit — официальное руководство по рабочему процессу Spec Kit
• репозиторий BMAD-METHOD — адаптивная ИИ-движимая Agile-методология
• репозиторий Ruflo — платформа мультиагентной оркестрации