O que é meta-prompting no Get Shit Done (GSD) e por que isso muda seu jeito de pedir código?

Fala aí, beleza? Existe um jeito de conversar com o Claude Code que quase todo mundo faz sem perceber: você digita o pedido, olha o resultado, reclama, digita de novo com outras palavras, e por aí vai

O problema não é o modelo, é que a decisão importante (o escopo, o critério de aceite, quando parar) mora na sua cabeça e some quando a sessão acaba

O GSD ataca exatamente isso, e ele diz o nome do remédio logo na primeira linha da própria descrição: meta-prompting, ao lado de engenharia de contexto e desenvolvimento guiado por spec 🙂

O que é o GSD (Get Shit Done) e onde ele vive hoje

A descrição oficial do projeto é curta e direta: "A light-weight and powerful meta-prompting, context engineering and spec-driven development system for Claude Code by TÂCHES"

Formação Recomendada

Formação Vibe Coding

Do Prompt ao Produto: Crie Software Real com IA

• 474 aulas
• 20 projetos
• 39h 27min

Conhecer formação

TÂCHES é a identidade usada pelo perfil glittercowboy no GitHub, onde o projeto foi publicado originalmente

Agora vem a parte que muita gente ainda erra ao procurar o repo: o repositório original do GSD foi arquivado pelo dono em 26/06/2026 e está read-only

O desenvolvimento ativo hoje é o GSD Core, em open-gsd/gsd-core, continuação mantida pela comunidade, descrita como "Git. Ship. Done Core"

Repara no trocadilho: a sigla continua sendo GSD, só que a continuação da comunidade reescreveu as três letras com outras palavras, uma versão mais apresentável do nome original 😛

É lá que estão código, issues, releases e contribuições

Tem ainda um projeto irmão na mesma organização, o open-gsd/gsd-pi, que carrega a mesma descrição de meta-prompting, engenharia de contexto e desenvolvimento guiado por spec, com foco em agentes trabalhando por longos períodos de forma autônoma sem perder o quadro geral

Meta-prompting na prática: o prompt vira artefato, não improviso

A documentação do GSD Core define o princípio assim: "meta-prompting (agent definitions themselves are carefully engineered prompts encoding hard-won knowledge about scoping tasks, verification, and escalation)"

Traduzindo pro nosso dia: a definição do agente JÁ vem com o conhecimento difícil embutido

Como fatiar uma tarefa, como verificar se ficou pronto de verdade, e quando escalar em vez de sair inventando

Se você conhece a diferença entre rodar um comando na mão toda vez e ter um script versionado no repo, é exatamente isso, só que aplicado ao texto que você manda pro agente

Que diferença isso faz na vida real? Se liga

No modo improviso, você lembra de pedir "escreve o teste antes" na segunda-feira e esquece na quinta

No modo meta-prompting, essa exigência não depende da sua memória: ela está escrita dentro do prompt que define o agente, e vale pra toda execução

O conhecimento sai da sua cabeça e vai pro artefato

É a mesma cabeça por trás de outros sistemas que reorganizam o jeito do agente escrever código: menos sorte, mais processo escrito

As três disciplinas do GSD: contexto novo, spec e meta-prompting

O GSD Core não trata meta-prompting como bala de prata

Ele combina três disciplinas, pareadas com subagentes de contexto novo

A documentação resume a divisão de papéis numa frase só: "fresh context ensures each agent reasons clearly, spec-driven artifacts ensure each agent reasons about the right thing, and meta-prompting ensures each agent knows how to reason about it well"

Repara que meta-prompting sozinho não salva ninguém

Um prompt maravilhoso apontado pro alvo errado continua entregando a coisa errada, só que com mais confiança 😛

Ele é a perna do COMO, e precisa das outras duas em pé

Por que isso existe: o context rot que degrada suas respostas

O problema que o GSD ataca tem nome: context rot

É a degradação de qualidade conforme a janela de contexto do agente vai enchendo

Você já viu isso acontecer: a sessão começa afiada, e lá pela terceira hora o agente esquece uma decisão que vocês tomaram no começo e refaz um trecho que já estava certo

A resposta do GSD Core tem duas frentes

A primeira é preservar artefatos do projeto, como STATE.md e CONTEXT.md, pra que o que foi decidido sobreviva a um reset de contexto

A segunda é delegar pesquisa, planejamento e execução a subagentes com contexto novo, em vez de empilhar tudo numa única conversa gigante

Onde o meta-prompting encosta no disco: a pasta .planning/

