get-shit-done ou seu próprio fluxo de prompts no Claude Code: qual vale mais a pena?

Fala aí, beleza? A escolha real não é entre duas ferramentas, é entre dois processos: adotar um sistema pronto de fases e context engineering ou escrever suas próprias instruções na unha

E tem um detalhe que muda a conta: o get-shit-done saiu de projeto de um autor só e virou projeto de comunidade

O repositório original está arquivado, o desenvolvimento migrou pra outro lugar e o nome do pacote mudou no caminho

Então não dá pra responder "vale a pena?" só olhando o fluxo de comandos, tem que olhar quem mantém isso no ano que vem também

Aqui vai comparativo linha a linha, os três eixos que realmente decidem (custo de aprendizado, padronização e liberdade) e veredito por cenário, sem torcida pra nenhum lado 🙂

O que é o get-shit-done e em que pé está o projeto hoje

O GSD é um sistema de meta-prompting e context engineering: em vez de você conversar solto com o agente, ele impõe um loop de fases com um comando por etapa

A primeira versão saiu em dezembro de 2025

O problema que ele ataca tem nome: context rot, a queda de qualidade conforme o assistente vai enchendo a janela de contexto

A receita dele é externalizar estado em arquivos, quebrar o trabalho em planos pequenos, executar cada plano em contexto limpo e verificar contra objetivos explícitos

O repositório mudou de endereço (e de nome):

Se liga nisso, porque é a parte que mais confunde quem chega agora:

• o repositório original gsd-build/get-shit-done foi arquivado em 26 de junho de 2026, está somente leitura e não recebe mais commits, issues ou PRs
• ele acumulou 64,7 mil estrelas antes disso
• o desenvolvimento ativo continua como GSD Core, em open-gsd/gsd-core, que concentra hoje código, issues, releases e contribuições, com 8,5 mil estrelas
• licença MIT, governança comunitária

Pré-inscrição Formação Claude Code

Domine o Claude Code do básico ao avançado

Você vai aprender a criar sistemas completos com Claude Code, sem precisar ser programador. Inscreva-se para ter acesso a um desconto de lançamento e bônus especiais!

Quero minha vaga

E o autor original? Sem contato com o mantenedor original (TÂCHES, que no GitHub aparece como glittercowboy) desde 01/04/2026

Em 22/05/2026 o colaborador trek-e lançou a continuação em open-gsd/get-shit-done-redux, com o mesmo código MIT e 394 branches e 229 tags espelhados bit a bit

O nome "redux" era provisório: o repositório passou a se chamar open-gsd/gsd-core e o pacote npm virou @opengsd/gsd-core

A ordem dos fatos ajuda a não se perder: sem contato com o autor desde 01/04/2026, continuação da comunidade em 22/05/2026 e o repositório original arquivado em 26/06/2026

Na lista de principais contribuidores do open-gsd/gsd-core aparecem trek-e (2.982 contribuições), glittercowboy (945), Tibsfox (127), davesienkowski (125) e jeremymcs (122)

E repara num detalhe que confunde: glittercowboy é o próprio TÂCHES, e essa contagem é acumulada, veio junto no espelhamento bit a bit do fork, não é sinal de que ele voltou a tocar o projeto

Como instala e o que ele suporta:

A instalação atual do GSD Core é essa:

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

Requisito de runtime: Node.js 22, por causa do fetch nativo e da compatibilidade ESM

Tome cuidado com isso, porque é o tipo de detalhe que faz a pessoa achar que a ferramenta está quebrada quando na verdade é a versão do Node

E tem um ponto que muita gente não espera: o instalador pergunta o runtime e suporta vários agentes, não só Claude Code

Ele instala em Claude Code, Codex, Gemini CLI, Cursor, Windsurf, Copilot, OpenCode, Antigravity CLI, Kimi CLI, Kilo e outros

Dá também pra instalar só um pedaço, em vez de tudo: existem as flags --profile=core, --profile=standard (core mais gestão de fases), instalação completa por padrão, perfis combináveis (--profile=core,audit) e --minimal como apelido de --profile=core

O fluxo de comandos:

O ciclo é initialize, discuss, plan, execute, verify, ship, cada etapa com seu comando:

• /gsd-new-project
• /gsd-discuss-phase
• /gsd-plan-phase
• /gsd-execute-phase
• /gsd-verify-work
• /gsd-ship

O /gsd-execute-phase é o mais interessante por baixo do capô: ele descobre os arquivos de plano da fase, analisa dependências entre tarefas, agrupa em ondas de execução paralela, dispara subagentes por onda e coleta os resultados

O /gsd-ship fecha o loop: envia a branch da fase, cria um PR com corpo gerado automaticamente, opcionalmente dispara review e acompanha o merge

