Get Shit Done - sistema de desenvolvimento orientado por especificações com meta prompts

• Sistema leve que automatiza o desenvolvimento orientado por especificações (SDD) em ambientes como Claude Code, ajudando a concluir projetos sem fluxos de trabalho complexos
• Evita a degradação da qualidade do código gerado por IA (context rot) por meio de engenharia de contexto, estruturação de prompts baseada em XML e orquestração multiagente
• Automatiza todo o ciclo de desenvolvimento — definição da ideia → planejamento → execução → verificação — com comandos como /gsd:new-project, /gsd:plan-phase, /gsd:execute-phase
• Garante rastreabilidade e eficiência com commits atômicos no Git por unidade de trabalho e execução paralela em ondas (wave execution)
• Ferramenta usada por engenheiros da Amazon, Google, Shopify e Webflow para aumentar a confiabilidade e a produtividade do desenvolvimento com IA

---

Visão geral

• Get Shit Done (GSD) é um sistema leve de meta prompts e gerenciamento de contexto que funciona em diversos ambientes de desenvolvimento com IA, como Claude Code, OpenCode, Gemini CLI, Codex, Copilot e Antigravity
• Resolve o problema de context rot, em que a qualidade do contexto se degrada enquanto a IA escreve código, gerando resultados consistentes com base em especificações
• Funciona em Mac, Windows e Linux, e pode ser instalado com o comando npx get-shit-done-cc@latest

Contexto de criação (Why I Built This)

• Foi criado para resolver o problema de ferramentas voltadas a grandes organizações exigirem processos desnecessariamente complexos
• O GSD foi projetado com a ideia de manter a complexidade dentro do sistema e o fluxo de trabalho simples
• Internamente, ele executa engenharia de contexto, formatação de prompts em XML, orquestração de subagentes e gerenciamento de estado
• O usuário consegue concluir um projeto com comandos simples

Principais recursos e fluxo de trabalho (How It Works)

• Todo o processo de desenvolvimento é composto por 6 etapas

  1. Inicialização do projeto: coleta informações sobre ideia, restrições, stack tecnológica etc. e gera arquivos como PROJECT.md e ROADMAP.md
  2. Etapa de discussão: define os detalhes de implementação e gera CONTEXT.md
  3. Etapa de planejamento: realiza pesquisa em paralelo e monta o plano, criando unidades de trabalho em estrutura XML
  4. Etapa de execução: faz execução paralela em ondas com base em dependências, além de commit e verificação por tarefa
  5. Etapa de verificação: executa testes automáticos e confirmação do usuário; em caso de falha, gera automaticamente um plano de correção
  6. Iteração e conclusão de marcos: repete as etapas e depois aplica tags de release

• O Quick Mode processa rapidamente uma única tarefa e permite controle detalhado com as flags --discuss, --research, --full

Tecnologias centrais (Why It Works)

• Engenharia de contexto: gerencia o contexto do projeto em arquivos como PROJECT.md, REQUIREMENTS.md e STATE.md
• Formatação de prompts em XML: define cada tarefa com clareza e inclui procedimentos de verificação
• Orquestração multiagente: opera em paralelo agentes especializados em pesquisa, planejamento, execução e verificação
• Commits atômicos no Git: faz commits por unidade de trabalho para facilitar rastreabilidade e recuperação
• Design modular: permite adicionar, inserir e modificar etapas livremente, oferecendo gerenciamento flexível do projeto

Sistema de comandos (Commands)

• Fluxo principal: /gsd:new-project, /gsd:plan-phase, /gsd:execute-phase, /gsd:verify-work
• Suporte a design de UI: /gsd:ui-phase, /gsd:ui-review
• Análise da base de código: /gsd:map-codebase
• Gerenciamento de projeto: /gsd:add-phase, /gsd:insert-phase, /gsd:complete-milestone
• Utilitários: /gsd:quick, /gsd:health, /gsd:stats, /gsd:debug, /gsd:note etc.

Ajustes e configuração (Configuration)

• O arquivo de configuração .planning/config.json controla modo, detalhamento de etapas, perfil de modelo, agentes de workflow, paralelização e estratégia de branching do Git
• O perfil de modelo pode ser quality, balanced, budget ou inherit
• É possível ajustar qualidade e velocidade com toggles como workflow.research, workflow.plan_check e workflow.verifier

Segurança e solução de problemas (Security & Troubleshooting)

