Get Shit Done no Claude Code: 5 casos de uso em que o GSD faz diferença de verdade

Fala aí, beleza? O Claude Code começa a sessão afiado e vai perdendo o fio conforme a janela de contexto enche

Você reconhece o padrão: as primeiras respostas acertam o arquivo certo de primeira, e lá pela metade da tarefa ele já esqueceu uma decisão que vocês combinaram no começo

Esse desgaste tem nome, context rot, a queda de qualidade conforme a janela vai lotando

E é justamente esse o alvo do GSD Core: uma camada de workflow que tu instala POR CIMA do Claude Code, empurrando pesquisa, planejamento e execução pesada pra subagentes de contexto fresco, mantendo a sessão principal enxuta

Só que GSD não é fórmula mágica pra tudo

Ele brilha em situações específicas, e é isso que eu separei aqui: 5 casos concretos de desenvolvimento, cada um com o pilar que ataca a dor e os comandos que existem de verdade na documentação

Bora? 😀

O que é o GSD Core e quais são os três pilares

O GSD nasceu no repositório gsd-build/get-shit-done, publicado originalmente por TÂCHES (o usuário glittercowboy no GitHub)

Esse repo original foi arquivado pelo dono em 26/06/2026 e hoje está somente leitura

O desenvolvimento migrou pra continuação mantida pela comunidade, o open-gsd/gsd-core

É o que tu acompanha hoje, beleza? Se cair num tutorial apontando pro repo antigo, tá olhando pra foto de um projeto congelado

No npm o pacote está na versão 1.10.0, licença MIT

E ele não é exclusivo do Claude Code: roda também em Codex, Antigravity CLI, Kimi CLI, Copilot e Cursor, entre outros

Os três pilares declarados:

• Engenharia de contexto: pesquisa, planejamento e execução pesada rodam em subagentes de contexto fresco, então a sessão principal não vira um depósito de arquivo lido
• Desenvolvimento guiado por especificação: artefatos antes da execução, ou seja, primeiro escreve o que vai ser feito, depois manda fazer
• Meta-prompting: as definições de agente são prompts engenheirados, que ficam em gsd-core/workflows/ e agents/

Se você já usou algum gerenciador de pacotes, a analogia mais próxima é essa: o GSD não muda o motor, ele padroniza o jeito de trabalhar em volta do motor

O trabalho anda num pipeline de fases: initialize, discuss, plan, execute, verify e ship

E todo o estado do projeto mora num diretório .planning/ na raiz do repositório, em arquivos Markdown ou JSON

"Mas por que Markdown?" Porque é legível por humano e commitável no git, o que faz TODA diferença no caso 4 lá embaixo

Caso 1: feature nova em uma base legada que você não conhece

A dor aqui é clássica: você entra num projeto que ninguém documentou, e o agente precisa entender o código antes de escrever uma linha

Aí ele começa a ler arquivo por arquivo, queimando contexto em descoberta

Quando chega a hora de implementar, a janela já está pela metade e a qualidade cai

Pilar que ataca: engenharia de contexto

O GSD Core tem comando próprio pra base já existente (brownfield): /gsd-onboard

Ele aciona o mapeamento quando ainda não existe mapa, e produz .planning/codebase/ mais um .planning/onboarding/SUMMARY.md

O mapeamento em si vem da skill gsd-map-codebase, que usa agentes mapeadores em paralelo

Tem duas flags que valem ouro no dia a dia:

• --fast faz uma varredura leve, com um agente só
• --query busca dentro do que já foi mapeado, em vez de reler a base inteira

A sacada é essa: a leitura cara acontece UMA vez e vira artefato

Depois disso, a sessão consulta o mapa em vez de refazer o trabalho

O sinal de reconhecimento: se você repete a mesma explicação da arquitetura em toda sessão nova, esse caso é o seu

Caso 2: refatoração ampla que não cabe em uma sessão só

Mudança que toca dezenas de arquivos é onde o vibe coding puro costuma se estrepar

A sessão enche, a qualidade despenca no meio do caminho, e você fica com metade do trabalho feito, sem histórico decente de quem mudou o quê

Pilar que ataca: desenvolvimento guiado por especificação, com apoio da engenharia de contexto

O artefato central aqui é o PLAN.md

Ele quebra o trabalho em tarefas discretas, ordenadas por dependência, cada uma com critério de aceite explícito

E tem uma peça que eu acho MUITO massa: antes de executar, um subagente chamado gsd-plan-checker valida o plano em oito dimensões, com loop de revisão de até três iterações até passar nos gates

Ou seja, o plano ruim é barrado antes de virar código ruim

As fases de planejar e executar (/gsd-plan-phase e /gsd-execute-phase) declaram effort: max pro runtime, sinalizando orçamento máximo de tokens

Tome cuidado com isso: fase pesada é fase cara, e vale casar com o resto das suas práticas pra gastar menos com o Claude Code no fim do mês

A execução também gera commits atômicos a cada tarefa concluída dentro do plano da fase

O princípio declarado é bem direto: commitar resultados, não processo

Então se a refatoração parar no meio, você não perdeu nada, o histórico conta a história

Caso 3: a mesma tarefa repetida em vários projetos e vários agentes

Essa dor é silenciosa

Você tem aquele prompt de sempre, o que monta o CRUD do jeito que você gosta, o que escreve teste no seu padrão

E aí reescreve ele em cada repositório, e de novo em cada ferramenta que você usa

Pilar que ataca: meta-prompting

No GSD as definições de agente são prompts engenheirados versionados, morando em gsd-core/workflows/ e agents/

