Vale a pena adotar o get-shit-done no Claude Code com o time?

Fala aí, beleza? Instalar um sistema sozinho é barato: tu roda, testa por dois dias e, se não colar, apaga a pasta e ninguém fica sabendo

Agora propor que cinco, dez pessoas mudem o jeito de trabalhar dentro do Claude Code, isso é outro esporte 😀

O get-shit-done se apresenta como um sistema de meta-prompting, context engineering e spec-driven development para o Claude Code, ou seja, a ideia é parar de improvisar prompt e passar a seguir um fluxo com fases e comandos

Só que na reunião ninguém discute filosofia, o pessoal vai direto no ponto fraco

Então este post não é venda: é uma checagem de objeções, com o que dá pra responder usando fato verificável e o que é melhor deixar em aberto

O que aconteceu com o get-shit-done original (e por que isso vai aparecer na reunião)

Começa pela linha do tempo, porque é a primeira coisa que qualquer líder técnico descobre ao abrir o repo

• O repositório gsd-build/get-shit-done foi arquivado pelo dono em 26 de junho de 2026 e está em modo somente leitura
• Ele tinha acumulado 64,7 mil estrelas no GitHub, então não é projeto obscuro que ninguém olhou
• A descrição do repositório credita a autoria a TÂCHES: "A light-weight and powerful meta-prompting, context engineering and spec-driven development system for Claude Code by TÂCHES"
• O mantenedor está sem resposta desde 1 de abril de 2026, com as contas sociais aparentemente removidas
• No meio disso apareceu um token $GSD na Solana associado publicamente a um rug pull
• Em 22 de maio de 2026 a comunidade lançou um fork, o open-gsd/get-shit-done-redux
• Depois a organização passou de gsd-redux para open-gsd e o repositório virou open-gsd/gsd-core, com as referências ao caso removidas

Antes que isso vire discussão boba na reunião, se liga num detalhe de grafia: no GitHub a organização é open-gsd, com hífen, e no npm o pacote que tu instala é @opengsd/gsd-core, sem hífen

É o mesmo projeto, só escrito diferente em cada lugar, então quando tu vir as duas formas no mesmo tutorial não é erro de digitação 🙂

Repara que tem duas coisas diferentes sendo misturadas quando alguém solta um "esse projeto morreu"

O código original está congelado, isso é verdade e está lá no aviso do GitHub

Mas o desenvolvimento ativo migrou pro gsd-core, que é a continuação comunitária do trabalho publicado originalmente no repositório arquivado

Se tu chegar na reunião sem essa linha do tempo na mão, a conversa acaba antes de começar

gsd-build/get-shit-done x open-gsd/gsd-core: o que muda na prática

Tabela curta, só com o que dá pra checar na fonte, pra tu levar como material de apoio

A linha da sintaxe parece detalhe bobo, mas é a que mais gera confusão no time

Tutorial antigo, print antigo, thread antiga: tudo isso vai mostrar /gsd: com dois pontos, e no gsd-core o comando é com hífen

Já me ferrei com coisa desse tipo em outra migração, o pessoal copia o comando do post velho e jura que a ferramenta está quebrada 😛

As objeções que o time vai levantar e como responder a cada uma

Aqui é o miolo do post

Separei por objeção, do jeito que ela sai na reunião mesmo, com a resposta honesta do lado

"O repositório está arquivado, isso é projeto morto"

O arquivado é o gsd-build/get-shit-done, desde 26 de junho de 2026, em modo somente leitura

O que segue vivo é o open-gsd/gsd-core, a continuação mantida pela comunidade a partir do trabalho publicado no repositório original

Os dois estão sob licença MIT, e é exatamente isso que permitiu o fork existir de forma legítima e permite o teu time manter a própria cópia se quiser

O que NÃO dá pra prometer: garantia de manutenção futura do gsd-core

Nenhum projeto open source dá essa garantia, e inventar uma aqui seria justamente o tipo de promessa que derruba a tua proposta na segunda reunião

"Teve história de token de cripto, não quero isso perto do nosso código"

Essa objeção é legítima e merece resposta com fato, não com "ah, mas o código é bom"