Conceito é bonito, mas eu gosto quando dá pra abrir o arquivo e olhar 😀

O GSD grava todo output relevante no sistema de arquivos, dentro de .planning/, em Markdown ou JSON legível por humano

Entre os artefatos citados na documentação estão CONTEXT.md, RESEARCH.md e PLAN.md, esse último com critérios de aceite explícitos

Os comandos de workflow do GSD Core mapeiam um pipeline de fases: initialize, discuss, plan, execute, verify, ship

E o /gsd-plan não começa do zero: ele carrega contexto anterior de PROJECT.md, REQUIREMENTS.md, STATE.md e CONTEXT.md já existentes

Ou seja, o histórico do projeto deixa de ser "aquela conversa que eu tive semana passada" e vira arquivo na raiz do projeto

O que muda no seu jeito de pedir código ao Claude Code

A mudança prática é mais de hábito do que de ferramenta, e ela cabe em três movimentos

O primeiro é parar de reescrever o mesmo pedido com palavras diferentes toda vez que o resultado sai torto

Se você já reformulou a mesma exigência três vezes, ela não é um pedido: é uma regra, e regra tem que morar em prompt salvo

O segundo é transformar as exigências recorrentes em texto fixo

Critério de aceite, jeito de verificar, limite de escopo, tudo isso pode viver na definição do agente em vez de depender de você lembrar na hora

O terceiro é tratar contexto como artefato em arquivo, não como histórico de chat

Histórico de chat some, enche e apodrece

Arquivo em .planning/ você abre, lê, corrige e versiona junto com o código

Quando vale adotar essa cabeça de meta-prompting

Nem todo trabalho pede esse nível de cerimônia, então vamos separar onde ele realmente paga

• Projeto longo que atravessa várias sessões: aqui o context rot é garantido, e ter STATE.md e CONTEXT.md no disco muda o jogo
• Codebase existente que precisa ser reconhecido antes de qualquer mudança: é o cenário clássico de estragar código alheio por falta de contexto
• Trabalho em equipe: quando o critério de aceite mora só na cabeça de uma pessoa, todo mundo revisa por achismo
• Time que roda mais de um agente de código: o instalador do GSD Core oferece Claude Code, OpenCode, Antigravity CLI, Kimi CLI, Kilo, Codex, Copilot, Cursor, Windsurf e outros, então a mesma disciplina atravessa as ferramentas

E se você ainda está decidindo se troca de fluxo, a régua honesta é testar no seu trabalho real antes de virar a chave de vez

Como instalar o GSD Core e ver os prompts por dentro

A melhor forma de entender meta-prompting é abrir os prompts e ler o que está escrito lá dentro

Bora?

1. Rode o instalador do pacote publicado no npm sob o escopo @opengsd

npx @opengsd/gsd-core@latest

2. Responda o runtime e o escopo que o instalador perguntar

Instalação global vale pra todos os projetos

Instalação local escopa a um único projeto e escreve no diretório .claude/ na raiz dele

O erro comum deste passo: escolher local achando que vai valer pra tudo, e depois estranhar que os comandos não aparecem no outro repositório

3. Se você já sabe que quer Claude Code em escopo global, dá pra pular essas perguntas usando a forma direta

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

As flags já dizem o runtime e o escopo, então é o mesmo instalador do passo 1, só que sem o papo

4. Use o comando de entrada certo pro seu caso

/gsd-new-project pra projeto novo

/gsd-onboard pra codebase que já existe

O erro comum deste passo: chamar o fluxo de projeto novo dentro de um repositório antigo e pular a etapa de reconhecimento do que já está lá

5. Não saia copiando arquivo na mão

A documentação de instalação é explícita: "do not copy files from agents/ or commands/ directly"

O instalador faz as transformações necessárias por runtime, então copiar as pastas manualmente te deixa com arquivos que não batem com o formato que a sua ferramenta espera

Esse é, disparado, o tropeço mais fácil de cometer quando a gente só quer "dar uma espiada" no repo

Conclusão

Meta-prompting é mudança de hábito antes de ser ferramenta

A virada é aceitar que o prompt não é conversa descartável: ele é ativo, versionado, revisável, com conhecimento difícil escrito dentro dele

O GSD só empacota essa ideia junto com spec e contexto novo, porque as três pernas seguram a mesa

Se quiser sentir na pele, o caminho é curto: instala o GSD Core pelo npx, roda um /gsd-plan e abre os artefatos que aparecerem em .planning/

Depois compara com o jeito que você pede código hoje, no improviso

A diferença fica bem visível 😀

até o próximo post!