Não é papelzinho colado no monitor, é arquivo

E aqui entra o detalhe da flag, que é o que confunde muita gente: --claude instala só no Claude Code, enquanto --all cobre todos os runtimes suportados de uma vez

Como esse caso é exatamente o de padronizar em várias ferramentas, o comando é o --all:

npx @opengsd/gsd-core@latest --all --global

Agora, nem toda tarefa merece o ciclo completo de pesquisa e planejamento, né?

Pra essas existe o caminho curto, o /gsd-quick, com variações --discuss --research, --validate e --full, além de /gsd-quick list, status e resume

Usar pipeline inteiro num ajuste de três linhas é o mesmo tipo de exagero de quem ignora quando não usar o Claude Code

Ceticismo saudável sempre: a ferramenta economiza contexto, não economiza julgamento

Caso 4: trabalho em equipe, quando o contexto precisa sair da sua cabeça

Em time a bagunça é outra

Cada pessoa carrega uma versão diferente das decisões do projeto, e o agente de cada uma responde diferente pra mesma pergunta

Aí vira aquele papo de "mas a gente não tinha combinado que não usava isso?"

Pilar que ataca: desenvolvimento guiado por especificação

A peça principal é o PROJECT.md, a fonte única de verdade do projeto

Ele é lido por todo agente em toda invocação, e guarda visão, restrições de arquitetura, decisões inegociáveis e regras de evolução

No mesmo .planning/ vivem também STATE.md, CONTEXT.md e config.json

Como tudo é Markdown ou JSON legível por humano, os artefatos podem ser commitados ao git e revisados como qualquer outro arquivo do repo

As preferências de implementação que vocês discutem não ficam soltas: o /gsd-discuss-phase captura elas no CONTEXT.md

E se o seu time preferir manter esse material local, dá pra definir commit_docs: false no /gsd-new-project ou via /gsd-settings, colocando .planning/ no .gitignore

Na hora de entregar, o /gsd-ship empacota o resultado como Pull Request: ele faz push da branch atual e monta o corpo do PR a partir de SUMMARY.md, VERIFICATION.md e ROADMAP.md

Dá até pra disparar um comando externo de code review, configurado em workflow.code_review_command

PR que se descreve sozinho é topzera pra quem vai revisar =)

Caso 5: migração, quando o antigo e o novo precisam conviver

Trocar framework, banco ou runtime tem uma característica cruel: o sistema antigo continua no ar enquanto você mexe

Quase sempre são duas frentes abertas ao mesmo tempo, e misturar as duas na mesma sessão é pedir pra confundir o agente

Pilar que ataca: engenharia de contexto, somada ao plano por fases

Pra isso o GSD Core cria workspaces isolados, pelo /gsd-workspace, com --new, --list e --remove

Cada workspace tem .planning/ independente, um manifesto WORKSPACE.md e cópias dos repos via git worktree (padrão) ou clone completo

Traduzindo: contexto separado pra cada frente, sem uma contaminar a outra

E o pipeline ajuda no resto, porque tem uma fase de verify antes do ship

Migração sem etapa de verificação é aquele salto no escuro que ninguém merece

Pra acompanhar de onde tá cada frente, o /gsd-progress mostra o relatório e roteia a próxima ação, e com --next ele mesmo avança

Resumo: qual dor, qual pilar e qual comando do GSD

Como instalar o GSD Core no Claude Code e por onde começar

1. Instale em modo global via npx

A flag decide o alcance da instalação, e é só isso que muda entre os dois comandos

Pra instalar apenas no Claude Code, a flag é --claude:

npx @opengsd/gsd-core@latest --claude --global

Se você usa mais de um agente de código no dia a dia, troca por --all, que cobre todos os runtimes suportados de uma vez:

npx @opengsd/gsd-core@latest --all --global

O erro comum deste passo: instalar só pro Claude Code, sentir falta do padrão no outro agente, e acabar mantendo dois jeitos de trabalhar

2. Escolha o ponto de entrada conforme o seu caso

Em base de código já existente, comece pelo /gsd-onboard, que dispara o mapeamento e gera o material em .planning/

Em projeto novo, o caminho é o /gsd-new-project: ele conduz o fluxo de perguntas, roda pesquisa de domínio opcional e gera requisitos e roadmap de fases

O erro comum deste passo: pular o mapeamento e mandar executar direto numa base que o agente nunca viu

3. Acompanhe com o /gsd-progress

Ele mostra o relatório e indica a próxima ação, e com --next avança sozinho

O erro comum deste passo: esperar ciclo completo em tarefa pequena, que pedia só um /gsd-quick

Não tenta rodar o pipeline inteiro no primeiro dia, beleza? Roda o comando de entrada, olha os artefatos que apareceram no .planning/, e só depois sobe pro fluxo completo

Conclusão

Se eu tivesse que resumir em uma frase: o GSD não deixa o Claude Code mais inteligente

Ele reduz o que a sessão precisa carregar, e transforma decisão em artefato que fica escrito no repositório

É menos "prompt secreto" e mais processo, e é por isso que o ganho aparece tanto nos 5 casos que a gente viu: base legada, refatoração ampla, tarefa repetida, time e migração

O próximo passo é bem concreto: identifica qual desses casos é o seu hoje, instala em modo global e roda só o comando de entrada correspondente

Depois disso você decide se o pipeline inteiro faz sentido pro seu jeito de trabalhar

E lembra do detalhe que economiza confusão: o repositório original está arquivado, então o que se acompanha hoje é o open-gsd/gsd-core

até o próximo post! 🙂