O que é o get-shit-done (GSD), o sistema de meta-prompting para Claude Code?

Fala aí, beleza? Apareceu um nome esquisito no meio das timelines de quem vive dentro do Claude Code, e o nome é literalmente get-shit-done 😀

O get-shit-done (GSD) é um sistema de meta-prompting, engenharia de contexto e spec-driven development criado por TÂCHES, e hoje ele é tocado pela comunidade, não mais pelo autor original

Neste post eu te conto o que ele é de fato, quem criou, como funciona o ciclo de trabalho dele e, principalmente, em que pé o projeto está agora (porque essa parte muda a sua decisão de instalar ou não)

Que problema o GSD tenta resolver: o context rot

O próprio repositório original se descreve como um sistema leve e poderoso de meta-prompting, engenharia de contexto e desenvolvimento orientado a especificação (spec-driven development) para o Claude Code

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

São três palavras grandes pra um problema bem simples de sentir na pele

O problema tem nome no projeto: context rot

Que context rot? É a degradação da qualidade da resposta conforme a janela de contexto do modelo vai enchendo durante sessões longas

Tu começa a sessão e o agente parece um gênio, entende tudo, acerta de primeira

Duas horas depois ele esqueceu a decisão que vocês tomaram no começo, reescreve arquivo que já estava certo e inventa função que não existe

Não é impressão sua, e se você quiser enxergar isso em número dá pra medir o gasto de token da sessão antes de teorizar

Os três pilares declarados atacam exatamente esse ponto

• meta-prompting: em vez de você escrever o prompt bom na mão toda vez, o sistema estrutura o prompt pra você
• engenharia de contexto: controlar o que entra na janela, e não jogar o projeto inteiro lá dentro
• spec-driven development: a especificação vem antes do código, então o agente tem pra onde olhar quando a memória curta falha

É mais ou menos como trabalhar com escopo escrito em vez de combinar tudo no grito: se a pessoa esquece, o documento lembra

Como funciona o ciclo de trabalho do GSD

O GSD Core não trabalha em "pede e recebe"

Ele repete um mesmo loop de cinco etapas por fase, dentro de cada milestone

O ciclo declarado pelo projeto é este:

1. Discuss: conversar sobre o que vai ser feito antes de qualquer linha de código
2. Plan: transformar a conversa em plano
3. Execute: rodar o plano
4. Verify: checar se o que saiu bate com o que foi combinado
5. Ship: fechar aquela fase e seguir pra próxima

Repara que o nome de cada etapa já entrega a intenção: nada de sair executando, e nada de dar por pronto sem verificar

A milestone é o pedaço grande do trabalho, e dentro dela cada fase dá essa mesma volta completa

Quem criou o get-shit-done e por que o projeto mudou de casa

O criador é Lex Christopherson, que publica sob o nome TÂCHES e usa o handle glittercowboy no GitHub

O projeto pegou tração forte: o repositório original acumulou 64,7 mil estrelas no GitHub antes de ser arquivado

E aí a história vira

O repositório gsd-build/get-shit-done foi arquivado pelo dono em 26 de junho de 2026 e está somente leitura, ou seja, não é mais a casa ativa do desenvolvimento

O pacote npm original, o get-shit-done-cc, parou na versão 1.42.3 e está sinalizado no registro como This package is no longer supported

O motivo declarado pra criação do fork da comunidade é direto: sem contato com TÂCHES desde 01/04/2026, com as contas sociais aparentemente deletadas ou inacessíveis

Tem ainda um capítulo que apareceu na imprensa e que eu registro com a devida etiqueta de alegação: o token $GSD, ligado ao projeto, foi publicamente associado a um rug pull alegado após a saída do fundador, e o token havia vencido o Bags Hackathon

Isso é o que foi noticiado, e fica aqui como alegação, não como fato fechado

O que isso muda para quem quer usar o GSD hoje

Muda o endereço, basicamente 🙂

O repositório arquivado não recebe mais nada, e as contribuições vão para o open-gsd/gsd-core, que se apresenta como continuação do trabalho publicado originalmente por TÂCHES

A licença MIT foi preservada no fork, então a base legal continua a mesma

O pacote npm do fork também trocou de nome no caminho: era @opengsd/get-shit-done-redux e virou @opengsd/gsd-core, com o bin renomeado junto

E tem sinal de projeto vivo, não de museu: a v1.11.0 saiu em 19 de agosto de 2026

Agora o dado mais interessante pra entender o momento

