Harry Tan lançou o gstack — um sistema de workflow para Claude Code com QA, revisão e release

Harry Tan lançou gstack como código aberto — um conjunto de skills para Claude Code que transforma o trabalho com um agente de IA para código em um processo mais rigoroso e previsível. A ideia é simples: em vez de misturar planejamento, revisão de engenharia, QA e lançamento em um único prompt infinito, separar tudo em modos distintos com papéis claros.

O que é gstack

No cerne, gstack não é um novo modelo e não é outro framework de agentes, mas uma camada de workflow sobre Claude Code. O projeto empacota estágios típicos de entrega de software em comandos separados e atribui a cada um seu próprio modo de pensamento. Em vez de improviso no espírito de "construa uma feature e a revise você mesmo", o desenvolvedor recebe uma sequência de passos: primeiro uma formulação de produto, depois um plano de engenharia, depois revisão, testes no navegador e apenas depois a preparação do lançamento. Em outras palavras, gstack tenta adicionar à desenvolvimento de IA não magia, mas disciplina de processo.

"Eight opinionated workflow skills for Claude Code" — assim é como o projeto se descreve.

A ideia-chave aqui não é dar ao agente mais liberdade, mas sim o oposto — restringir o contexto de cada tarefa. Conforme a descrição do projeto, isso deve reduzir o número de soluções fracas que aparecem quando uma única IA simultaneamente inventa uma feature, escreve código, testa a interface e decide se isso pode ser lançado em produção. gstack separa esses papéis e força a execução sequencial, como se pessoas diferentes com áreas diferentes de responsabilidade estivessem trabalhando na tarefa.

Oito modos de operação

No momento do lançamento, o repositório continha oito comandos principais, cada um responsável por uma parte separada do processo, em vez de "tudo de uma vez". Essa é a aposta principal do gstack: a qualidade melhora não através de nova inteligência, mas através de disciplina em torno do agente de código já existente. Um comando separado verifica a ideia do produto, outro verifica arquitetura e testes, outro verifica riscos no código, e ainda outro é responsável pelo estágio final antes do merge e lançamento.

• `/plan-ceo-review` — revisão de produto da ideia e prioridades
• `/plan-eng-review` — arquitetura, fluxo de dados, casos extremos e testes
• `/review` — busca de riscos em produção e problemas de código
• `/ship` — sincronização de branch, execução de testes e preparação de 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 de coding com IA: o agente escreve rapidamente o caso feliz, mas frequentemente perde casos extremos, regressões e falhas de UX. Em gstack, essas verificações são movidas para modos separados para que não compitam 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 em si da prática de engenharia comum, onde design, implementação, testes e lançamento não são jogados em uma única etapa.

Navegador, QA e stack

A parte mais interessante do gstack não são os skills em markdown, mas o runtime persistente do navegador. Em vez de lançar um novo navegador para cada ação, o sistema inicia um daemon Chromium headless de longa vida e se comunica com ele via HTTP localhost. Isso é necessário tanto para velocidade quanto para manter o estado entre os passos.

Conforme a descrição do projeto, um cold start da ferramenta de navegador leva cerca de 3–5 segundos, e as chamadas subsequentes após o lançamento se encaixam em aproximadamente 100–200 milissegundos. Por isso, cookies, abas, localStorage e estado de login são preservados entre comandos. É especialmente importante como este navegador é integrado ao fluxo de QA.

O comando `/browse` dá ao agente a capacidade de entrar na aplicação, clicar pela interface, tirar screenshots e ver onde tudo quebra. E `/qa` vai além: analisa o diff do branch, identifica rotas afetadas e testa precisamente essas páginas e cenários que poderiam ter sido impactados pelas mudanças. Em um exemplo do repositório, esse modo analisou oito arquivos modificados, encontrou três rotas afetadas e as testou contra uma instância local da aplicação — vinculando mudanças de código ao comportamento real da interface.

De uma perspectiva técnica, gstack também foi construído pragmaticamente. Para usá-lo, você precisa de 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 em um binário executável separado. O conjunto pode ser instalado em `~/.claude/skills/gstack` ou colocado no `~/.claude/skills/gstack` local dentro do projeto para que toda a equipe use o mesmo processo. Os autores explicam a escolha de Bun por razões simples: binários compiláveis, acesso nativo a SQLite, execução de TypeScript sem boilerplate extra e servidor HTTP integrado através de `Bun.serve()`.

O que isso significa

gstack é interessante não como "outro conjunto de prompts", mas como uma tentativa de transformar coding com IA em um pipeline repetível com verificações em cada estágio. Se essa abordagem pegar, o mercado se moverá não apenas para modelos mais fortes, mas também para camadas operacionais mais rigorosas sobre eles — com modos separados para planejamento, revisão, QA e lançamento. A mudança principal aqui é que confiança em IA está sendo construída não através de promessas de modelo, mas através de estágios de verificação.