E tem o /gsd-progress, que mostra o relatório de progresso e roteia pra próxima ação: com --next ele avança automaticamente e com --do mapeia intenção em linguagem natural pro comando GSD adequado

Ou seja, você não precisa decorar a ordem, o próprio sistema te empurra pro próximo passo

E o episódio do token $GSD?

Essa parte precisa entrar, porque quem pesquisa o nome esbarra nela

O token $GSD, vencedor do Bags Hackathon, foi alvo de acusações de rug pull depois que o fundador afirmou que o produto estava obsoleto e sumiu

Rastreadores da comunidade acusam a retirada de cerca de US$ 500 mil via remoção de liquidez, venda de tokens e prêmios, e o market cap caiu pra aproximadamente US$ 97.600

O caso foi classificado como exit fraud de um único desenvolvedor, não injeção de malware nem ataque de cadeia de suprimentos

A comunidade forkou o projeto e concluiu uma auditoria de segurança

Traduzindo pro que interessa na sua decisão: isso é risco de governança, não de código comprometido

Muda a pergunta de "isso é perigoso de rodar?" pra "quem responde por esse projeto daqui a seis meses?"

O que significa montar seu próprio fluxo de prompts no Claude Code

O lado do "na unha" não é escrever prompt bonitinho no chat, é usar os mecanismos nativos de customização que o Claude Code já te dá

São eles:

• skills: ficam em .claude/skills/ (projeto) ou ~/.claude/skills/ (pessoal), cada uma é um diretório com um arquivo SKILL.md
• comandos: em .claude/commands/, continuam funcionando normalmente
• plugins: empacotam comandos, subagentes, servidores MCP e hooks, e instalam com um único comando

E os slash commands têm tipos distintos: os embutidos (/help, /clear, /model), as skills criadas como arquivos SKILL.md, os comandos que vêm de plugins instalados e os prompts de servidores MCP

Se você conhece a ideia de script no package.json, a analogia é justa: o comando é o atalho, a skill é a instrução que ele carrega

A graça é que o problema que os dois lados atacam é o MESMO

Context rot não é exclusividade de quem não usa framework: se você deixa a sessão inchar, a qualidade cai igual

O caseiro combate isso da mesma forma que o sistema pronto: externalizando estado em arquivos, quebrando o trabalho em planos pequenos, rodando cada plano em contexto limpo e verificando contra objetivo explícito

A diferença é que no fluxo próprio VOCÊ escreve essa disciplina, e ninguém te lembra dela quando bater a preguiça

E antes de sair criando skill do zero pra tudo, vale olhar o que já existe pronto: eu falei sobre como escolher skills do Claude em outro post, porque a mais popular nem sempre é a que encaixa no seu fluxo

Pra ver uma skill customizada fazendo trabalho de verdade, este vídeo do canal mostra uma skill que faz a IA ler seu código e desenhar a arquitetura sozinha (Archify)

get-shit-done x fluxo próprio: comparativo linha a linha

Lendo a tabela sem paixão: o GSD ganha em tempo até o primeiro uso, cobertura do ciclo e portabilidade entre agentes

O fluxo próprio ganha em liberdade e em não depender de ninguém

E o empate técnico está na padronização, porque os dois padronizam bem, só que um já vem padronizado e o outro exige que você versione a sua padronização no repositório

Custo de aprendizado, padronização e liberdade: os três eixos que decidem

Custo de aprendizado: pronto x iteração

No GSD você paga pra aprender um vocabulário

São comandos com nome, ordem e função definidos, e o /gsd-progress com --next e --do ainda te ajuda a não decorar nada, porque ele aponta o próximo passo e mapeia intenção em linguagem natural pro comando certo

No fluxo próprio você paga em iteração

Escrever SKILL.md é fácil, escrever um SKILL.md que faz o agente se comportar do mesmo jeito na décima vez é que dá trabalho

E esse custo não some depois do setup, ele volta toda vez que o modelo muda de comportamento

Padronização: só vale o que está versionado

Aqui o ponto é simples e as pessoas erram muito nele

Um conjunto caseiro de instruções que mora no ~/.claude/skills/ de cada dev NÃO é padronização, é preferência pessoal com nome bonito

Pra virar padrão, tem que estar no .claude/ do repositório, versionado, revisado em PR como qualquer outro código

O sistema pronto entrega isso de graça: todo mundo instala a mesma coisa, e a instalação por perfil ainda deixa você escolher o quanto de processo quer impor

Liberdade: editar um arquivo x conviver com as decisões

No fluxo próprio, discordou de uma regra? Abre o arquivo, muda a linha, pronto

No sistema pronto, discordou do pipeline de fases? Ou você convive com a decisão dele, ou mantém um fork

E fork é dívida: alguém no time vira o dono de reconciliar as mudanças de upstream pra sempre

O eixo extra que este caso impõe: quem mantém isso ano que vem