Entre 2 e 31 de julho de 2026, o npm registrou 41.372 downloads do get-shit-done-cc original contra 38.843 do @opengsd/gsd-core

Ou seja: metade do mundo ainda estava instalando o pacote descontinuado nessa janela

Se você seguir um tutorial antigo, é bem provável que caia no lugar errado

GSD Core, GSD Pi e GSD Browser: qual é qual

O Open GSD não é um produto só, e isso confunde bastante gente que chega pelo nome antigo

São três coisas com papéis diferentes:

Na prática, quem chega falando "quero instalar o GSD" quase sempre quer o GSD Core

O que você precisa antes de instalar o GSD Core

O requisito é um só e é bem objetivo: Node.js 22

Se você está numa versão mais antiga, resolve isso antes, senão você vai perder tempo caçando erro que não é do GSD

E tem um ponto que muita gente não sabe: o GSD Core não é exclusivo do Claude Code

Ele instala em Claude Code, Codex, Gemini CLI, Cursor, Windsurf, Copilot e outros runtimes suportados

Isso importa na hora de escolher o escopo, porque se você pula de ferramenta durante o dia, faz sentido pensar onde o sistema vai morar

Como instalar o GSD Core no Claude Code

Passo a passo curto, só com o que está na documentação viva do projeto

1. Confirme que você está no Node.js 22

O erro comum deste passo é assumir que a versão instalada serve. Se o ambiente estiver numa versão mais antiga, corrija antes de rodar qualquer npx

2. Se você já usava o pacote antigo, saia dele primeiro

npx get-shit-done-cc --claude --global --uninstall

Pra escopo de projeto, troque por --local --uninstall

O erro comum deste passo é continuar usando o get-shit-done-cc, que está marcado como não suportado. Ele ainda está publicado no registro, então nada te impede de instalar, e é justamente por isso que tanta gente instala sem perceber

3. Instale o GSD Core no escopo global

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

4. Ou instale no escopo local do projeto

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

O erro comum deste passo é confundir os dois escopos: instalar local achando que vai valer em todos os projetos, ou instalar global e ficar procurando o sistema dentro do repositório

Se depois de instalar os comandos não aparecerem no Claude Code, vale seguir o mesmo caminho de diagnóstico de comando que não aparece que serve pra qualquer pacote desse tipo

5. Começando um projeto novo, use /gsd-new-project

6. Num repositório que já existe, use /gsd-onboard

O erro comum deste passo é pular o onboard e mandar o GSD trabalhar direto num código que ele nunca leu. Em repositório existente, o /gsd-onboard é a etapa em que o sistema entende o projeto antes de planejar qualquer coisa

Para quem o get-shit-done serve (e para quem não serve)

Serve bem pra três perfis

Quem faz sessão longa no Claude Code e sente a qualidade cair. Esse é o público-alvo declarado, já que o context rot é o problema que o sistema nasceu pra atacar

Quem quer trabalho fatiado em milestones, com especificação antes do código. Se você já sofreu com agente que executa antes de combinar, o loop Discuss, Plan, Execute, Verify e Ship é exatamente o freio que faltava

Quem não vive só no Claude Code. Como o GSD Core instala em Codex, Gemini CLI, Cursor, Windsurf, Copilot e outros runtimes, o mesmo jeito de trabalhar te acompanha quando você troca de ferramenta

Agora o contraponto honesto, porque nem tudo é festa

Se o seu uso é tarefa curta e pontual ("arruma essa função aqui", "escreve esse teste"), um sistema de fases vai te cobrar cerimônia pra pouco retorno

E se você foi atrás do projeto original pelo nome, vai cair num repositório arquivado e num pacote npm marcado como não suportado, o que dá a falsa impressão de que o GSD morreu

Não morreu, só mudou de casa

Conclusão

O get-shit-done é um sistema leve de meta-prompting, engenharia de contexto e spec-driven development criado por Lex Christopherson (TÂCHES) pra atacar o context rot

A história em volta do projeto ficou complicada: repositório arquivado desde 26/06/2026, pacote original marcado como não suportado, mantenedor sem contato desde 01/04/2026 e um token $GSD publicamente associado a um rug pull alegado

Mas a ideia continua viva, com licença MIT preservada e release nova em 19 de agosto de 2026

O próximo passo concreto, se você quiser experimentar: instale pelo @opengsd/gsd-core, entre por /gsd-new-project num projeto novo ou /gsd-onboard num repositório existente, e ignore o repositório e o pacote arquivados

É o mesmo sistema, só que no endereço certo 😀

Até o próximo post!