Spec-driven development com Claude, Codex e o plugin Superpowers

O prompt some no chat, a spec fica

Eu ainda falo com agentes por prompt direto. Essa é a interface. Mas quando o trabalho tem mais de um passo, o prompt não deveria ser o único lugar onde a decisão vive. Ele some no histórico do chat, se mistura com exploração e fica difícil de revisar depois que o diff existe.

A spec é a camada de compromisso. Ela nomeia o problema, a fronteira, os arquivos que provavelmente vão mudar, os checks que provam a mudança e o que o agente não deve fazer. O agente pode ajudar a rascunhar. O humano precisa aprovar.

Onde entram Claude, Codex e Superpowers

Claude Code e Codex já se sobrepõem no formato do trabalho que conseguem fazer: ler um codebase, editar arquivos, rodar comandos e carregar memória de projeto. O Claude Code documenta memória via CLAUDE.md, skills, hooks e sub-agents. O Codex documenta AGENTS.md, skills e subagents. A sobreposição ajuda. Ela deixa o processo com formato de ferramenta, sem deixar a ferramenta ser dona do processo.

O Superpowers fica acima disso como disciplina de workflow. Eu trato isso como um jeito de forçar etapas nomeadas no trabalho: destrinchar o formato, escrever o plano, executar conforme o plano, rodar testes, pedir review e verificar antes de concluir. O valor aparece porque os gates óbvios ficam visíveis exatamente no momento em que é fácil pular por cima deles.

A spec carrega as decisões

Uma spec útil não precisa ser longa por padrão. Ela tem que ser precisa o bastante para um segundo agente, ou o mesmo agente numa sessão nova, implementar sem redescobrir a decisão do zero.

O que você ganha com a spec

A spec parece burocracia, mas é o que torna o trabalho portátil. Quando os créditos acabam no meio da tarefa, ou você troca de um agente para outro, a próxima sessão não começa do zero. Ela lê a spec e retoma a decisão, em vez de redescobrir tudo a partir de um chat que nunca viu.

Essa portabilidade aparece em coisas menores todo dia. Uma decisão errada é pega numa spec de quinze linhas, não num diff de seiscentas. Uma interrupção, um limite de contexto ou um crash não apagam o plano. Outra pessoa do time implementa a partir da spec, sem a sua conversa, e os passos que a spec marca como independentes podem rodar em paralelo, em sessões ou subagentes diferentes.

O agente recebe um plano, não um desejo

Meu loop preferido é simples: escrever a spec, inspecionar o repo, transformar a spec em um plano pequeno, rodar a implementação e revisar o resultado com base na spec, não na confiança do assistente.

Em trabalho Angular, isso significa que o plano nomeia a fronteira real: estado de componente, stream RxJS, escopo de provider, comportamento de rota, edge case de hydration, test runner ou setup de MCP. Um plano que só diz 'modernize o componente' ainda é um desejo, não uma instrução: sobra pro agente adivinhar o resto.

Verificação vence confiança

Eu não aceito 'pronto' de um agente sem evidência. Para código, isso costuma ser teste, build, lint, validação de conteúdo, screenshots ou saída específica de comando. Para escrita, são filtros de voz, checagem de fontes e varredura de banlist. Trabalho diferente, mesma regra.

No review, eu procuro uma coisa mais concreta: o repo agora contém o comportamento pedido pela spec, com evidência anexada e sem estrago extra em volta.