Esse é o eixo que normalmente ninguém coloca na planilha, e nesse caso ele é obrigatório

O projeto já trocou de mãos: o repositório original arquivado, o autor sem contato desde 01/04/2026, a continuidade tocada pela comunidade

A comunidade respondeu bem (fork com o código MIT espelhado, auditoria de segurança concluída, repositório ativo com contribuidores recorrentes), mas isso é um dado sobre o passado, não uma garantia sobre o futuro

Quem já viveu uma atualização de ferramenta que quebrou fluxos que estavam rodando sabe que dependência externa cobra o preço no pior momento possível

Qual escolher em cada cenário

Dev solo em projeto pessoal: o GSD Core resolve rápido, principalmente porque você não tem com quem combinar processo

Instalar por perfil e usar só o essencial evita o efeito "framework maior que o projeto"

Time pequeno querendo processo igual entre pessoas: aqui o sistema pronto brilha

Comando igual pra todo mundo, ciclo com verify e ship definidos, PR com corpo gerado automaticamente

Montar isso na unha é possível, só que é um projeto paralelo dentro do seu projeto

Equipe que usa mais de um agente: se metade do time está no Claude Code, uma parte no Codex e outra no Cursor, portabilidade deixa de ser luxo

O GSD Core instala nesses runtimes, o seu conjunto de skills não vai junto

Projeto com regras próprias fortes: se o seu ciclo já tem etapas obrigatórias que não batem com discuss, plan, execute, verify, ship, o pipeline de fases vira atrito

Nesse caso, fluxo próprio, sem drama

Empresa com restrição de dependência de terceiros: quando entrar dependência externa exige processo de aprovação, o histórico do projeto (original arquivado, continuidade comunitária) vai ser assunto na reunião

Ou você entra com fork interno, ou monta na unha

E as alternativas com outra filosofia:

Não é um duelo de dois, tem gente atacando o mesmo problema por caminhos diferentes:

• Superpowers: aposta em desenvolvimento guiado por testes e restringe o processo
• GSD: restringe o ambiente de execução com pipeline de fases
• Spec-Kit: é metodologia de especificação, estrutura o "o quê" sem definir o "como", e tem a maior compatibilidade entre agentes

Repara que a escolha é filosófica antes de ser técnica: você quer que te obriguem a testar, te obriguem a seguir fases ou te obriguem a especificar?

Veredito: quando o get-shit-done vale a instalação e quando não vale

Vale a instalação se você está em time, se mais de uma pessoa toca o mesmo repositório e se hoje cada um conversa com o agente de um jeito

Nesse cenário, ter o ciclo plan, execute, verify, ship com comando próprio e subagentes em ondas paralelas resolve mais problema do que cria

Também vale se você usa mais de um agente de IA, porque portabilidade você não constrói sozinho num fim de semana

NÃO vale se você é solo, já tem um jeito de trabalhar que funciona e o seu projeto tem regras específicas demais

Instalar um pipeline de fases em cima de um fluxo que já roda liso é trocar disciplina que você domina por disciplina que você vai ter que aprender

Agora, sem suavizar nenhum dos dois lados:

O ponto fraco do GSD é depender de um projeto que já trocou de dono uma vez, com o autor original fora desde abril de 2026 e a continuidade sustentada por voluntários

O ponto fraco do fluxo próprio é que ninguém conta: manter um conjunto de instruções VIVO custa tempo toda semana, e é justo o tipo de manutenção que a gente adia

E tem o caminho do meio, que eu acho o mais honesto pra maioria: instalar com o perfil mínimo (--minimal, que é apelido de --profile=core) e ir colocando as suas skills por cima

Você pega o esqueleto do ciclo sem engolir o framework inteiro, e a parte específica do seu projeto continua sendo sua

O que me faria mudar de ideia? Ritmo de manutenção do repositório ativo caindo

Se as releases e as issues do open-gsd/gsd-core esfriarem, a conta inverte e o fluxo próprio vira a aposta segura

Conclusão

No fim, a decisão não é sobre ferramenta favorita, é sobre processo

Os dois lados combatem a mesma coisa (context rot) do mesmo jeito: estado em arquivo, plano pequeno, contexto limpo, verificação contra objetivo explícito

A pergunta é só quem escreve essa disciplina: um projeto de comunidade ou você

Próximo passo prático, escolhe um dos dois:

1. roda o GSD Core num projeto descartável, com perfil mínimo, e vê se o ciclo de fases encaixa no seu jeito de trabalhar antes de adotar de vez
2. versiona duas ou três skills próprias no .claude/ do repositório e mede se o resultado do agente melhora de verdade

Depois de duas semanas de uso real, compara: menos retrabalho? Menos sessão que degringola no meio? Menos "peraí, como a gente faz isso mesmo?"

É isso que decide, não a contagem de estrelas 😀

até o próximo post!