Como usar o gstack no Claude Code: do /autoplan ao /ship em uma feature

Disparar comando solto é uma coisa

Rodar uma esteira, do plano até o envio, é outra bem diferente

Fala aí, beleza? O garrytan/gstack é o conjunto de skills de Claude Code aberto por Garry Tan, CEO da Y Combinator, publicado no GitHub em 12 de março de 2026

A descrição oficial do repositório apresenta o pacote como 23 ferramentas opinativas que fazem os papéis de CEO, Designer, Eng Manager, Release Manager, Doc Engineer e QA

E o negócio pegou: o repositório passou de 89,7 mil estrelas em menos de dois meses depois da publicação 😀

Neste post o caminho é ponta a ponta: instalar, gerar o plano, rodar o /autoplan, passar pelo gate e fechar no /ship

O que você precisa antes de instalar o gstack:

Os pré-requisitos do script de setup são três: Claude Code, Git e Bun na versão 1.0 ou superior

Tem um quarto item que não é bem pré-requisito, é armadilha: o Node também precisa estar no PATH, por causa de um bug do Bun com o transporte de pipe do Playwright no Windows

Então se você já tem Node instalado, ótimo, deixa ele acessível no terminal e segue o baile

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

Global ou vendorizado no projeto?

Aqui tem uma escolha antes do primeiro comando

O gstack pode ser instalado de forma global, em ~/.claude/skills/gstack, ou vendorizado dentro do próprio projeto, em .claude/skills/gstack

E ele detecta sozinho qual tipo de instalação está rodando, então tu não precisa configurar isso na mão

A regra prática: global quando é a tua máquina e tu quer as skills em todo projeto, vendorizado quando o repositório é compartilhado e o time inteiro deve ter as mesmas skills junto do código

Guarda essa diferença, porque os comandos que vêm abaixo são todos da instalação global, que é a documentada no README

Como instalar o gstack no Claude Code:

1. Rode o comando oficial de instalação

O comando documentado clona o repositório dentro da pasta de skills do Claude Code e já executa o script de setup na sequência:

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

Repara que são duas coisas coladas num comando só: o clone e o ./setup

E repara também no caminho: ~/.claude/skills/gstack é a instalação GLOBAL

Se a tua escolha foi vendorizar, o lugar das skills é .claude/skills/gstack dentro do projeto, e é isso que o gstack detecta na hora de rodar

O erro comum deste passo: clonar o repositório e achar que a skill já apareceu no Claude Code

Não apareceu

É o ./setup que instala os arquivos das skills, sem ele tu só tem uma pasta com código dentro

2. Ou use o wrapper de plugin, se preferir

Existe um wrapper de plugin de Claude Code para o gstack, mantido por terceiro, o Ahacad/gstack

Ele traz o garrytan/gstack como submódulo git em vendor/gstack e expõe as skills como symlinks pelo sistema de plugins, em vez do setup por symlink manual

Só lembra que plugin de terceiro no Claude Code tem duas etapas: primeiro tu adiciona o marketplace, depois instala

/plugin marketplace add <repositório ou URL>
/plugin install

O erro comum deste passo: ir direto no /plugin install sem ter adicionado o marketplace antes

3. Reinstale quando quiser sincronizar com o repositório

O projeto se mexe, e tu vai querer as skills atualizadas

Pra isso, roda o setup de novo, de novo pelo caminho da instalação global:

cd ~/.claude/skills/gstack && ./setup

Isso reinstala os arquivos das skills e sincroniza a tua instalação com o repositório

Na instalação vendorizada o caminho das skills é outro, .claude/skills/gstack dentro do projeto, então confere na documentação oficial antes de sair copiando o comando de cima

O erro comum deste passo: esperar que a atualização chegue sozinha

Ela não chega, quem sincroniza é o setup rodado de novo

Do /autoplan ao /ship: a esteira completa em uma feature

Agora a parte que importa

O gstack não é uma caixinha de comandos avulsos, é uma sequência com ordem e gates

Bora ver na prática?

1. Entenda o ciclo de vida antes de sair chamando skill

O ciclo de vida completo documentado pelo gstack é este:

office-hours → plan → implement → review → QA → ship → retro

Atenção num detalhe que confunde muita gente: a etapa review do ciclo é a review do CÓDIGO, e por isso ela vem depois do implement

O /autoplan é outra coisa: ele é a review do PLANO, e mora dentro da etapa plan, ou seja, antes de tu escrever código

O /ship mora lá no fim, quando o trabalho já passou por review e QA

O erro comum deste passo: chamar o /autoplan sem ter plano nenhum

Ele é um pipeline de auto review, ou seja, ele revisa algo que já existe

2. Gere o documento de design

Na etapa de planejamento, o documento de design é gravado numa pasta própria: ~/.gstack/projects/

E esse arquivo não fica ali de enfeite, ele alimenta diretamente as reviews de plano, sendo consumido por /plan-ceo-review e /plan-eng-review

É o que faz a esteira funcionar sem copiar e colar contexto de uma etapa pra outra

O erro comum deste passo: deixar o plano só no chat e depois estranhar que a review não achou nada pra revisar

3. Acione o /autoplan

A skill autoplan é acionada quando tu pede autoplan, auto review, run all reviews, review this plan automatically ou make the decisions for me

O que ela faz: lê as skills completas de review e executa elas em sequência, tomando decisões automáticas a partir de princípios de decisão codificados