• Arquivos sensíveis como .env, secrets/, *.pem e *.key devem ser adicionados à deny list do Claude Code para bloquear acesso
• Se houver erro de reconhecimento de comando após a instalação, recomenda-se reiniciar o runtime ou reinstalar
• Em ambientes Docker, problemas de caminho podem ser resolvidos configurando CLAUDE_CONFIG_DIR
• A opção --uninstall remove todos os componentes

Comunidade e licença

• Há suporte a ports da comunidade para OpenCode, Gemini CLI e Codex
• Disponível sob a licença MIT
• “Claude Code is powerful. GSD makes it reliable.” — ferramenta que reforça a confiabilidade do Claude Code

[GN⁺]

Opiniões no Hacker News

• Eu costumava usar o Plan mode junto com o Superpowers, mas no fim senti que só o Plan mode já bastava
  Esses frameworks são bons para tarefas fire-and-forget que exigem pesquisa, mas pareciam consumir mais de 10x mais tokens
  A diferença na qualidade do resultado também não era tão grande, então eu batia com frequência no limite do Max plan

  • Eu peguei os recursos de brainstorm·design·implementation planning do Superpowers e os conectei a uma camada de implementação baseada em Ralph
    Quando o planejamento de implementação termina, ele segue automaticamente sem pedir minha entrada, mas precisa rodar dentro de um Docker sandbox
    É por causa das configurações de permissão perigosas, mas de qualquer forma acho isso mais seguro
    Por enquanto está funcionando bem e a produtividade aumentou, mas isso parece uma etapa intermediária da jornada
  • Eu fiz o contrário e migrei do Plan mode para o Superpowers
    Voltei a usar depois de ver o anúncio da versão mais recente, e os cross-checks e self-review em várias camadas deixaram os resultados mais estáveis
    Daria para fazer isso manualmente, mas o Superpowers automatizou o processo e ficou muito mais conveniente
  • Testei a mesma tarefa com GSD e Plan Mode, e o Plan Mode terminou até a implementação básica em 20 minutos, enquanto o GSD levou algumas horas
    O GSD gerou código considerando o contexto do projeto inteiro, enquanto o Plan Mode implementou só o necessário, em nível de MVP
    Dependendo do workflow e da escala do trabalho, os prós e contras ficam bem claros
  • O Plan mode do GitHub Copilot mudou de forma estranha recentemente depois da adição de plan memory
    A saída ficou mais prolixa, mas os detalhes ficaram mais vagos
    Só aumentaram etapas como “design” e “figure out”, e ele passa direto para a implementação sem perguntas de acompanhamento
  • Eu também tive uma experiência parecida. Queimei uma semana inteira de assinatura do Claude e créditos de API para conseguir só umas 500 linhas de código
    Às vezes ele manipulava os testes ou produzia resultados sem sentido
    No fim, concluí o MVP guiando tudo manualmente, e isso foi muito mais eficiente

• Hoje em dia existem frameworks meta demais desse tipo, mas quase não vi nenhum provar produtividade de fato
  A maioria só desperdiça tokens e ainda polui a context window
  No fim, o melhor para mim foi manter tudo simples: fornecer só a informação necessária e repetir Plan → Code → Verify

  • No texto de Apenwarr, “The AI Developer’s Descent Into Madness”, isso aparece como uma sátira da situação em que “o agente cria o próprio framework”
  • Eu mesmo criei um mini framework combinando Claude e Codex
    Quando vejo o Codex pegando erros que o Claude sozinho deixou passar, sinto que não dá para delegar tudo a um único agente
  • Eu uso uma abordagem de design visual de especificação
    Projeto o fluxo de telas do app em imagens e exporto isso em markdown estruturado, então o LLM entende o contexto por tela
    Comparado a specs baseadas em texto, isso ajuda a detectar com antecedência estados ausentes ou fluxos de erro
  • No fim, esses meta frameworks não passam de ferramentas de personalização como .vimrc ou .emacs.d
    São úteis para quem fez, mas para outras pessoas acabam parecendo inúteis

• Eu acho que sistemas Spec-Driven estão fadados ao fracasso
  Specs escritas em inglês não conseguem conectar o código real ao comportamento real
  Esse problema já foi resolvido com testes automatizados
  O comportamento do sistema precisa ser codificado em testes executáveis
  Mesmo quando o LLM gera a implementação, ele deveria escrever os testes primeiro e validar a consistência com mutation testing
  Organizei isso neste texto e neste exemplo no GitHub

  • Specs em linguagem natural não escalam, mas se for possível criar uma especificação formal (formal spec) a partir delas, talvez haja potencial
    No fim, isso precisa ser expresso em forma de código
  • Também houve um texto dizendo “A sufficiently detailed spec is code”, mas eu não consegui reproduzir os resultados da OpenAI
    Veja o link
  • Spec Driven Development tem um nome parecido com TDD, mas a direção é completamente oposta
  • Tratar testes apenas como resultado de uma spec é uma lógica equivocada
    A spec cobre um escopo muito maior do que os testes
    Também é comum o LLM ignorar os testes ou alterá-los arbitrariamente

