gstack /review e /qa: como revisar o código e fazer QA antes do merge?

Fala aí, beleza? Tem um momento no fluxo de dev que é puro voto de confiança: o merge

CI verde, teste passando, pipeline lindo, e mesmo assim a race condition tá lá, a query N+1 tá lá e a tela quebra no primeiro clique de quem tá logado

CI verde diz que nada explodiu, não é atestado de código sadio nem de produto funcionando

O gstack é o conjunto de skills de Claude Code publicado por Garry Tan no repositório garrytan/gstack, aberto como open source em março de 2026

A descrição oficial do repo apresenta o pacote assim: "Use Garry Tan’s exact Claude Code setup: 23 opinionated tools that serve as CEO, Designer, Eng Manager, Release Manager, Doc Engineer, and QA"

Neste post eu recorto só o time de qualidade: o /review, que ataca o diff da sua branch, e o /qa, que ataca a aplicação rodando

Bora ver na prática? 😀

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

O que você precisa antes de rodar /review e /qa

A lista é curta:

• Claude Code instalado na máquina
• um repositório git com a sua branch de trabalho: o /review compara essa branch com a base via merge-base, então quanto mais raso o histórico, mais coisa entra na revisão de uma vez
• a aplicação web acessível no caso do /qa: local ou uma URL de staging

Sobre o navegador do QA, se liga nisso: o navegador que o /qa usa é um Chromium headless controlado por Playwright

Que navegador headless? É o navegador de verdade rodando sem janela aberta na sua frente, dirigido por código

E o detalhe que muda o jogo: cookies, abas, localStorage e sessão persistem entre comandos, então o estado não evapora a cada instrução nova

O pacote ainda traz o /browse, a skill de navegador persistente pra você verificar a UI na prática

Cada skill vive em uma pasta com o seu próprio SKILL.md, e é exatamente esse o caso de review/SKILL.md e qa/SKILL.md dentro do repo. Se o conceito ainda é novo pra você, vale entender antes o que são skills em agentes de código

A instalação documentada é uma linha só:

git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack && cd ~/.claude/skills/gstack && ./setup

E se você quer o mesmo setup valendo pro time inteiro, a documentação orienta copiar o gstack pra dentro do projeto, remover o .git e rodar o setup lá:

cp -Rf ~/.claude/skills/gstack .claude/skills/gstack && rm -rf .claude/skills/gstack/.git && cd .claude/skills/gstack && ./setup

Como rodar a revisão e o QA do gstack passo a passo

1. Instale e confirme que as skills chegaram

Roda o git clone da instalação e depois confere que review/SKILL.md e qa/SKILL.md existem dentro da pasta clonada

O erro comum deste passo: instalar só no seu perfil, em ~/.claude/skills/gstack, e achar que o time todo tá com as mesmas skills. Não tá. Pra isso existe a variante que copia o pacote pra dentro do projeto

2. Prepare a branch e o diff

O /review monta o diff da branch atual contra a base ainda não mergeada usando merge-base, assim:

   git fetch origin <base> --quiet
   DIFF_BASE=$(git merge-base origin/<base> HEAD)
   git diff "$DIFF_BASE" --stat

O erro comum deste passo: pular o fetch e comparar com uma base velha. Aí a revisão passa a olhar mudança que nem é sua, e você perde tempo discutindo código dos outros

3. Acione o /review e entenda o que ele caça

Os gatilhos documentados são pedidos do tipo "review this PR", "code review", "pre-landing review" e "check my diff"

A postura dele é a de um engenheiro sênior paranoico atrás do bug que passa no CI e quebra em produção: race conditions, tratamento de erro ausente, consultas N+1, vulnerabilidades de segurança e suposições erradas sobre o formato dos dados

Além do bug óbvio, ele analisa o diff procurando problema estrutural: segurança de SQL, violações de fronteira de confiança com LLM e efeitos colaterais escondidos atrás de condicionais

