Garry Tan lança o gstack, sistema de workflow para o Claude Code com QA, revisão e release

Garry Tan publicou em código aberto o gstack, um conjunto de skills para o Claude Code que transforma o trabalho com um agente de IA para programação em um processo mais rígido e previsível. A ideia é simples: não misturar planejamento, revisão de engenharia, QA e release em um prompt interminável, e sim separá-los em modos distintos, com papéis claros.

O que é o gstack

O gstack não é um modelo novo nem mais um framework de agentes, mas uma camada de workflow sobre o Claude Code. O projeto empacota as etapas típicas da entrega de software em comandos separados e define para cada um uma mentalidade própria. Em vez de improvisar no estilo "faça a feature e se revise sozinho", o desenvolvedor recebe uma sequência de passos: primeiro a formulação de produto, depois o plano de engenharia, em seguida a revisão, a verificação no navegador e só então a preparação do release. Ou seja, o gstack tenta trazer ao desenvolvimento com IA disciplina de processo, não mágica.

"Eight opinionated workflow skills for

Claude Code" é como o próprio projeto se descreve.

A ideia central não é dar mais liberdade ao agente, mas o oposto: estreitar o contexto de cada tarefa. Segundo a descrição do projeto, isso deve reduzir as decisões fracas que surgem quando a mesma IA inventa a feature, escreve o código, testa a interface e decide se dá para soltar em produção. O gstack separa esses papéis e obriga a passar por eles em sequência, como se pessoas diferentes, com áreas de responsabilidade diferentes, trabalhassem na tarefa.

Oito modos de trabalho

No lançamento, o repositório tinha oito comandos principais, e cada um cuidava de uma parte do processo, e não de "tudo de uma vez". Essa é a principal aposta do gstack: a qualidade sobe não com uma inteligência nova, mas com disciplina em torno de um agente de programação que já existe. Um comando avalia a ideia de produto, outro a arquitetura e os testes, outro os riscos no código, e mais um cuida da última etapa antes do merge e do release.

• `/plan-ceo-review` — revisão de produto da ideia e das prioridades
• `/plan-eng-review` — arquitetura, data flow, edge cases e testes
• `/review` — busca por riscos em produção e problemas no código
• `/ship` — sincronização da branch, execução de testes e preparação do PR
• `/browse`, `/qa`, `/setup-browser-cookies`, `/retro` — navegador, QA, importação de cookies e retrospectiva

Essa divisão em papéis parece especialmente lógica diante de um problema típico da programação com IA: o agente escreve rápido o happy path, mas muitas vezes deixa passar cenários de borda, regressões e falhas de UX. No gstack, essas verificações ficam em modos separados, para não competir com a tarefa de "escrever código o mais rápido possível". Isso não garante a ausência de erros, mas aproxima o processo da prática comum de engenharia, em que design, implementação, verificação e publicação não são jogados em uma única etapa.

Navegador, QA e stack

A parte mais interessante do gstack não são as skills em markdown, mas o runtime de navegador persistente. Em vez de abrir um navegador novo a cada ação, o sistema sobe um daemon de Chromium headless de longa duração e conversa com ele por HTTP em localhost. Isso serve tanto à velocidade quanto à manutenção do estado entre os passos. Segundo os dados da descrição do projeto, a partida a frio da ferramenta de navegador leva cerca de 3–5 segundos, e as chamadas seguintes, depois da inicialização, levam aproximadamente 100–200 milissegundos. Assim, cookies, abas, localStorage e estado de login são mantidos entre os comandos.

Também importa como esse navegador se encaixa no fluxo de QA. O comando `/browse` permite que o agente entre no aplicativo, clique pela interface, tire screenshots e veja onde as coisas quebram. O `/qa` vai além: analisa o diff da branch, identifica as rotas afetadas e verifica justamente as páginas e os cenários que as mudanças poderiam ter prejudicado. No exemplo do repositório, esse modo analisou oito arquivos alterados, encontrou três rotas afetadas e as executou contra uma instância local do aplicativo, ou seja, ligou as mudanças de código ao comportamento real da interface.

Do lado técnico, o gstack também é pragmático. Para funcionar, exige Claude Code, Git e Bun 1.0+, e no momento da publicação o repositório usava Playwright e o pacote `diff`, com o comando `/browse` compilado como um binário executável à parte. O conjunto pode ser instalado em `~/.claude/skills/gstack` ou colocado em um `.claude/skills/gstack` local dentro do projeto, para que toda a equipe use o mesmo processo. Os autores explicam a escolha do Bun por motivos simples: binários compilados, acesso nativo ao SQLite, execução de TypeScript sem configuração extra e servidor HTTP embutido via `Bun.serve()`.

O que isso significa

O gstack é interessante não como "mais um conjunto de prompts", mas como uma tentativa de transformar a programação com IA em um pipeline repetível, com verificações em cada etapa. Se essa abordagem pegar, o mercado deve avançar não só rumo a modelos mais fortes, mas também a camadas operacionais mais rígidas por cima deles, com modos separados para planejamento, revisão, QA e release. A principal mudança é que a confiança na IA passa a ser construída não sobre as promessas do modelo, mas sobre etapas de verificação.