• Eu uso um sistema de IA pessoal e estou pensando se devo torná-lo público
  Ele é tão customizado para o meu trabalho que manter uma versão pública separada parece um fardo
  Em vez de deixar outras pessoas usarem diretamente, quero compartilhar só os padrões, usando meu sistema como referência

  • Não é obrigatório fazer manutenção
    Na era da IA, só compartilhar inspiração e ideias já tem valor suficiente

• Usei o GSD num hackathon de equipe, mas ele demorou demais para entender a codebase e o consumo de tokens também foi pesado
  Também houve erros frequentes ao gerar transcrições do agente
  Era uma ferramenta exagerada para criar só algumas funcionalidades pequenas
  A lição foi simples — escrever boas specs + repetir o Plan mode foi muito mais eficiente

• As restrições de design do Beads me incomodavam, então criei eu mesmo uma ferramenta parecida
  Minha versão é baseada em SQLite e ainda adicionei sincronização bidirecional com o GitHub
  O ponto central é conversar primeiro com o modelo e criar um arquivo de spec claro
  Com esse arquivo, o modelo não esquece, e quanto mais detalhes houver, melhor fica a qualidade da saída
  Implementei como protótipo uma ideia que eu vinha amadurecendo havia muito tempo com o Claude, e o resultado ficou melhor do que eu esperava

  • Para ser um “molho secreto”, o RPI (research-plan-implement) já é um conceito presente na documentação oficial
    O modelo continua sendo um sistema probabilístico, então memória perfeita é impossível
    Embalar isso como se fosse uma nova técnica milagrosa é exagero

• Eu usei o Superpowers, e como este GSD parece parecido, fiquei curioso com a comparação

  • Usei os dois, e o GSD é excessivamente complexo e lento
    O Quick mode faz a ferramenta perder o propósito original, e o Superpowers ficou como um bom meio-termo
  • Prompts estruturados realmente ajudam
    Se você colocar esse tipo de framework no repositório e fizer a IA melhorar o próprio framework, isso também pode ser útil em trabalhos criativos
    Ainda assim, esse tipo de estrutura parece só um hack temporário; quando os modelos evoluírem o suficiente, isso deve desaparecer naturalmente
  • O Superpowers escrevia todo o código já na fase de planejamento, e depois os subagentes só copiavam aquilo, o que era ineficiente
    O GSD resolveu esse problema, mas como há etapas demais, ficou lento
  • Testei o Superpowers ao migrar meu blog de Hugo para Astro
    A spec criada pelo Superpowers era detalhada, mas deixou de fora algumas funções (como RSS e analytics), enquanto uma spec colaborativa que propunha migração em paralelo foi mais flexível
    No fim, pedi ao Claude para comparar e integrar as duas specs e produzir a versão final
    Veja a comparação detalhada
  • Nem sei se realmente precisa de um wrapper de CLI
    Só com Claude skills já parece perfeitamente viável

• Usei o GSD intensivamente por 3 meses e ele é muito mais maduro que o speckit que eu usava antes
  Até tarefas complexas ele automatiza em 95%
  Os 5% restantes eu fecho com testes manuais
  Com isso, até lancei um produto SaaS (whiteboar.it)
  O próprio modelo também melhorou, mas o ganho de produtividade foi real

  • Eu também tive uma experiência parecida
    Achei desperdício continuar pagando FreshBooks, então criei eu mesmo um app macOS em Swift com GSD
    Implementei com a Anthropic API até a extração automática de recibos e a categorização
    Começou como webapp, mas foi evoluindo para um app desktop completo com recursos como integração com câmera
    Graças ao GSD, consegui terminar meu app pessoal de contabilidade

• No fim, a ferramenta realmente necessária é uma ferramenta que economize tokens
  Mas ainda não existe nada assim
  Até o Claude Code gasta tokens demais em projetos grandes

  • Se for para recomendar uma, tem o RTK AI e o repositório no GitHub

• O nome “este pacote de arquivos Markdown” é cafona demais

  • Talvez ficasse melhor se estivesse numa pasta “Languages”
  • Ainda assim, não é pior que “gstack”, vai?