4. Rode o /qa contra a aplicação de pé

A documentação mostra o teste contra uma URL de staging (o exemplo é https://staging.myapp.com)

O ciclo dele é bem definido: testa a feature, encontra o bug, corrige no código-fonte, faz um commit atômico por correção e re-verifica

Tome cuidado aqui: o /qa mexe no código. Se você não quer isso, existe o /qa-only, que roda a varredura e só reporta os bugs, sem alterar nada

5. Resolva a sessão antes de testar tela logada

Pra área autenticada tem o /setup-browser-cookies, que importa cookies do Chromium real e abre um seletor interativo de domínios

Os gatilhos são "import cookies", "login to the site" e "authenticate the browser"

O erro comum deste passo: tocar QA de tela logada sem sessão importada. O navegador cai na tela de login, e você conclui que a feature quebrou quando o que faltava era o cookie

6. Deixe o /qa escrever o teste de regressão

Ele não inventa um estilo próprio de teste: lê de 2 a 3 arquivos de teste mais próximos da correção e replica nomeação de arquivo, imports, estilo de asserção, aninhamento describe/it e setup/teardown

Na prática, o teste novo entra parecendo que foi escrito por quem já mantinha a suíte, e não por um robô de passagem

Onde /review e /qa entram no fluxo do PR

O critério é simples e vale gravar: o /review olha o diff, o /qa olha o produto rodando

Um não substitui o outro, porque diff limpo com tela quebrada continua sendo tela quebrada

E tem o encaixe com o resto do pacote, que é onde a coisa fica massa

O plano de teste produzido pelo /plan-eng-review é lido pelo /qa automaticamente, ou seja, nada de copiar e colar checklist de uma janela pra outra

O /codex é um wrapper da OpenAI Codex CLI e serve de segunda opinião com outro modelo: quando /review e /codex revisam a mesma branch, o gstack aponta quais achados se sobrepõem e quais são exclusivos de cada um

É um baita filtro de ruído, e antes de soltar outro agente na sua branch vale entender como funcionam permissões e sandbox no Codex

Já o release é etapa separada: o /ship sincroniza com a main, roda os testes e abre o PR

O que a revisão apontou em um projeto de teste

No vídeo eu mostro a revisão rodando em um projeto que eu tinha acabado de construir do zero, com 30 arquivos criados

Detalhe do bastidor: o projeto não tinha git nem branch, então precisei fazer um commit antes, senão não teria nada em cima do que rodar. A outra saída seria adicionar uma funcionalidade nova e revisar só ela

Sem histórico anterior, a revisão acabou avaliando praticamente o projeto inteiro

O resultado: 6 problemas apontados, já classificados por categoria (falso positivo, intencional, pré-existente, aceitável), e nenhum problema crítico

O único ponto de atenção de verdade foi a ausência de testes: ela sinalizou 5 novos caminhos sem cobertura

Lê esses números como expectativa realista, e não como propaganda: a skill não vira alarme falso gritando em tudo, nem carimbo de aprovação automático

Ela devolve pendência concreta e cobertura faltando, e a decisão do que corrigir antes do merge continua sendo sua =)

Pra ver o gstack inteiro em ação e as skills conversando entre si antes de você aplicar só o /review e o /qa, este vídeo do canal mostra o fluxo completo:

Conclusão

O veredito de uso é curtinho: /review antes de abrir o PR, /qa contra staging antes do merge

E se você não quer commit automático mexendo no seu código, troca pelo /qa-only, que só reporta

Vale lembrar que o projeto segue em desenvolvimento ativo: tem issue aberta no repositório oficial em 18, 19 e 20 de agosto de 2026, então acompanhar o repo é parte do combo

Próximo passo? Instala o gstack, roda o /review naquela branch que já tá aberta aí e compara o retorno com o que o CI vinha te dizendo

A distância entre as duas coisas costuma ser a parte interessante…

Até o próximo post! 🙂