Гарри Тан выложил свой Claude Code: 23 инструмента-роли и 139 тыс. звёзд

Знакомая картина: вы просите ИИ-агента «сделать фичу», и он в одном потоке придумывает продукт, рисует интерфейс, пишет код, сам себя хвалит и забывает про документацию. Результат обычно средний сразу по всем пунктам. Репозиторий garrytan/gstack пытается лечить именно это, и сегодня он снова в дневном топе GitHub Trending: 139 039 звёзд всего и 285 за последние сутки.

Что это за набор

Garry Tan позиционирует gstack как свою точную настройку Claude Code. В описании проекта сказано, что это 23 «категоричных» (opinionated) инструмента, которые работают как CEO, дизайнер, инженерный менеджер, релиз-менеджер, инженер по документации и QA. Язык проекта — TypeScript.

Важная оговорка: мы опираемся на описание репозитория и его метрики. Построчный разбор каждого из 23 инструментов здесь не приводится, и перед внедрением его стоит сделать самостоятельно.

Почему роли работают лучше общего промпта

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

Представьте типичный день. Вы хотите добавить в сервис экран настроек. В ролевой схеме порядок может быть таким:

• «CEO» проверяет, нужна ли фича вообще и что именно в ней главное;
• «дизайнер» описывает состояния экрана и пограничные случаи;
• «инженерный менеджер» режет задачу на шаги;
• «QA» отдельно пытается сломать результат;
• «релиз-менеджер» и «редактор документации» закрывают хвосты: версию, список изменений, README.

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

Почему это обсуждают

Первая причина очевидна: имя автора. Когда глава крупного стартап-акселератора показывает, как именно он работает с агентом, это интересно как рабочий артефакт, а не как теория. Вторая причина глубже: сообщество устало от абстрактных разговоров про агентов и хочет видеть конкретные конфигурации, которые можно скопировать и запустить.

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

Ограничения

Описание честно говорит, что инструменты «категоричные». Это значит, что внутри зашиты чужие вкусы: как должен выглядеть хороший релиз, что считать достаточной документацией, насколько жёстким должен быть QA. Для команды с другим стеком, другими соглашениями или регуляторными требованиями часть правил придётся переписать.

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

Что делать на практике

Не устанавливайте набор целиком на рабочий репозиторий в первый же день. Лучше так:

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

Продактам и основателям стоит посмотреть на gstack с другой стороны: как на шаблон процесса. Даже если вы не используете сам код, вопрос «какие роли в моей разработке с агентом пока никто не играет» полезен. Чаще всего это именно проверка качества и релизная гигиена.

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