Quais são os papéis do gstack no Claude Code: CEO, Designer, Eng Manager, QA e mais

Fala aí, beleza? O Garry Tan abriu ao público o setup que ele mesmo usa no Claude Code, e a descrição do repositório não vende comando: ela vende cargo

É isso mesmo que tu leu, o texto oficial do projeto diz que são 23 ferramentas opinativas que fazem o papel de CEO, Designer, Eng Manager, Release Manager, Doc Engineer e QA

Se você ainda não clonou nada e só quer saber o que vem dentro da caixa antes de gastar tempo, esse post é o mapa

Vou passar papel por papel, dizer qual skill responde por cada um, o que ela entrega, e onde isso ainda depende de você olhar e decidir

O que é o gstack e quem está por trás:

O gstack é um repositório público, garrytan/gstack, mantido por Garry Tan, e ele se descreve como o setup exato do autor pro Claude Code

Na prática, a descrição oficial é bem direta: 23 ferramentas opinativas que servem como CEO, Designer, Eng Manager, Release Manager, Doc Engineer e QA

Repara na palavra opinativas

Não é um canivete neutro, é um jeito específico de tocar projeto empacotado em skills, com opinião sobre o que vem antes e o que vem depois

Pré-inscrição Formação Claude Code

Domine o Claude Code do básico ao avançado

Você vai aprender a criar sistemas completos com Claude Code, sem precisar ser programador. Inscreva-se para ter acesso a um desconto de lançamento e bônus especiais!

Quero minha vaga

E tem uma peça que muita gente não percebe de cara: o SKILL.md da raiz do repositório funciona como um roteador do conjunto

Ou seja, você não precisa decorar os nomes de todas as skills logo no primeiro dia: o pedido cai no roteador e ele manda pra skill certa (planejamento, revisão, QA, entrega, depuração, docs, segurança, design)

É o mais próximo de "fala com a equipe e alguém pega" que dá pra ter dentro de um terminal 🙂

Mapa dos papéis do gstack: qual skill faz o quê

Aqui vai o resumo que você veio buscar, sem enrolação

Detalhe importante: os seis primeiros papéis são os que estão na descrição oficial do repositório

O /cso é um bônus que vive no pacote e não aparece naquela frase de vitrine, por isso deixei separado na tabela

O que cada papel representa na prática:

Tabela é ótima pra bater o olho, mas cada papel resolve uma dor bem diferente

Bora abrir um por um?

O CEO: quem desafia a premissa antes de você escrever código

A skill /plan-ceo-review não olha o seu código

Ela olha a sua decisão: repensa o problema, questiona as premissas e chega a expandir o escopo quando isso resulta num produto melhor, usando perguntas forçadas pra reenquadrar o produto antes de qualquer implementação

Parece papo de consultor, mas é o oposto disso

O ganho aqui é evitar aquele clássico de construir muito bem a coisa errada

E olha, se você já apanhou de resposta genérica da IA, boa parte dos erros comuns de engenharia de prompt nasce exatamente aí: pedir código antes de fechar o problema

O Designer: dois momentos, duas skills

Esse papel é o único que aparece duas vezes, e faz todo sentido

/plan-design-review roda a crítica de design ainda no plan mode do Claude Code, ou seja, antes da implementação

/design-review é a skill pra revisar a interface já construída

E o que ela procura é interessante: inconsistência visual, problemas de espaçamento e alinhamento, hierarquia e tipografia, estados de interação esquecidos, interações lentas e os padrões comuns de "AI slop"

Aquele visual genérico de site gerado por IA, sabe? Aquele que qualquer pessoa bate o olho e sente o cheiro

Ter isso como item explícito de checklist é MUITO mais útil do que pedir "deixa bonito" pro modelo

O Eng Manager: arquitetura travada antes da implementação

A skill /plan-eng-review é o modo gerente de engenharia: arquitetura, fluxo de dados, diagramas, casos de borda e testes

A lógica é travar a arquitetura antes de começar a escrever

Aqui mora um dos maiores ganhos do pacote, porque casos de borda são justamente o que o vibe coding esquece e o que aparece em produção depois, no pior horário possível