O registro público é este: o mantenedor original está sem resposta desde 1 de abril de 2026, as contas sociais aparentemente foram removidas, e existiu um token $GSD na Solana associado publicamente a um rug pull

O fork comunitário nasceu motivado por esse contexto e removeu as referências ao caso

Se alguém do time continuar desconfortável, a saída não é discutir: é apontar a licença MIT e a possibilidade de o time revisar o que está sendo instalado antes de liberar pra todo mundo

"E se a gente ficar preso no Claude Code?"

Essa é a objeção mais fácil de responder

O gsd-core não é exclusivo do Claude Code: ele suporta Claude Code, OpenCode, Antigravity CLI, Kimi CLI, Kilo, Codex, Copilot, Cursor, Windsurf e outros

Na hora de instalar, o runtime é uma flag, --claude no caso do Claude Code

Ou seja, se o time trocar de ferramenta lá na frente, o processo que vocês desenharam não vira lixo junto

"E os nossos artefatos de planejamento, ficam presos onde?"

Em nenhum lugar fora do repositório

Todo o estado do projeto vive no diretório .planning/ na raiz do repo, em Markdown ou JSON

Sem banco de dados, sem servidor, sem serviço externo

E aqui vale separar duas pastas que o pessoal mistura: o .planning/ é o ESTADO do teu projeto, o que o fluxo discutiu, planejou e verificou

Já o .claude/ na raiz é onde a instalação local escreve os arquivos do próprio sistema, ou seja, é a ferramenta instalada, não o teu planejamento

São coisas diferentes e não competem entre si: uma guarda a instalação, a outra guarda o trabalho

E como o .planning/ é arquivo de texto na raiz, dá pra commitar no git e o time inteiro enxerga o mesmo estado

Essa é a resposta mais forte pra quem tem trauma de ferramenta que sequestra o histórico do projeto: se amanhã vocês largarem o sistema, os documentos continuam lá, legíveis

"Esse fluxo todo não é pesado demais pro nosso ritmo?"

Depende do que o time chama de pesado, então melhor colocar o fluxo na mesa em vez de defender

O gsd-core organiza o trabalho num ciclo de fases: initialize, discuss, plan, execute, verify, ship

Cada fase tem comando dedicado, entre eles /gsd-new-project, /gsd-onboard, /gsd-discuss-phase, /gsd-plan-phase, /gsd-execute-phase e /gsd-verify-work

É processo explícito, e processo explícito sempre parece mais lento no papel do que o improviso

A pergunta honesta pro time não é "é pesado?", é "a gente já não faz discussão, plano e verificação de qualquer jeito, só que sem registrar em lugar nenhum?"

"Legal pra projeto novo, mas o nosso repo já existe"

Tem ponto de entrada diferente pra cada cenário

/gsd-new-project é pra projeto do zero

/gsd-onboard é pra começar dentro de um repositório que já existe

Escolher o comando errado aqui é o jeito mais rápido de dar má impressão logo no primeiro dia do piloto, então alinha isso antes

"Isso vai encher os nossos commits de markdown"

Existe configuração pra isso, chama commit_docs

E tem um comportamento que vale decorar: se .planning/ estiver no .gitignore, o commit_docs vira false automaticamente, independente do que estiver escrito no config.json

Ou seja, o .gitignore ganha da configuração

Se o time quer visibilidade compartilhada, os documentos precisam entrar no git

Se o time quer commit limpo, dá pra manter fora, só que aí some a parte de "todo mundo vê o mesmo plano", que é justamente um dos argumentos de adoção coletiva

O que o sistema diz atacar: context rot e sessão principal enxuta

Aqui eu preciso ser bem claro sobre o que é afirmação do projeto e o que é ganho comprovado

O problema declarado é o "context rot": a qualidade degrada conforme a janela de contexto vai enchendo

Se tu já passou três horas na mesma sessão e sentiu o modelo começar a esquecer decisão que ele mesmo tomou no começo, tu sabe do que estamos falando

O mecanismo declarado pelo gsd-core é rodar pesquisa, planejamento e execução em subagentes de contexto novo, mantendo a sessão principal enxuta

