gstack ou criar suas próprias skills no Claude Code: qual escolher?

Instalar o pacote pronto do gstack com um comando ou escrever seus próprios arquivos SKILL.md do zero?

Fala aí, beleza? Essa escolha virou pauta porque o gstack, o setup open source que Garry Tan (presidente e CEO da Y Combinator) publicou para o Claude Code, explodiu no GitHub e caiu no colo de todo mundo que usa agente pra programar

Do outro lado da balança está o caminho artesanal, que é bem menos glamouroso e bem mais seu: abrir uma pasta, escrever um arquivo markdown e ganhar um comando que fala exatamente a língua do seu projeto

Esse post não é lista de recursos, é uma decisão

Bora comparar os dois lados com o que dá pra verificar, e fechar com um veredito por perfil de usuário 🙂

O que é o gstack e o que vem dentro dele:

O gstack é um repositório open source mantido na conta pessoal de Garry Tan, com o setup dele para Claude Code

Foi publicado em 12/03/2026, roda sob licença MIT (uso gratuito) e virou fenômeno de estrela: em 17/08/2026 o repositório aparecia com 128.765 estrelas, na 76ª posição do ranking global de repositórios mais estrelados do GitHub

A descrição oficial do repositório resume o pacote como 23 ferramentas opinativas que atuam como CEO, Designer, Eng Manager, Release Manager, Doc Engineer e QA

Já o README detalha o conjunto como 23 especialistas mais 8 power tools

Ou seja, os 23 são os especialistas, e as power tools entram por cima disso: as duas contagens não são a mesma coisa, e vale saber disso antes de sair citando número por aí

Repare na palavra opinativas, porque ela é o coração da comparação: não é um kit neutro, é o jeito de trabalhar de outra pessoa empacotado em arquivos

Que comandos aparecem depois de instalar?

Entre as skills documentadas no repositório estão /office-hours, /plan-ceo-review, /plan-eng-review, /review, /qa, /ship, /qa-only, /browse, /setup-browser-cookies, /devex-review, /land-and-deploy, /canary, /benchmark e /document-release

Dá pra sentir o formato só pelos nomes: é um fluxo de produto inteiro, do planejamento com revisão de CEO até o deploy e a documentação do release

Como o gstack é instalado:

O caminho oficial é clonar o repositório dentro da pasta de skills do Claude Code e rodar o script de setup:

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

Repare no destino do clone: ~/.claude/skills/gstack, na sua pasta pessoal, então o gstack entra como skill pessoal e vale pra todos os seus projetos

Um detalhe que muda a vida de quem gosta de mexer: a instalação é por symlink apontando para a raiz do repositório clonado

Ou seja, você edita o SKILL.md lá no repo e a alteração fica visível para as sessões do Claude Code, sem precisar reinstalar nada

E o pacote deixou de ser exclusivo do Claude Code: o setup aceita uma flag de host, no formato ./setup --host <nome>, com hosts como codex, cursor, opencode, factory, slate, kiro, hermes e openclaw, cada um recebendo as skills em ~/.<agente>/skills/

O que é montar suas próprias skills no Claude Code:

Agora o outro lado, que é mais simples do que parece

Uma skill no Claude Code é uma pasta com um arquivo dentro

Se ela é pessoal, mora em ~/.claude/skills/<nome>/SKILL.md e vale para todos os seus projetos

Se ela é de projeto, mora em .claude/skills/<nome>/SKILL.md, pode ser commitada no repositório e viaja junto com o código

Esse segundo caminho é o que resolve o problema de manter o time no mesmo padrão, porque a instrução deixa de ser combinado verbal e vira arquivo versionado

O que vai dentro do SKILL.md?

O SKILL.md é o único componente obrigatório de uma skill

Ele é composto por um frontmatter YAML (com name, description e o opcional allowed-tools) mais o corpo em markdown com as instruções

O nome da pasta vira o identificador da skill

---
name: revisar-pr
description: Revisa o diff atual procurando bug de lógica e teste faltando
allowed-tools: Read, Grep, Bash
---

Leia o diff da branch atual

Procure: caso de borda sem teste, erro engolido em catch, query sem índice

Escreva o resultado em lista, do mais grave pro menos grave

A skill entra em cena de duas formas: automaticamente, quando o pedido do usuário combina com a description, ou manualmente, quando você chama por /nome-da-skill

Por que isso importa pro seu contexto?