O QA: teste de verdade, no diff da sua branch

O /qa não sai testando o app inteiro no chute

Ele analisa o diff da branch, identifica as rotas afetadas e testa esses caminhos clicando pelos fluxos de usuário num Chromium headless de longa duração

E esse "de longa duração" é a parte esperta: em vez de abrir um navegador novo a cada ação, o gstack mantém um processo persistente que conversa por HTTP em localhost, preservando cookies, abas, localStorage e estado de login entre os comandos

Quem já tentou automatizar teste de fluxo logado sabe o inferno que é perder a sessão a cada passo

O Release Manager: da branch até o pull request

O /ship é o papel mais mecânico da turma, e ainda bem

Ele prepara a branch, sincroniza com a main, roda os testes e abre o pull request, incluindo commits, push e criação do PR

É a etapa que todo mundo faz no automático e erra justamente por isso

O Doc Engineer: documentação com régua, não com achismo

São duas skills

/document-generate cria a documentação que falta do zero, pesquisando o código primeiro e escrevendo nos quadrantes do Diátaxis (referência, how-to, tutorial e explicação)

/document-release lê a documentação do projeto, cruza com o diff, monta um mapa de cobertura Diátaxis e atualiza README, ARCHITECTURE, CONTRIBUTING, CLAUDE.md e CHANGELOG

E por que Diátaxis? Que negócio é esse?

É um framework que separa documentação em quatro tipos com propósitos distintos, e o gstack usa isso como régua de cobertura

O próprio repositório explica a escolha no arquivo docs/explanation-diataxis-in-gstack.md: os quatro quadrantes servem como resposta determinística pra pergunta "a documentação foi atualizada?"

Sacou a jogada? Vira um checklist objetivo em vez de um "acho que tá documentado"

O CSO: a auditoria que não estava na vitrine

O /cso é o modo Chief Security Officer, com auditoria de segurança focada em infraestrutura

Ele cobre busca por segredos, cadeia de suprimentos de dependências, segurança de pipeline CI/CD, segurança de LLM/IA e varredura da cadeia de skills

Esse último item é insano de tão pertinente: auditar a própria cadeia de skills que você instalou na máquina

Por que os papéis funcionam como equipe, e não como comandos soltos:

Aqui está o real diferencial em relação a qualquer coleção avulsa de skills que você baixa por aí

As skills do gstack são pensadas como um processo em sequência: Think, Plan, Build, Review, Test, Ship, Reflect

E a costura entre elas é literal, não é só ordem sugerida

O /office-hours escreve um design doc que o /plan-ceo-review lê

O /plan-eng-review escreve um plano de teste que o /qa executa

No começo do fluxo, o /office-hours tem dois modos: o modo startup, com seis perguntas forçadas (realidade da demanda, status quo, especificidade desesperada, cunha mais estreita, observação e adequação ao futuro), e o modo builder, pra brainstorm de projetos paralelos, hackathons, aprendizado e open source

E no fim da linha o /retro escreve uma retrospectiva semanal com consciência de time, incluindo sequências de entrega e oportunidades de melhoria

É como contratar uma equipe onde cada pessoa entrega um artefato pra próxima, em vez de seis freelas trabalhando sem se falar

Como os papéis se comportam quando você roda de verdade:

Agora o veredito honesto, com o que eu vi rodando

No vídeo eu monto um projeto de exemplo, uma microrrede social de pensamentos, e o fluxo começa pelo office hours fazendo perguntas de objetivo, estágio e evidência de demanda

Ele lista as premissas pra eu concordar ou não, pesquisa referências parecidas na web e me devolve três abordagens com notas, recomendando uma delas

E aqui vai a primeira observação importante: aceitar a abordagem recomendada JÁ mudou o foco do produto em relação à minha ideia inicial

Isso não é bug, é o papel de CEO fazendo o trabalho dele

Mas significa que você tem que estar acordado na hora de aceitar 😀