A analogia que ajuda: em vez de um dev fazendo tudo numa mesa cheia de papel até não caber mais nada, cada tarefa grande vai pra uma mesa limpa e volta só com o resultado

Agora o aviso: isso é o que o projeto afirma atacar, e o mecanismo está descrito na documentação

Este post NÃO afirma ganho medido de qualidade ou de velocidade, porque isso não está sustentado por fonte que eu possa citar aqui

Quem vai produzir esse número é o teu piloto, no teu repositório, com o teu time

Como fazer um piloto com o time sem bagunçar o repositório

A sequência abaixo é conservadora de propósito: só o que está na documentação, nada de passo adivinhado

Se a ideia é testar antes de espalhar, vale desenhar isso como um piloto com um time pequeno e não como decisão de empresa inteira

1. Escolha um projeto de baixo risco pro piloto. Nada de repo crítico com deploy diário, o objetivo é o time sentir o fluxo, não descobrir surpresa em produção

2. Instale em escopo local, dentro do projeto do piloto. A instalação local escreve no diretório .claude/ na raiz do projeto, e é aqui que entra o pacote npm @opengsd/gsd-core, sem hífen, do mesmo projeto que no GitHub aparece como open-gsd/gsd-core:

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

O --claude é a flag de runtime e o --local é a flag de escopo

O erro comum deste passo: copiar arquivos de agents/ ou commands/ do repositório na mão

A documentação orienta explicitamente a não fazer isso, porque o instalador aplica transformações específicas de cada runtime

3. Só vá pro escopo global depois que o piloto fechar. O global usa o diretório de configuração do runtime, por exemplo ~/.claude:

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

O erro comum deste passo: instalar global no meio do teste e achar que está usando a versão do piloto

Quando as duas instalações existem, a local tem precedência

4. Decida commit_docs e .gitignore ANTES do primeiro commit. Se .planning/ entrar no .gitignore, o commit_docs vira false automaticamente, e aí não adianta discutir depois por que os documentos não apareceram no PR de ninguém

5. Escolha o ponto de entrada certo. /gsd-new-project se o projeto do piloto nasce agora, /gsd-onboard se vocês vão rodar em cima de um repositório existente

6. Rode um ciclo completo antes de opinar. O ciclo é initialize, discuss, plan, execute, verify, ship, e julgar o sistema no meio do caminho é o mesmo que julgar code review olhando só o primeiro comentário 🙂

Veredito: em que time o get-shit-done faz sentido e em qual não faz

Faz sentido no time que já sente dor de sessão longa e quer processo versionado

Se vocês vivem repetindo contexto pro modelo, se cada dev planeja de um jeito e o plano morre no chat, o .planning/ commitado no git resolve um problema real de visibilidade, mesmo antes de qualquer discussão sobre qualidade de código gerado

Também faz sentido em time multi ferramenta, porque a lista de runtimes suportados vai bem além do Claude Code

Não faz sentido, ou pelo menos merece um "agora não", no time que tem política dura contra depender de projeto comunitário depois que o original foi arquivado

Esse pessoal não está sendo chato: o repositório original está mesmo em somente leitura desde 26 de junho de 2026, e o mantenedor está inacessível desde 1 de abril de 2026

Se a conversa de adoção no teu time ainda está travada em quantos assentos e quanto custa por dev, resolve isso primeiro, porque discutir sistema de prompting antes de fechar o básico é colocar o carro na frente dos bois

E o que não dá pra prometer, com base no que está documentado: número de produtividade, redução de retrabalho, garantia de manutenção futura e recurso específico de time além do compartilhamento de arquivos via git

Qualquer um que te prometer isso está vendendo, não avaliando

Conclusão

O resumo é simples: o get-shit-done original está arquivado, o gsd-core segue como continuação comunitária sob licença MIT, e a decisão de adotar com o time se ganha ou se perde nas objeções, não no hype

Próximo passo concreto pra esta semana: instala em escopo local num projeto de baixo risco, decide commit_docs e .gitignore antes do primeiro commit, e roda um ciclo inteiro do fluxo

Depois disso, senta com o time e reavalia com dado de vocês, não com estrela de GitHub

Se o teu time já rodou algo parecido, conta como foi, sempre rende papo bom por aqui

até o próximo post! 😀