Source: https://aiprimetech.io/ru/blog/gstack-claude-code-setup-guide/ 15 июл., 2026 · 7 мин · Инструменты # gstack для Claude Code: как на самом деле работает процесс с 23 агентами A Автор: [AI Prime Tech](https://aiprimetech.io/ru/) · При участии ИИ Пул-реквест с 14 файлами может пройти модульные тесты и всё же оказаться неудачным по трём совершенно разным причинам: поведение продукта описано недостаточно чётко, интерфейс неудобен, а в примечаниях к выпуску пропущен шаг миграции. Один запуск Claude Code с запросом «проверь этот PR» сводит все эти вопросы в один перегруженный диалог. gstack использует более жёстко заданный подход. Его 23 ролевых инструментов разделяют процесс выпуска ПО на планирование, проектирование, реализацию, ревью, проверку качества в браузере, подготовку релиза и документирование. Вместо того чтобы просить универсального помощника по программированию импровизировать процесс, вы вызываете последовательность специализированных рабочих процессов Claude Code, таких как /plan-ceo-review, /plan-eng-review, /review, /qaи /ship. Это различие важно. gstack — не просто каталог полезных промптов, а его «23 агентов» — не 23 автономных исполнителей, постоянно координирующих действия в фоне. Это ролевые навыки Claude Code, которые вызываются в определённые моменты инженерного процесса. Их ценность определяется задаваемой ими моделью работы; она же создаёт большую часть накладных расходов. ## gstack для Claude Code — операционная система, а не набор промптов Полезная мысленная модель для gstack для Claude Code — это инженерная операционная система поверх Claude Code. Каждый инструмент задаёт Claude роль, процедуру и ожидаемые результаты. Вместе эти инструменты закрепляют определённые представления о том, как ПО должно проходить путь от идеи до продакшена. Общий промпт может выглядеть так: ``` Review my implementation plan. ``` Рабочий процесс на основе ролей ставит более узкий вопрос: ``` /plan-eng-review ``` Этот навык может предписывать Claude анализировать архитектуру, зависимости, возможные отказы, тестируемость, риски внедрения и последовательность реализации. Навык планирования, ориентированный на продукт, может проверять тот же план с точки зрения ценности для пользователей и объёма работ. Навык, ориентированный на дизайн, может ставить под сомнение детали взаимодействия, а не границы компонентов бэкенда. Разница — в воспроизводимости. Участникам команды не нужно помнить промпт для ревью длиной в 40 строк или придумывать собственный контрольный список. Процедура заложена в навыке. Компромисс не менее важен: gstack привносит в ваш репозиторий чужую процедуру. Он исходит из того, что несколько этапов ревью, отдельная проверка качества и структурированная работа над релизом оправдывают затраты контекста и времени. Это часто уместно для изменений в рабочей системе, но избыточно для исправления опечатки или внутреннего скрипта из пары строк. ## Что на самом деле охватывают 23 инструментов на основе ролей Точный состав инструментов в репозитории может меняться, поэтому я считаю файлы из текущей рабочей копии SKILL.md авторитетным источником, а не полагаюсь на скриншоты или описания при запуске проекта. Ключевой принцип архитектуры — разделение обязанностей. | Этап поставки | Примеры инструментов | Что поручают Claude | Основное ограничение | Планирование продукта | /plan-ceo-review, /office-hours | Критически оценить проблему, ценность для пользователей, объём работ и продуктовые допущения | Продуктовые решения по-прежнему зависят от предоставленных сведений о клиентах | Инженерное планирование | /plan-eng-review | Проверить архитектуру, потоки данных, граничные случаи, тестирование и внедрение | Невозможно проверить недокументированные ограничения инфраструктуры | Дизайн | /plan-design-review, /design-consultation | Проверить структуру взаимодействия, визуальные решения и удобство использования | Текст и скриншоты дают меньше информации, чем наблюдение за реальными пользователями | Контроль реализации | /careful, инструменты защиты или заморозки изменений | Ограничить рискованные правки и удерживать работу в заявленных границах | Ограничения могут замедлять обоснованные изменения, затрагивающие несколько частей системы | Ревью кода | /review | Проверить изменения на дефекты, регрессии, проблемы безопасности и недостающие тесты | Объёмные изменения всё равно могут превышать практические возможности внимательного ревью | Проверка качества во время выполнения | /qa, /browse | Протестировать приложение через браузер и проверить его фактическое поведение | Охват проверки определяется настройкой среды и тестовыми данными | Выпуск | /ship | Выполнить проверки перед релизом и согласовать шаги создания коммита или поставки | Разрешения на операции с Git и развёртывание требуют осознанного контроля | Документация | /document-release, /retro | Зафиксировать поведение выпущенной версии, контекст релиза и полученные уроки | Сгенерированный текст необходимо сверять с итоговой системой Именно поэтому название «набор промптов» преуменьшает возможности 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 ./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 инструментов в работу команды с первого дня. Начните с тех мест, где ваш существующий процесс теряет больше всего информации. Разумная матрица оценки выглядит так: | Проблема команды | С чего начать | Что пока отложить | Планы не учитывают граничные случаи | /plan-eng-review | Полная последовательность дизайна и выпуска | Изменения интерфейса вызывают незаметные регрессии | /browse, /qa, /plan-design-review | Рабочие процессы продуктовой стратегии | Ревью проводятся непоследовательно | /review | Автоматизированный выпуск | Релизам не хватает контекста | /document-release, /retro | Браузерные инструменты | Claude вносит слишком широкие правки | /careful и средства ограничения объёма работ | Внедрение сквозного рабочего процесса Примените выбранную часть инструментов к нескольким реальным изменениям и зафиксируйте: - Какие замечания привели к изменениям кода или объёма работ? - Какие замечания повторялись? - Сколько контекста пришлось повторять? - Оставались ли сгенерированные артефакты согласованными с реализацией? - Какие команды требовали разрешений, которые команда не предоставила бы в 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 и командам развёртывания. - Оценивайте полезные находки и предотвращённые дефекты, а не количество вызванных команд. - Внедряйте всю операционную систему только тогда, когда затраты на её процессы ниже потерь от сбоев, которые она предотвращает. [Программирование](/ru/blog/tag/coding/)[Claude](/ru/blog/tag/claude/)[Агенты](/ru/blog/tag/agents/)[Модели](/ru/blog/tag/models/) A [AI Prime Tech](https://aiprimetech.io/ru/) Этот блог публикует AI Prime Tech. Статьи готовятся с помощью ИИ; прежде чем полагаться на сведения, зависящие от версии, такие как идентификаторы моделей, цены и лимиты, сверяйте их с официальной документацией. Получите более дешёвый доступ к API Claude Один ключ API для Claude Opus 5.5, Sonnet 5, Haiku 4.5 и Fable 5.1, а также GPT-6 моделей. Оплата по мере использования, без подписки. [Получить ключ API →](/register) AI Prime Tech — независимый сторонний API-шлюз. Claude™ и Anthropic® — товарные знаки Anthropic, PBC. Связь с этой компанией или одобрение с её стороны не подразумеваются.