gstack для Claude Code: как на самом деле работает процесс с 23 агентами

gstack для Claude Code — операционная система, а не набор промптов

Полезная мысленная модель для gstack для Claude Code — это инженерная операционная система поверх Claude Code. Каждый инструмент задаёт Claude роль, процедуру и ожидаемые результаты. Вместе эти инструменты закрепляют определённые представления о том, как ПО должно проходить путь от идеи до продакшена.

Общий промпт может выглядеть так:

Review my implementation plan.

Рабочий процесс на основе ролей ставит более узкий вопрос:

/plan-eng-review

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

Разница — в воспроизводимости. Участникам команды не нужно помнить промпт для ревью длиной в 40 строк или придумывать собственный контрольный список. Процедура заложена в навыке.

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

Что на самом деле охватывают 23 инструментов на основе ролей

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

Именно поэтому название «набор промптов» преуменьшает возможности gstack. Результаты планирования используются при реализации; реализация создаёт набор изменений; ревью и проверка качества анализируют эти изменения; выпуск и документация оформляют результат.

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

Планирование намеренно избыточно

Продуктовое, инженерное и дизайнерское ревью пересекаются. Так задумано.

Рассмотрим предлагаемую функцию «экспорт всей активности клиентов»:

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

На практике такое разделение выявляет допущения, которые теряются внутри общего плана реализации. Цена — повторная загрузка контекста. Если план уже занимает 8,000 токенов, три этапа ревью могут обойтись дорого и привести к повторяющимся замечаниям.

Ревью и проверка качества — разные задачи

/review опирается прежде всего на свидетельства из кода: изменения, типы, тесты, места вызова и принятые в репозитории соглашения. /qa и /browse может собирать свидетельства поведения во время выполнения из самого приложения.

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

Практическая последовательность выглядит так:

/plan-eng-review
/careful
# Implement the approved plan in Claude Code
/review
/qa
/document-release
/ship

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

Установка gstack без слепого доверия

При типичной установке на уровне пользователя репозиторий размещают в каталоге навыков Claude Code и запускают его скрипт настройки:

git clone https://github.com/garrytan/gstack.git \
  ~/.claude/skills/gstack

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

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

find ~/.claude/skills/gstack \
  -name SKILL.md \
  -print |
  sort

find ~/.claude/skills/gstack \
  -name SKILL.md |
  wc -l

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

cd ~/.claude/skills/gstack
git status --short
git log -1 --oneline
sed -n '1,240p' setup

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

git clone https://github.com/garrytan/gstack.git vendor/gstack
cd vendor/gstack
git checkout <reviewed-commit-sha>
./setup

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

Ограничьте рабочий процесс разрешениями Claude Code

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

На уровне проекта файл .claude/settings.json может задать базовые ограничения:

{
  "permissions": {
    "allow": [
      "Bash(git status:*)",
      "Bash(git diff:*)",
      "Bash(npm test:*)",
      "Bash(npm run lint:*)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Bash(git push:*)",
      "Bash(git push --force:*)"
    ]
  }
}

Рассматривайте это как пример политики, а не универсальный файл, готовый к использованию без изменений. Адаптируйте команды к своему менеджеру пакетов, средству запуска тестов и версии Claude Code.

Явный запрет на git push особенно полезен во время оценки. /ship по-прежнему может проверять готовность к релизу, но окончательное действие, влияющее на внешнюю систему через сеть, остаётся за человеком. Когда команда разберётся в рабочем процессе, вы сможете решить, оправдано ли строго ограниченное разрешение на отправку изменений.

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

Начните с части инструментов, прежде чем внедрять всю систему

Я бы не вводил все 23 инструментов в работу команды с первого дня. Начните с тех мест, где ваш существующий процесс теряет больше всего информации.

Разумная матрица оценки выглядит так:

Примените выбранную часть инструментов к нескольким реальным изменениям и зафиксируйте:

• Какие замечания привели к изменениям кода или объёма работ?
• Какие замечания повторялись?
• Сколько контекста пришлось повторять?
• Оставались ли сгенерированные артефакты согласованными с реализацией?
• Какие команды требовали разрешений, которые команда не предоставила бы в CI?
• Понимали ли разработчики, когда вызывать каждую роль?

Накладные расходы на контекст — не теоретическая проблема. Каждой роли нужны состояние репозитория, требования и предыдущие решения. В отдельных сеансах могут теряться обоснования; в одном длинном сеансе могут накапливаться устаревшие допущения. Я храню утверждённый план в файле репозитория, например docs/plans/export-jobs.md, а затем указываю каждому рабочему процессу использовать этот артефакт. Постоянно хранимые файлы надёжнее ожидания, что контекст разговора будет служить памятью проекта.

Документированное поведение и рекламные заявления

Обоснованное утверждение состоит в том, что gstack предоставляет 23 инструментов Claude Code, ориентированных на роли, и рабочий процесс с заданным подходом, охватывающий жизненный цикл программного обеспечения. Это поведение можно проверить, прочитав установленные навыки и запустив их в тестовом репозитории.

Более широкие заявления — о резком увеличении объёма результатов, замене инженерной команды или сокращении недель работы до часов — остаются рекламными, пока не подтверждены в вашей среде. Результаты зависят от качества репозитория, покрытия тестами, неоднозначности задачи, выбора модели, разрешений и разработчика, контролирующего работу.

Текущая линейка моделей также не устраняет эти ограничения. Sonnet 4.6 может быть практичным вариантом по умолчанию для длительной работы над кодом, а Haiku 4.5 — подходить для более простых задач классификации или документирования. Контекст Fable 5 объёмом 1M может помочь при работе с очень большими массивами материалов, а gpt-5.6-sol предлагает ещё один вариант для инженерных задач в поддерживаемых средах. Ни одна из моделей не превращает ролевой промпт в проверенные знания о продукте или свидетельства из рабочей системы.

Практические рекомендации

• Рассматривайте gstack как процесс разработки с заданным подходом, реализованный через навыки Claude Code.
• Понимайте «23 агентов» как инструменты на основе ролей, а не как постоянно работающих исполнителей, которые автоматически координируют действия.
• Установите из репозитория, изучите setup, и закрепите проверенный коммит для использования командой.
• Начните с двух или трёх рабочих процессов, которые устраняют известные проблемы при поставке.
• Храните утверждённые планы и решения в файлах, чтобы у всех ролей был общий долговременный контекст.
• Разделяйте ревью кода и проверку качества во время выполнения: они выявляют разные классы сбоев.
• На время оценки ограничьте доступ к секретам, сеансам в продакшене, отправке изменений в Git и командам развёртывания.
• Оценивайте полезные находки и предотвращённые дефекты, а не количество вызванных команд.
• Внедряйте всю операционную систему только тогда, когда затраты на её процессы ниже потерь от сбоев, которые она предотвращает.