Aqui está o ponto técnico que decide boa parte do comparativo

O corpo de uma skill só entra no contexto quando ela é usada, diferente do CLAUDE.md, que é sempre carregado

Ou seja: material de referência longo dentro de uma skill custa quase nada até o momento em que é necessário

Isso muda como você organiza tudo, e explica por que enfiar todo o processo no CLAUDE.md é a pior das opções

E os slash commands e plugins, morreram?

Não

Arquivos markdown em .claude/commands/ (projeto) e ~/.claude/commands/ (pessoal) seguem funcionando, com o nome do arquivo sem a extensão virando o nome do comando

Um .claude/commands/deploy.md cria o /deploy e funciona igual a uma skill em .claude/skills/deploy/SKILL.md

O frontmatter opcional desses comandos permite pré-aprovar ferramentas com allowed-tools, definir override de modelo com model e adicionar uma description, e o placeholder $ARGUMENTS recebe o que você passar na chamada

E tem ainda a camada de plugin, que empacota skills, agents, hooks e servidores MCP

A instalação de plugin acontece em dois passos, adicionar o marketplace e depois instalar a partir dele:

/plugin marketplace add <repo>
/plugin install <plugin>@<marketplace>

A gestão fica por conta de /plugin disable, /plugin enable, /plugin uninstall e /reload-plugins

O marketplace oficial da Anthropic (claude-plugins-official) já entra sozinho na primeira execução interativa

gstack x skills próprias: comparação lado a lado:

Coloquei na mesa os critérios que realmente pesam na hora de decidir, e cada linha fecha com quem ganha ali

Repare que não existe um vencedor geral

O gstack ganha nos critérios de arranque e alcance, e as skills próprias ganham nos critérios de encaixe e contexto

Quando o gstack faz sentido e quando ele atrapalha:

Critério na tabela é bonito, mas o que decide mesmo é o cenário

Onde o pacote pronto brilha:

• Projeto novo sem processo definido: você não tem checklist de QA nem ritual de release, então herdar um fluxo opinativo é melhor que não ter fluxo nenhum
• Dev solo que quer review e ship prontos: comandos como /review, /qa e /ship te dão os ganchos de um time inteiro sem você ter que inventar cada etapa
• Time que precisa de vocabulário comum: quando todo mundo fala /plan-eng-review, a conversa para de ser "me manda aquele prompt aí"

Onde ele atrapalha:

• Repositório com CLAUDE.md extenso: uma review crítica após um mês de uso aponta que algumas skills do gstack passam de 400 linhas, e que isso pesa no consumo de contexto justamente em projetos que já carregam um CLAUDE.md grande
• Quem já tem checklist próprio de QA e deploy: aí o pacote não soma, ele briga com o que você já faz, e vira aquele caso clássico de duas skills em conflito disputando o mesmo pedido
• Iniciante em agentes: a mesma review registra que o fluxo interativo do /plan-ceo-review tem 10 etapas, o que pode soar burocrático demais pra quem ainda está pegando o jeito

E o meio-termo? Existe!

Quase ninguém fala do caminho do meio, que é o mais honesto: instalar, usar por umas semanas e OBSERVAR quais comandos você de fato aciona

O que sobrar vira referência

O que faltar você escreve como skill própria, do seu tamanho

Skill é arquivo em pasta, não é casamento 😀

O que muda na prática quando você roda um pacote de skills pronto:

Aqui eu falo do que passei, e vou ser direto na régua: eu não instalei o gstack no vídeo

O que eu fiz foi instalar uma skill pronta de um catálogo de terceiros no Claude Code, e a sensação de rodar coisa que outra pessoa escreveu é exatamente a mesma

Antes de partir pra prática eu explico o que é uma skill, porque sem isso o resto vira mágica: é um arquivo em Markdown com nome, descrição do que ele faz e, no corpo, o detalhamento das instruções que a IA deve seguir quando aquela skill for ativada

Nada de prompt secreto, é arquivo de texto mesmo

Na instalação eu passo por três escolhas que valem pra qualquer pacote pronto: quais editores recebem a skill, instalar só no projeto ou de forma global, e usar link simbólico em vez de baixar uma cópia do arquivo

Como eu tinha marcado mais de um editor, o instalador criou pastas para vários

Apaguei as outras e deixei só a do Claude Code, e no vídeo eu comento o óbvio: dava pra ter selecionado apenas esse editor lá no começo, e economizar a faxina

