Como o get-shit-done organiza o trabalho no Claude Code: os três pilares e o ciclo de uma fase

Fala aí, beleza? Existe um ponto bem definido em que o Claude Code começa a errar num projeto longo: quando a conversa fica gorda e aquela restrição que você deixou clara lá no começo vira só mais uma linha perdida no meio de tudo

O get-shit-done se define como um sistema de meta-prompting, context engineering e spec-driven development para Claude Code, com a assinatura "by TÂCHES" na própria descrição oficial do repositório

A proposta é fácil de enunciar e chata de fazer na mão: quebrar o trabalho em fases e guardar o estado do projeto em arquivos no disco, não na memória da sessão

Neste post eu abro os três pilares e o ciclo completo de uma fase, só com o que a documentação declara. Sem comando inventado, sem passo mágico 🙂

O problema que o GSD ataca: context rot

O sintoma todo mundo já viveu: a qualidade cai sem aviso

Não tem erro na tela, não tem mensagem de limite, o modelo só passa a responder pior, esquecer o combinado e mexer onde não devia

A causa, na definição da própria doc:

Conforme a conversa cresce e a janela de contexto enche, a recuperação de informação enfraquece e o raciocínio degrada

As instruções iniciais (restrições, arquitetura combinada, casos de borda) passam a disputar atenção com tudo que veio depois

Esse é o tal do context rot, e ele não avisa quando começa

A solução que o sistema declara:

A sessão principal funciona como orquestrador fino e nunca toca arquivo-fonte: ela sobe agentes, coleta resultados, atualiza o estado compartilhado e roteia pro passo seguinte

Com isso, o contexto do orquestrador cresce devagar

O trabalho pesado desce pros executores, e cada executor da etapa Execute começa com uma janela limpa de 200 mil tokens

Pra prevenir a volta do problema, o estado mora fora da conversa: os arquivos da pasta de artefatos sobrevivem ao /clear e ao fechamento da máquina, e permitem que um subagente novo retome de onde o anterior parou

Os três pilares do get-shit-done e onde cada um aparece

Os três nomes da descrição oficial não são enfeite, cada um resolve uma coisa diferente e mora num lugar diferente do sistema

Se o terceiro pilar te soa familiar, é porque ele não é exclusivo daqui: a mesma lógica de spec, plano e tarefas aparece em como o Kiro organiza specs, com outra roupagem

De gsd-build a GSD Core: qual repositório usar hoje

Essa parte confunde muita gente que chega pelo nome antigo, então vamos aos fatos

O repositório original gsd-build/get-shit-done foi criado em 14/12/2025 e acumulou 64,7 mil estrelas

Ele foi arquivado pelo dono em 26/06/2026 e segue em modo somente leitura, sem reversão até 24/08/2026

O desenvolvimento continua hoje no open-gsd/gsd-core, repositório da comunidade que concentra código, issues, releases e contribuições, com a tagline "Git. Ship. Done – Core"

Por que o fork existe:

A discussão de abertura do GSD Core declara os motivos: sem contato com o mantenedor original (TÂCHES) desde 01/04/2026, contas sociais inacessíveis e o token $GSD publicamente associado a um rug-pull

É isso que está escrito lá, não é boato de timeline

O que você precisa antes de rodar o primeiro ciclo

A instalação atual é via npx, no modo interativo:

npx @opengsd/gsd-core@latest

Se você não quer prompt nenhum, dá pra escolher runtime e escopo direto na flag:

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

Tome cuidado com um detalhe: a documentação diz que o instalador é obrigatório por compatibilidade entre runtimes e proíbe copiar arquivos das pastas agents/ ou commands/ na mão

Parece bobo pular essa regra, mas é justamente ela que garante que o mesmo sistema rode em CLI diferente

E roda mesmo: além do Claude Code, o GSD Core suporta OpenCode, Codex, Copilot, Gemini CLI, Cursor, Windsurf, Cline e Kilo, entre outros, com flags equivalentes (--gemini, --codex, --cursor, --cline, --all)

Veio do pacote antigo? Se liga na migração:

A doc orienta NÃO rodar npx get-shit-done-cc --uninstall na migração, e usar npm uninstall no lugar

Depois, remover na mão só os caminhos que pertencem ao GSD, preservando arquivos seus como dev-preferences.md e USER-PROFILE.md

Por fim, reiniciar o runtime alvo pra ele recarregar o diretório de configuração

