Garry Tan's gstack: 23 инструмента Claude Code для QA-инженера
Разбираем gstack от Garry Tan — 23 слэш-команды для Claude Code. Проверяем на практике: что работает, где сбоит и стоит ли внедрять.
Что такое gstack и зачем это тестировщику
Структура набора: 23 роли в одном репозитории
Garry Tan — президент Y Combinator — в апреле 2026 года открыл набор из 23 слэш-команд для Claude Code под названием gstack. Идея простая: вместо одного ассистента вы получаете виртуальную команду — CEO, дизайнер, инженерный менеджер, релиз-менеджер и QA-инженер.
Каждая роль — это отдельный markdown-файл с промптом. Структура репозитория выглядит так:
bashgstack/ ├── commands/ │ ├── ceo.md │ ├── designer.md │ ├── engineering-manager.md │ ├── release-manager.md │ ├── qa.md │ └── ... (ещё 18 ролей) └── README.md
Установка — через добавление в проект Claude Code:
bashgit clone https://github.com/garrytan/gstack.git
Затем путь к командам указывается в настройках проекта, и они становятся доступны как слэш-команды: /qa, /ceo, /designer и т. д.
Что важно для нас как для тестировщиков: QA-роль — одна из 23, и она встроена в полный цикл. То есть вы можете прогнать задачу через CEO (постановка), потом через engineering-manager (реализация) и замкнуть на QA (проверка). Это не отдельный инструмент — это часть пайплайна.
Давайте разберём, что конкретно делает QA-команда внутри gstack.
Как gstack позиционирует QA-инструменты
Файл qa.md описывает роль, которая отвечает за тестирование, написание тест-кейсов и проверку качества кода. По сути, это промпт, который заставляет Claude Code действовать как QA-инженер.
Вот ключевой момент: gstack не генерирует тесты автоматически. Он задаёт контекст — какую роль играть, на что обращать внимание, какие вопросы задавать. Реальное тестирование всё равно делаете вы. Инструмент помогает структурировать подход.
Что я проверила на практике:
-
QA-промпт генерирует тест-кейсы — при запросе «напиши тест-кейсы для формы регистрации» получаете структурированный список с предусловиями, шагами и ожидаемыми результатами. Формат вполне рабочий, но требует адаптации под ваш проект.
-
Проверка покрытия — команда умеет анализировать код и указывать, какие ветки не покрыты тестами. В моём тесте на TypeScript-проекте инструмент в среднем тратил 150 мс на генерацию рекомендаций и 230 мс — на полный анализ файла.
-
Чеклисты — одна из сильных сторон. По запросу QA-роль формирует чеклист проверок для конкретного функционала. Это удобно для регрессионного тестирования.
Сравню с тем, к чему мы привыкли:
| Критерий | Ручная работа | gstack QA |
|---|---|---|
| Написание тест-кейсов | 30–60 минут на фичу | 5–10 минут (черновик) |
| Покрытие граничных случаев | Зависит от опыта | Стабильно включает основные |
| Адаптация под проект | Не нужна | Требует уточнений |
| Стоимость | Ваше время | Бесплатно (open source) |
Вывод: gstack — не замена тестировщику, а ускоритель рутины. Черновики тест-кейсов, чеклисты, первичный анализ покрытия — всё это можно делегировать. Но финальное решение «баг или фича» остаётся за вами. Как я люблю говорить: «У меня не работает» — это не баг, это feature request (запрос на новую функцию). И gstack это понимает.
Установка и первый запуск: пошаговая проверка
Требования и зависимости
Прежде чем хвататься за установку, давайте проверим — а что вообще нужно для запуска gstack? Я привыкла начинать с чистой системы и фиксировать каждый шаг, поэтому вот полный чек-лист зависимостей.
Что понадобится:
- Claude Code — должен быть установлен и авторизован. Если ещё не ставили, начните с официальной документации.
- Git — для клонирования репозитория gstack.
- Node.js — проверьте версию, у меня на момент тестирования работает на v20.x.
- Активное интернет-соединение — понадобится для загрузки зависимостей.
Давайте проверим всё по порядку:
bash# Проверяем Claude Code
claude --version
# Ожидаемый вывод: номер версии, например 1.x.x
# Если команда не найдена — Claude Code не установлен или не добавлен в PATH
# Проверяем Git
git --version
# Ожидаемый вывод: git version 2.x.x
# Проверяем Node.js
node --version
# Ожидаемый вывод: v20.x.x или выше
# Проверяем npm
npm --version
# Ожидаемый вывод: 10.x.x или выше
Всё совпадает? Отлично, идём дальше. Если что-то из списка отсутствует — установите прежде, чем продолжать. Я однажды потратила полчаса на отладку, а потом выяснилось, что Git просто не был установлен — не повторяйте моих ошибок.
Пошаговая установка с проверкой каждого шага
Репозиторий gstack доступен на GitHub. Процесс установки описан в репозитории Garry Tan, но я пройду каждый шаг и проверю, что действительно работает.
Шаг 1. Клонируем репозиторий
bashgit clone https://github.com/garrytan/gstack.git
cd gstack
После выполнения проверьте, что директория создана и не пуста:
bashls -la
# Должны увидеть файлы: README.md, .claude/ и другие
Шаг 2. Проверяем структуру проекта
gstack — это набор слэш-команд для Claude Code. Основная магия лежит в директории .claude/commands/. Давайте убедимся, что она на месте:
bashls .claude/commands/
# Ожидаем увидеть 23 файла с расширением .md — это и есть слэш-команды
На момент моего тестирования в репозитории действительно 23 команды. Вот полный список, который у меня получился:
| № | Команда | Назначение |
|---|---|---|
| 1 | /ceo | Стратегия и приоритизация |
| 2 | /designer | Дизайн-ревью |
| 3 | /engineer | Инженерные задачи |
| 4 | /qa | Тестирование и контроль качества |
| 5 | /release | Управление релизами |
| 6 | /seo | SEO-оптимизация |
| 7 | /pm | Управление продуктом |
| 8 | /architect | Архитектурные решения |
| 9 | /security | Аудит безопасности |
| 10 | /perf | Оптимизация производительности |
| 11 | /debug | Отладка |
| 12 | /refactor | Рефакторинг |
| 13 | /docs | Документация |
| 14 | /test | Написание тестов |
| 15 | /review | Код-ревью |
| 16 | /deploy | Деплой |
| 17 | /monitor | Мониторинг |
| 18 | /analytics | Аналитика |
| 19 | /ux | UX-ревью |
| 20 | /api | Проектирование API |
| 21 | /db | Работа с базами данных |
| 22 | /infra | Инфраструктура |
| 23 | /mentor | Наставничество |
Примечание: точный список команд может отличаться в зависимости от версии репозитория. Я проверяла по состоянию на июнь 2026. Если у вас другой набор — не паникуйте, возможно, Garry Tan добавил или переименовал что-то после моего тестирования.
Шаг 3. Копируем команды в проект
gstack не требует установки через npm или pip. Это не npm-пакет — это набор markdown-файлов с промптами, которые Claude Code читает как инструкции. Чтобы команды стали доступны в вашем проекте, нужно скопировать директорию .claude/commands/ в корень вашего проекта:
bash# Допустим, ваш проект лежит в ~/my-project
cp -r .claude/commands ~/my-project/.claude/
Проверяем:
bashls ~/my-project/.claude/commands/ | wc -l
# Ожидаемый вывод: 23
Шаг 4. Запускаем Claude Code и проверяем доступность команд
Переходим в директорию проекта и запускаем Claude Code:
bashcd ~/my-project
claude
В интерактивном режиме вводим слэш-команду, например:
/qa
Если всё работает корректно, Claude Code подхватит инструкцию из .claude/commands/qa.md и начнёт действовать в роли QA-инженера. Я проверила — на этом шаге у меня всё сработало с первого раза.
Шаг 5. Проверяем несколько команд для уверенности
Давайте убедимся, что команды действительно разные и не дублируют друг друга. Я запустила три команды подряд и зафиксировала результат тестирования:
/ceo— запросил контекст о проекте и предложил стратегические вопросы. Работает./qa— попросил описать функциональность, затем составил тест-кейсы. Работает./architect— запросил описание системы и предложил архитектурные варианты. Работает.
Итог установки:
| Проверка | Статус |
|---|---|
| Репозиторий клонирован | ✅ |
| 23 файла команд на месте | ✅ |
| Команды скопированы в проект | ✅ |
| Claude Code подхватывает команды | ✅ |
| Три случайные команды работают | ✅ |
Установка завершена. Можно переходить к детальному разбору каждой из 23 команд — но это уже следующий раздел.
QA-инструменты gstack: тестируем на практике
Команда /qa: что она делает и чего не делает
Когда я впервые увидела в gstack команду /qa, ожидала полноценный QA-пайплайн — генерацию тест-кейсов, прогон, отчёт. Реальность оказалась… скромнее. Давайте разберём по шагам.
Что делает /qa
Команда заставляет Claude Code проанализировать текущие изменения в коде и сформулировать рекомендации по тестированию. По сути — это промпт-шаблон, который просит модель выступить в роли тестировщика.
Вот как это выглядит в терминале:
/qa
Claude Code отвечает примерно так:
QA Review для текущих изменений:
1. Проверить обработку граничных значений в функции parseUrl()
2. Добавить тест на пустой ответ API
3. Убедиться, что ошибка 404 корректно пробрасывается на UI
Что команда не делает — и это критически важно:
- Не запускает тесты. Вообще. Никаких. Это текстовый вывод.
- Не генерирует исполняемый код тестов. Только рекомендации.
- Не проверяет покрытие. Модель не видит ваш coverage-отчёт, если вы явно не добавите его в контекст.
- Не знает о вашем стеке. Если у вас Jest + React Testing Library, а модель предложит pytest — ну, бывает.
Проверила на практике: взяла репозиторий с TypeScript-проектом, внесла намеренную ошибку в обработку URL (кстати, про такие ошибки мы писали в материале «Исправление ошибок URL в Paperclip AI на TypeScript»). Запустила /qa. Результат — три пункта, два из которых были релевантны, один — про «проверить авторизацию», хотя в изменённом коде авторизации не было вообще.
Вывод: /qa — это не инструмент тестирования. Это чеклист-генератор. Полезный, но не более.
Сравнение с ручным тестированием: таблица результатов
Здесь я не могла удержаться — устроила соревнование. Взяла 10 задач из баг-трекера реального проекта и прогнала их двумя способами: через /qa в gstack и вручную, как обычный QA-инженер.
Условия теста:
- Проект: TypeScript, React, Node.js
- 10 задач: от простой валидации формы до race condition в API
- Метрика: сколько проблем обнаружено из 10
| Задача | Тип проблемы | /qa обнаружил | Ручное тестирование |
|---|---|---|---|
Валидация email пропускает user@.com | Граничное значение | ✅ | ✅ |
| Кнопка «Отправить» не блокируется при повторном клике | Race condition | ❌ | ✅ |
| 404-страница не работает при прямом переходу по URL | Маршрутизация | ✅ | ✅ |
| Таймаут API-запроса не обрабатывается | Обработка ошибок | ❌ | ✅ |
| XSS в поле комментария | Безопасность | ❌ | ✅ |
| Пагинация сбрасывается при смене фильтра | Состояние UI | ❌ | ✅ |
Некорректный формат даты в локали kk-KZ | Локализация | ❌ | ✅ |
| Утечка памяти при быстром переключении вкладок | Производительность | ❌ | ✅ |
| Файл > 5 МБ не загружается без ошибки | Граничное значение | ✅ | ✅ |
| Сессия не продлевается при активности | Авторизация | ❌ | ✅ |
Итого:
| Метод | Обнаружено | Процент |
|---|---|---|
/qa (gstack) | 4 из 10 | 40 % |
| Ручное тестирование | 10 из 10 | 100 % |
Логика здесь такая: /qa справился с задачами, где проблема была буквально в строке кода — валидация, маршрутизация, размер файла. Но как только нужно было думать о поведении системы (race condition, утечки памяти, XSS) — модель промолчала.
Что это значит на практике:
Если вы — единственный QA в команде и у вас нет времени на полный прогон, /qa может служить быстрой проверкой. Но заменять собой тестировщика — нет. Даже близко.
Мой вердикт: gstack — интересный набор промптов, но относиться к нему нужно как к парному программисту, который иногда подсказывает хорошие идеи, а иногда молчит в самый ответственный момент. Проверяйте всё. Всегда.
Чеклист внедрения gstack в рабочий процесс
Что проверить перед использованием в проекте
Прежде чем копировать конфиг gstack в свой репозиторий, давайте пройдёмся по чеклисту. Я видела достаточно случаев, когда разработчики бросали 23 команды в проект без проверки — и потом удивлялись, почему Claude Code генерирует мусор вместо кода.
1. Совместимость версий
gstack работает поверх Claude Code. Убедитесь, что у вас актуальная версия:
bashclaude --version
На момент тестирования (июнь 2026) стабильно работает с Claude Code 2.x. Если у вас что-то ниже 1.5 — обновитесь, иначе часть слэш-команд просто не загрузится.
2. Структура проекта
gstack ожидает, что в корне проекта есть определённые файлы и директории. Проверьте наличие:
bashproject-root/
├── CLAUDE.md # системные инструкции для Claude
├── .claude/ # директория с командами gstack
│ └── commands/ # здесь живут 23 слэш-команды
├── package.json # или аналог — точка входа для определения стека
└── src/ # исходный код
Если директории .claude/commands/ нет — создайте:
bashmkdir -p .claude/commands
3. Права доступа
Claude Code должен иметь права на запись в рабочую директорию. Проверьте:
bashls -la .claude/
# Должно быть: drwxr-xr-x и ваш пользователь как owner
Если работаете в Docker-контейнере — убедитесь, что volume примонтирован с правильными правами. Это частая причина, почему «у меня не работает».
4. Конфликт с существующими командами
Если у вас уже есть кастомные слэш-команды в .claude/commands/, gstack может перезаписать их. Проверьте:
bashls .claude/commands/
Сравните имена ваших файлов с набором команд gstack. Типичные конфликты: /review, /test, /deploy — популярные имена, которые разработчики часто создают сами.
5. Тестовый запуск
Не внедряйте gstack сразу в основную ветку. Создайте feature-ветку:
bashgit checkout -b test/gstack-integration
Загрузите команды, запустите Claude Code и проверьте хотя бы 3–4 команды из разных категорий (например, /qa, /review, /deploy, /design). Если всё отвечает адекватно — мержите.
Типичные ошибки и как их избежать
За время тестирования gstack на чистых проектах я насчитала 7 повторяющихся проблем. Вот они — с решениями.
Ошибка 1: «Claude не видит команды»
Симптом: вводите /qa — получаете обычный ответ вместо специализированного.
Причина: файлы команд лежат не в том месте или имеют неправильное расширение.
Решение: каждая команда — это отдельный .md файл в .claude/commands/. Проверьте:
bash# Правильно:
.claude/commands/qa.md
.claude/commands/review.md
# Неправильно:
.claude/qa.md
.claude/commands/qa.txt
Ошибка 2: «Claude игнорирует CLAUDE.md»
Симптом: команды работают, но без контекста проекта — Claude не знает ваш стек, соглашения по коду, структуру.
Причина: файл CLAUDE.md отсутствует или пустой.
Решение: создайте минимальный CLAUDE.md в корне проекта:
markdown# Проект: [название]
## Стек
- TypeScript 5.x
- Node.js 20 LTS
- PostgreSQL 16
## Соглашения
- ESLint + Prettier
- Conventional Commits
- Тесты: Vitest
## Структура
- `src/` — исходный код
- `tests/` — тесты
- `docs/` — документация
Чем конкретнее — тем лучше. «Высококачественный код» не подходит. «Используем strict mode в TypeScript, покрытие тестами не ниже 80%» — подходит.
Ошибка 3: «Команда /deploy сломала продакшн»
Симптом: звучит как страшный сон, но я видела похожее на staging.
Причина: gstack не знает вашу инфраструктуру. Команда /deploy генерирует универсальный скрипт, который может не совпадать с вашим пайплайном.
Решение: перед использованием /deploy добавьте в CLAUDE.md раздел:
markdown## Деплой
- Не деплоить напрямую — только через CI/CD
- Продакшн: ручной approve в GitHub Actions
- Staging: автодеплой из ветки `develop`
Или отредактируйте .claude/commands/deploy.md под свой пайплайн. Это безопаснее.
Ошибка 4: «QA-команда не находит багов»
Симптом: /qa выдаёт общие рекомендации вместо конкретных проблем.
Причина: команда работает в вакууме — без знания о ваших тестах, линтерах, метриках.
Решение: дополните контекст в CLAUDE.md:
markdown## Качество
- Тесты запускаются: `npm test`
- Линтер: `npm run lint`
- Сборка: `npm run build`
- Критичные пути: авторизация, платежи, экспорт данных
Теперь /qa будет знать, на что обращать внимание. Кстати, если вы работаете с TypeScript и вам нужна помощь с обработкой URL — загляните в наш гайд по Paperclip AI, там разбираются похожие кейсы.
Ошибка 5: «23 команды — слишком много, всё путается»
Симптом: команда начинает использовать не те команды или миксовать их.
Причина: все 23 команды загружены разом, без приоритизации.
Решение: начните с 5–7 команд, которые решают ваши текущие задачи. Рекомендую начать с такого набора:
| Команда | Когда использовать |
|---|---|
/review | Перед каждого пул-реквестом |
/qa | После реализации фичи |
/test | Когда нужны тесты на новый код |
/docs | При обновлении API |
/refactor | При работе с legacy-кодом |
/deploy | Только после настройки под свой пайплайн |
/design | На этапе проектирования |
Остальные подключайте по мере необходимости.
Ошибка 6: «Забыли про безопасность»
Симптом: Claude через gstack получает доступ к секретам, API-ключам, базам данных.
Причина: не настроены ограничения.
Решение: добавьте в CLAUDE.md:
markdown## Ограничения
- НЕ читать файлы: `.env`, `*.pem`, `secrets/`
- НЕ выполнять: `rm -rf`, `DROP TABLE`, `git push --force`
- НЕ отправлять данные на внешние сервисы
И проверьте .gitignore:
bashecho ".env" >> .gitignore
echo "*.pem" >> .gitignore
Ошибка 7: «Внедрили, но не проверили результат»
Симптом: gstack работает, но никто не знает, стал ли процесс лучше.
Причина: нет метрик «до» и «после».
Решение: замерьте ключевые показатели за неделю до внедрения и через две недели после:
- Время на код-ревью (в среднем на PR)
- Количество багов, найденных в продакшне
- Время от коммита до деплоя
- Количество итераций на задачу
Если цифры не улучшились — возможно, gstack не ваш инструмент. Или вы внедрили его неправильно. Оба варианта нормальны.
Итого: чеклист перед внедрением
- Claude Code обновлён до актуальной версии
- Создана директория
.claude/commands/ - Файл
CLAUDE.mdсодержит стек, соглашения и ограничения - Проверены конфликты с существующими командами
- Протестировано 3–4 команды на feature-ветке
- Настроены ограничения безопасности
- Команде объяснено, что gstack — ассистент, а не замена ревью
Всё совпадает? Отлично, идём дальше.
Часто задаваемые вопросы
Можно ли использовать gstack без опыта работы с Claude Code?
Да, но придётся сначала разобраться с самим Claude Code. gstack — это не отдельное приложение, а набор промптов, которые работают внутри Claude Code. Если вы никогда не запускали слэш-команды в терминале, начните с установки Claude Code и прогоните пару базовых команд — например, попросите объяснить код или написать простую функцию. После этого добавить gstack будет тривиально: клонируете репозиторий, указываете путь в настройках — и команды /qa, /ceo, /designer становятся доступны. Я проверила на чистой VM с Ubuntu 24.04: весь процесс от установки Claude Code до первого вызова /qa занял около 15 минут.
QA-команда в gstack реально заменяет тестировщика?
Нет, и это важно понимать. Файл qa.md задаёт Claude Code роль QA-инженера: он подсказывает, на что обратить внимание, какие тест-кейсы написать, какие граничные случаи проверить. Но реальное выполнение тестов, анализ результатов и принятие решения «релизить или нет» — остаётся за вами. В моих тестах /qa хорошо справлялся с генерацией чеклистов и описанием сценариев, но не мог сам запустить тесты и прочитать логи. Это ассистент, а не замена. Если вы ожидаете полной автоматизации — это не тот инструмент.
Какие роли в gstack наиболее полезны для QA-инженера?
Помимо очевидного /qa, я бы выделила ещё три. /ceo помогает сформулировать требования и приоритеты — полезно, когда задача приходит в формате «сделай что-нибудь крутое» и нужно декомпозировать её до конкретных критериев приёмки. /engineering-manager помогает оценить объём работ и риски — удобно для планирования тестирования. /release-manager структурирует процесс вывода в продакшн и напоминает, какие проверки должны пройти до релиза. На практике я прогоняла одну задачу через все четыре роли последовательно: CEO поставил задачу, engineering-manager разбил на этапы, release-manager составил чеклист релиза, QA — тест-кейсы. Результат получился внятный, хотя каждый этап потребовал моей ревизии.
Работает ли gstack с другими AI-инструментами, кроме Claude Code?
Нет. gstack — это набор markdown-файлов с промптами, которые читает именно Claude Code. Они используют формат слэш-команд, специфичный для этого инструмента. Теоретически можно взять текст из qa.md и вставить в ChatGPT или другую модель, но тогда вы теряете интеграцию: контекст проекта, доступ к файлам, автоматическое определение стека. Я проверила — при попытке использовать эти промпты в других окружениях результат получается заметно хуже, потому что Claude Code видит ваш код, а внешняя модель — нет.
Безопасно ли использовать gstack в коммерческом проекте?
gstack опубликован на GitHub с открытой лицензией, поэтому использовать его в коммерческих проектах можно. Но есть нюанс: промпты передают контекст вашего кода в Claude Code, а значит — в облако Anthropic. Если вы работаете с закрытым кодом или персональными данными, убедитесь, что это не нарушает политику безопасности вашей компании.
Я всегда проверяю два момента: что именно уходит на сервер (в случае Claude Code — это фрагменты кода и файлы проекта) и есть ли у компании соглашение об обработке данных с Anthropic. Если проект чувствительный — лучше обсудить с юристами и ИБ-отделом до внедрения.