Depois que o documento de design foi aprovado, o framework me ofereceu três caminhos de revisão como próxima etapa: revisão de engenharia pra definir arquitetura, revisão de CEO pra desafiar o escopo e revisão de design pra checar se o design é o ideal

Eu escolhi rodar só a revisão de engenharia pra ilustrar, mas acho interessante passar pelas três pra bater em cima do que foi planejado

E fica claro no uso que essas revisões são opcionais: se você achou que o planejamento inicial já ficou garantido, dá pra seguir direto pra execução

Na etapa de revisão de CEO, o escopo do meu projeto apareceu com nota 7 (e olha, posso estar enganado nesse número), tendo 10 como alvo

Outra coisa que me chamou atenção: antes de escrever qualquer linha de código, o framework tentou gerar uma imagem do esquema do projeto, falhou, e então criou um wireframe em HTML do app

O resultado visual ficou mto massa, sinceramente

Também apareceu no fluxo uma oferta de segunda opinião usando o Codex pra debater a revisão, e eu recusei porque não tinha a ferramenta instalada na máquina

Tome cuidado com um ponto: a aprovação do plano deveria ser feita lendo tudo o que fica na pasta do framework

Eu aprovei sem ler no vídeo, e assumo, mas não é o que eu recomendo pra você haha

No onboarding ainda passei por perguntas de telemetria (dá pra recusar sem problema), de proatividade pra acionar skills sozinho (essa vale a pena deixar ligada) e de regras de roteamento

Deixei ligada também a opção de olhar outros projetos da máquina pra aprender padrões, com os dados ficando locais

E logo depois do primeiro comando ele já escreveu um CLAUDE.md com instruções próprias no projeto

Então onde cada papel entrega e onde ainda exige julgamento humano?

Os papéis de processo entregam sozinhos muito bem: o QA testando as rotas do diff no navegador e o release preparando branch, testes e PR são trabalho chato e repetitivo que a máquina faz melhor que você às 23h

Já o CEO e o Designer entregam provocação, não decisão

Eles reenquadram o produto, e reenquadrar produto é exatamente o tipo de coisa que você não pode aprovar no piloto automático

A motivação toda de usar um pacote assim, na minha visão, é acabar com o vibe coding malfeito: gente que tem uma ideia, sai programando, acumula bug, faz deploy e depois se dá mal

Como instalar o gstack para testar os papéis:

Já aviso: a instalação não é aquele next, next e finish de plugin

São comandos colados dentro do terminal, com um passo de git clone

1. Clone o repositório dentro da pasta de skills e rode o script de setup

git clone https://github.com/garrytan/gstack.git ~/.claude/skills/gstack && cd ~/.claude/skills/gstack && ./setup

O erro comum deste passo é rodar o git clone na pasta do seu projeto, por hábito: o caminho ~/.claude/skills/gstack é parte do combinado, não é decoração

2. Se você usa outro agente de código, troque o host no próprio script

./setup --host codex
./setup --host cursor

Nesse caso o clone vai pra ~/.codex/skills/gstack ou ~/.cursor/skills/gstack, e o erro comum é instalar no caminho do Claude Code e ficar esperando as skills aparecerem no outro agente

3. Abra o docs/skills.md antes de sair usando tudo

É o guia de cada skill do gstack, com filosofia, fluxo e exemplos

O erro comum deste passo é o meu: aprovar o que o framework escreveu sem ler o que ficou na pasta

Conclusão:

Recapitulando o mapa: os papéis do gstack são CEO (/plan-ceo-review), Designer (/plan-design-review e /design-review), Eng Manager (/plan-eng-review), QA (/qa), Release Manager (/ship) e Doc Engineer (/document-generate e /document-release), com o /cso de brinde na parte de segurança

O que amarra tudo é a sequência Think, Plan, Build, Review, Test, Ship, Reflect, com uma skill entregando artefato pra próxima

Se você for testar, o caminho concreto é começar pelo /office-hours, seguir o fluxo até o /ship e ler o docs/skills.md antes de adotar o pacote inteiro de uma vez

E quando rodar as revisões por papel, leia o que elas escreveram antes de aprovar… é ali que o ganho aparece de verdade

até o próximo post!