O ciclo de uma fase no GSD Core, passo a passo

O ciclo declarado tem seis passos: initialize, discuss, plan, execute, verify e ship

Cada passo tem comando dedicado, e os nomes são fixos com prefixo /gsd-. Bora ver a sequência?

1. Partida do projeto com /gsd-new-project (projeto novo) ou /gsd-onboard (repositório já existente). O erro comum deste passo é rodar o comando de projeto novo em cima de um repo que já tem código, quando o caminho declarado pra esse caso é o onboard

2. Discussão da fase com /gsd-discuss-phase. É aqui que as decisões daquela fase são fechadas e viram o CONTEXT.md dentro da pasta da fase

3. Planejamento com /gsd-plan-phase. Sem número de fase, o workflow lê o ROADMAP.md e mira a próxima fase ainda não planejada, gerando planos de implementação atômicos com critérios de aceite. O erro comum deste passo é atropelar a discussão e chegar no plan sem o CONTEXT.md da fase, ou seja, planejar sem as decisões que o próprio ciclo prevê

/gsd-plan-phase

4. Execução com /gsd-execute-phase. Ele descobre os arquivos de plano da fase, analisa dependências entre tarefas, agrupa em ondas de execução paralela, sobe um agente executor novo por plano, e cada executor commita o trabalho dele antes da próxima onda começar

5. Verificação com /gsd-verify-phase, o passo que confere o que foi feito antes de seguir. A ideia de deixar a checagem como etapa própria e não como confiança no output segue a mesma linha de modelos que checam o próprio trabalho em tarefas longas

6. Ship, o sexto e último passo do ciclo, que fecha a sequência da fase

Fora do ciclo: acompanhar e retomar

Dois comandos existem pra te situar entre uma fase e outra, e eles não fazem parte dos seis passos

O /gsd-progress --next mostra onde o projeto está e o que vem depois

Já o /gsd-resume-work lê o STATE.md pra retomar o trabalho. O erro comum aqui é tentar retomar rolando o histórico da conversa: o estado vivo está no arquivo, e é ele que o comando lê

Os arquivos da pasta .planning e o papel de cada um

Todos os comandos leem e escrevem numa pasta de artefatos na raiz do repositório, a .planning/

O ponto forte tá no formato: todo artefato é Markdown ou JSON, legível por humano e commitável no git

Ou seja, dá pra abrir num editor, revisar num pull request e discutir com o time como qualquer outro arquivo do repo, não é caixa-preta 😀

Quando esse fluxo compensa (e quando é peso a mais)

Olhando só pro que o sistema declara fazer, dá pra separar bem os cenários

Compensa quando:

• você começa um projeto do zero e quer visão, restrições e fases escritas antes da primeira linha de código
• você quer adotar o fluxo num repositório que já existe, caminho que o /gsd-onboard cobre
• o trabalho atravessa vários dias: os artefatos sobrevivem ao /clear e ao fechamento da máquina, e o resume lê o estado do arquivo
• o time quer decisão versionada no git, com o Markdown do plano entrando na revisão junto com o diff
• vocês usam mais de um runtime além do Claude Code, já que o instalador cobre Codex, Gemini CLI, Cursor, Cline e companhia

Tende a ser peso a mais quando: a tarefa é curta e vive num arquivo só

Discutir fase, planejar fase, executar em ondas e verificar pra trocar uma função de lugar é cerimônia demais pro tamanho do problema, né?

Vídeo: fluxos de trabalho assistidos no Claude

Pra começar do zero no assunto de delegar trabalho pro Claude, este vídeo do canal mostra o Claude Cowork num tutorial com 3 casos reais

Conclusão

Os três pilares do get-shit-done não vivem soltos: o meta-prompting está nos prompts engenheirados de workflows/ e agents/, o context engineering aparece no orquestrador fino e nos executores com 200 mil tokens limpos, e o spec-driven vira arquivo dentro da .planning/

Tudo isso se encaixa num ciclo de seis passos: initialize, discuss, plan, execute, verify e ship

Próximo passo concreto: instale pelo instalador oficial com npx @opengsd/gsd-core@latest, rode o comando de partida certo pro seu caso (/gsd-new-project pra projeto novo, /gsd-onboard pra repo existente) e abra os arquivos gerados antes de planejar a primeira fase

E não esquece: o repositório vivo hoje é o open-gsd/gsd-core, o antigo está arquivado em modo somente leitura

até o próximo post! 🙂