Sobre projeto x global, minha régua é simples: se a skill só vai ser usada em um projeto, instalar globalmente não compensa

E por causa da opção que escolhi, o que ficou no projeto foi um link simbólico pra skill, não uma cópia do arquivo (mesma ideia do symlink que o setup do gstack faz)

No vídeo abaixo você me vê fazendo esse caminho inteiro, da escolha na instalação até o resultado na tela

Eu testo uma skill de design gerando uma página única, com elementos específicos, por UM único prompt

E aí veio a parte que me convenceu: coloquei lado a lado o resultado com e sem a skill

Sem skill, a página saiu com ícones genéricos, emoji no meio e cores mal escolhidas

Com a skill, os ícones ficaram mais profissionais e as escolhas seguiram padrões de design de verdade

Uma dica que eu dou lá e repito aqui: cite a skill explicitamente no prompt

Ajuda a ferramenta a encontrar e usar a coisa certa, em vez de você ficar torcendo pro match de description acontecer

O ponto cego do pacote pronto:

O ganho imediato é real, mas ele não é uniforme

A mesma review crítica do gstack relata que, em uso estável após quatro semanas, o autor usava apenas seis dos comandos instalados e ignorou ou desinstalou o resto

Isso bate com o que eu senti no meu teste: uma skill certeira muda o resultado na hora, e o resto do catálogo fica ali parado

Juntando com o alerta das skills acima de 400 linhas, o retrato fica claro: pacote pronto é ótimo pra DESCOBRIR o que você quer, e ruim pra manter tudo instalado pra sempre

Veredito por perfil: qual escolher no seu caso:

Sem cima do muro, vamos por perfil

Está começando com agentes:

Instale o gstack e use como material de estudo

Abra os SKILL.md, leia como as instruções são escritas, rode um /review num projeto de teste

O que ignorar: os fluxos interativos longos, tipo as 10 etapas do /plan-ceo-review, que só fazem sentido quando você já entendeu o ciclo

Risco assumido: achar que o processo de outra pessoa é O processo

Dev solo com projeto próprio:

Instale, use por algumas semanas e depois faça a poda

Fique com os comandos que você aciona de verdade e escreva os seus pro que sobrou de fora

Risco assumido: contexto disputado se o seu CLAUDE.md já for grande

Time com padrão a impor:

Aqui eu vou de skills próprias, commitadas em .claude/skills/<nome>/SKILL.md

O padrão do time é o padrão do time, não o de um repositório de fora, e uma skill versionada no projeto entra no code review como qualquer arquivo

Risco assumido: alguém precisa manter isso vivo

Usuário avançado com fluxo maduro:

Provavelmente você já tem seus comandos em .claude/commands/ funcionando com $ARGUMENTS e allowed-tools

Use o gstack como catálogo de ideias, roube estrutura, não instale o pacote inteiro

Risco assumido: quase nenhum, desde que você resista à tentação de deixar tudo ligado

As arestas conhecidas (importante!):

Duas coisas que eu não escondo de ninguém antes de instalar

A primeira: existe uma issue aberta no repositório (a #1543) sobre o comando /gstack não completar automaticamente no Claude Code, por colisão entre diretório e wrapper

A segunda, e essa é mais séria: existe um wrapper de plugin de Claude Code para o gstack mantido por terceiro, no repositório github.com/Ahacad/gstack, que NÃO é o repositório oficial

Tome cuidado ao copiar comando de instalação que você achou por aí, confira sempre de qual conta o repositório é 🙂

Conclusão:

A melhor notícia dessa comparação é que ela não é permanente

Skill é arquivo em pasta: dá pra adicionar, testar e apagar no mesmo dia, sem cerimônia

O gstack te dá um fluxo inteiro de graça, com curadoria de quem trabalha em outro contexto, e escrever o seu te dá encaixe perfeito com o custo de contexto que VOCÊ escolhe

Se eu tivesse que resumir: comece pelo pronto pra aprender o formato, termine no seu pra caber no seu projeto

Próximo passo prático, bem curtinho:

1. Escolha UM fluxo repetitivo seu (aquele que você digita o mesmo prompt toda semana)
2. Veja se algum comando do gstack já cobre aquilo
3. Se não cobrir, crie a pasta, escreva um SKILL.md com o frontmatter mínimo (name e description) e teste chamando por /nome-da-skill

Faça o teste e me conta qual caminho ficou melhor no seu setup

Até o próximo post!