O que é o get-shit-done (GSD) e o que ele não é: os mitos sobre o sistema

Fala aí, beleza? Um nome desses é chamativo o bastante pra fazer meio mundo achar que saiu um modelo de IA novo pra brigar no topo…

Só que não é nada disso

O get-shit-done (GSD) é uma camada de fluxo de trabalho que roda POR CIMA de um agente que você já usa, e não um agente novo pra substituir o que tu tem instalado

Bora separar o que dá pra verificar do que inventaram sobre ele, mito por mito? 🙂

De onde vem o GSD: o repositório arquivado e o repositório ativo

O projeto original foi criado por Lex Christopherson, conhecido como TÂCHES, que no GitHub aparece no perfil glittercowboy

Aí vem a primeira confusão: o repositório gsd-build/get-shit-done foi arquivado pelo dono em 26/06/2026 e está somente leitura

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

Ou seja, ele não é mais a casa ativa do projeto

O desenvolvimento ativo hoje acontece no open-gsd/gsd-core, sob a organização Open GSD, num repositório criado em 22/05/2026

E isso derruba o mito do número que circula por aí

Aquelas 64.724 estrelas que aparecem em thread de rede social são do repositório ARQUIVADO

O repositório ativo tem 7.558 estrelas e 518 forks, e o ecossistema ainda inclui o open-gsd/gsd-pi, com 989 estrelas e 88 forks

Não é pouco, mas é bem diferente do número que te venderam, né?

O que o GSD é e o que ele não é: mito por mito

Olha a lista dos mitos mais comuns e o que a fonte do projeto de fato diz:

Repara que quase todo mito nasce da mesma raiz: gente tratando uma camada de workflow como se fosse um produto de IA concorrente

Como o GSD entra no seu fluxo: instalação e ciclo de trabalho

A melhor forma de entender que ele é camada, e não substituto, é ver por onde ele entra

Bora ver na prática?

1. Instale o GSD por cima do runtime que você já usa. Pro Claude Code, de forma global, a documentação de instalação do GSD Core traz este comando:

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

A mesma página diz que, se você quiser deixar a instalação só no projeto atual, é só trocar --global por --local

O erro comum deste passo: sair copiando arquivo das pastas agents/ ou commands/ na mão, porque "é só um monte de markdown"

Tome cuidado! O guia install-on-your-runtime, no próprio repositório do projeto, orienta usar o instalador justamente pra garantir a compatibilidade entre os runtimes

2. Entre pelos comandos de barra. Depois de instalado, os pontos de entrada são dois: /gsd-new-project pra projeto novo e /gsd-onboard pra codebase que já existe

Esse detalhe já mata o mito do substituto: os comandos aparecem DENTRO do agente que você já tinha

3. Olhe os artefatos que ele gera. O /gsd-new-project produz PROJECT.md, REQUIREMENTS.md, ROADMAP.md e o STATE.md inicial

Se você conhece a lógica de escrever a especificação antes de sair codando, é exatamente isso, só que costurado dentro do agente

4. Rode o ciclo por marco. O loop do GSD tem cinco passos: Discuss, Plan, Execute, Verify, Ship

E por que tanta cerimônia? Por causa do context rot

Que diabo é context rot? É a degradação da qualidade quando a sessão vai acumulando contexto e o agente começa a se perder no próprio histórico

A jogada do GSD é rodar pesquisa, planejamento e execução pesados em subagentes de contexto limpo, mantendo a sessão principal enxuta

Quando o GSD faz sentido (e quando ele não resolve seu problema)

Faz sentido quando:

• você vai começar um projeto novo e quer especificação antes do código, em vez de vibe coding puro que depois ninguém entende
• você caiu num codebase existente e precisa mapear o terreno antes de mexer, o caso clássico do /gsd-onboard
• suas sessões são longas e você sente a qualidade caindo conforme o contexto engorda
• seu time troca de runtime de agente e você quer um fluxo comum, já que o GSD roda em vários deles

Nesse último ponto vale a comparação: é o mesmo tipo de trabalho de organizar as habilidades do agente pra ele não escolher a ferramenta errada, só que aplicado ao fluxo inteiro do projeto

E ele NÃO é resposta quando:

• você está procurando um modelo mais capaz, porque o GSD não é um modelo
• você quer trocar o agente que já usa, porque ele depende justamente desse agente estar instalado
• você espera resultado sem passar pelas etapas de discussão e planejamento, que é o coração do ciclo

Não existe prompt mágico aqui, o trabalho de pensar continua sendo seu 😀

O que muda pra quem chegou agora pelo nome

Na prática, três consequências bem diretas

Primeira: instale a partir do pacote @opengsd/gsd-core e acompanhe o open-gsd/gsd-core, porque um monte de tutorial e link antigo ainda aponta pro repositório arquivado

Segunda: aquele número de estrelas que te impressionou provavelmente não é do projeto que você vai instalar de fato

Terceira: o GSD só faz sentido se você já tiver um runtime de agente rodando, porque ele é a camada de cima e não a base

Conclusão: um sistema de fluxo, não um atalho mágico

Recapitulando pra fechar

O get-shit-done é uma camada de meta-prompting, engenharia de contexto e desenvolvimento orientado a especificação, que roda sobre um runtime de agente já existente, se descreve como leve e é MIT e gratuito

Ele não é modelo, não é substituto do Claude Code e não é exclusivo dele

O próximo passo concreto é simples: instale no runtime que você já usa, rode /gsd-onboard num repositório existente e veja o ciclo Discuss, Plan, Execute, Verify, Ship funcionando no seu projeto

E acompanha o open-gsd/gsd-core como fonte atual, que é de lá que vem o que é verdade sobre o projeto hoje

até o próximo post! 🙂