E a ordem das fases de review é estrita:

CEO → Design → Eng → DX

Se liga que isso aqui é a lista de FASES DE REVIEW do pipeline, não a lista de papéis do pacote que apareceu lá em cima (CEO, Designer, Eng Manager, Release Manager, Doc Engineer e QA)

São listas diferentes, com finalidades diferentes, e por isso aparece um DX aqui que não estava lá

Sempre sequencial, nunca em paralelo: cada fase termina antes da próxima começar

O erro comum deste passo: tentar "ganhar tempo" pedindo pra rodar as fases juntas

A sequência é proposital, cada fase entra com o resultado da anterior na mesa

4. Responda ao gate final

Aqui é o pulo do gato do /autoplan

Ele não te devolve tudo pra decidir, ele decide o que dá pra decidir sozinho e guarda pro final só as taste decisions

O gate final de aprovação traz três tipos de coisa: abordagens equivalentes (quando tanto faz e alguém precisa escolher), escopo no limite (aquilo que pode entrar ou ficar pra depois) e discordâncias do Codex

O erro comum deste passo: esperar um relatório com cada detalhe da review pra aprovar item por item

O gate é sobre gosto e escopo, o resto já foi decidido no caminho

5. Implemente sabendo o que trava o envio

Com o plano aprovado, tu implementa

E aqui vale amarrar uma ponta: a Eng Review é aquela fase Eng que já rodou no plano, dentro do /autoplan

Não são duas coisas com o mesmo nome, é a mesma review, e é ela que trava o envio lá na frente, no /ship

É o gate obrigatório do fluxo, e o único que dá pra desligar por configuração global:

gstack-config set skip_eng_review true

Agora se liga nisso: a review adversarial não é gate que tu liga e desliga, ela é automática e SEMPRE ligada

Todo diff passa por um subagente adversarial do Claude e por um desafio adversarial do Codex

E diffs a partir de 200 linhas ganham ainda uma review estruturada do Codex, com gate P1, que vem junto dessa camada automática

O erro comum deste passo: desligar a eng review achando que desligou a checagem inteira

A adversarial continua lá, batendo no teu diff 😛

6. Rode o /qa

O /qa recolhe automaticamente o plano de teste que veio da eng review

Sem copiar e colar nada, é a mesma lógica do documento de design: a etapa anterior entrega pra próxima

O erro comum deste passo: montar um plano de teste na mão e colar no chat, duplicando o que a eng review já produziu

7. Feche com o /ship

O /ship é a etapa de envio, e ele tem umas decisões de arquitetura bem pensadas

A auditoria de cobertura de testes é despachada como subagente do tipo general-purpose, em uma janela de contexto nova

O processo principal só recebe a conclusão, e isso é defesa contra context rot

Outra coisa: a auditoria para na primeira suíte que falha, pra não gastar custo de API com as suítes restantes, e não segue adiante se algo falhar

Só continua se tudo passa

O subagente também é instruído a apenas relatar: ele roda git diff e reporta, não commita e não dá push

Pra montar o contexto do envio, o /ship lê a descrição do pull request e as mensagens de commit da branch com comandos de linha:

gh pr view --json body --jq .body
git log origin/<base>..HEAD --oneline

O erro comum deste passo: esperar que o subagente de auditoria já deixe tudo commitado e empurrado

Ele relata, ponto

Quando vale rodar a esteira inteira e quando um comando solto resolve

Nem toda tarefa pede o pacote completo, beleza?

Separa assim:

Feature nova com escopo aberto:

É o caso mais óbvio pra esteira inteira

Quando ninguém sabe direito onde a feature termina, o valor está justamente no gate final, que separa o que é decisão de gosto do que já foi resolvido pelas fases de review CEO, Design, Eng e DX

Correção pequena:

Diff curto não aciona a review estruturada do Codex com gate P1, que entra a partir de 200 linhas

Mas atenção: mesmo aqui o subagente adversarial do Claude e o desafio adversarial do Codex continuam rodando, porque a review adversarial é sempre ligada

Time que quer padronizar:

A Eng Review sendo o gate obrigatório que trava o envio é uma vantagem organizacional

O time todo passa pelo mesmo ponto de controle, e desligar é uma decisão explícita via gstack-config set skip_eng_review true, não um esquecimento

Projeto compartilhado:

Instalação vendorizada em .claude/skills/gstack deixa as skills viajando junto do repositório

Quem clona o projeto pega o mesmo conjunto, sem depender do que cada um instalou na própria máquina

Veja um projeto sendo tocado do zero ao deploy no Claude Code

Pra começar do zero com um projeto inteiro dentro do Claude Code, este vídeo do canal mostra a construção de um app completo até o deploy:

Conclusão

O gstack não brilha quando tu dispara um comando solto e olha o resultado

Ele brilha quando os comandos viram sequência: plano gravado em ~/.gstack/projects/, reviews rodando em ordem estrita, gate final só com o que precisa de gosto humano, /qa puxando o plano de teste sozinho e /ship auditando em contexto novo antes de qualquer coisa sair

Próximo passo prático? Instala, escolhe a próxima feature pequena da tua fila e roda o /autoplan nela

Depois observa com calma o que o gate final te devolve, porque é ali que dá pra sentir se a esteira combina com o teu jeito de trabalhar, antes de partir pro /ship

até o próximo post! 🙂