Guia · Agentes de código
Como dar poderes ao seu agente de código
Como instalar o Superpowers no Claude Code e no Codex e rodar o protocolo que faz o agente provar o que entregou — em vez de só avisar que terminou.
Contexto
Agente que avisa → agente que prova
Quem já usa Claude Code ou Codex conhece a cena: você pede uma mudança, o agente escreve muito código em poucos minutos e diz que está pronto. Aí você abre o diff (as linhas que mudaram) e encontra dois arquivos que ninguém pediu, nenhum teste e uma conclusão que ninguém rodou.
O problema não é o modelo, é a falta de processo em volta dele. Superpowers é um conjunto de skills (habilidades reutilizáveis que o agente carrega sozinho quando o assunto aparece) mais uma metodologia de desenvolvimento. Ele não troca o Claude Code nem o Codex: organiza como o agente entende, planeja, testa, executa, revisa e prova o trabalho. Modelo bom sem processo ainda improvisa.
Passo a passo
Como montar, na ordem.
- 01
Instale o Superpowers no Claude Code
Repositório oficial: github.com/obra/superpowers. Dentro do Claude Code, rode /plugin install superpowers@claude-plugins-official — é o marketplace (catálogo de plugins) oficial da Anthropic. Se preferir o marketplace do próprio projeto, rode /plugin marketplace add obra/superpowers-marketplace e depois /plugin install superpowers@superpowers-marketplace. Feche e abra uma sessão nova: plugin instalado só entra na sessão seguinte.
- 02
Instale também no Codex
No Codex CLI, abra /plugins, procure por superpowers e escolha Install Plugin. No app do Codex, clique em Plugins na barra lateral, entre na categoria Coding, localize Superpowers e clique no botão de mais. Cada ambiente instala separado: dar poderes ao Claude Code não dá poderes ao Codex. Depois de instalar, comece uma conversa nova.
- 03
Confirme que carregou antes de confiar
Evidência vale mais que suposição, inclusive na instalação. No Claude Code, rode /plugin e veja superpowers na lista de instalados; os arquivos ficam em ~/.claude/plugins/. O que você ganha são skills, não comandos: superpowers:brainstorming, superpowers:writing-plans, superpowers:executing-plans e outras. Elas se invocam descrevendo o que você quer — pedir para o agente clarear a ideia antes de codar já carrega a de brainstorming. Se ele ignorar, você ainda está na sessão antiga.
- 04
Escreva a regra da casa no arquivo que o agente sempre lê
Plugin instalado não substitui regra sua. Crie CLAUDE.md na raiz do projeto para o Claude Code e AGENTS.md para o Codex, e cole: antes de escrever código, confirme o objetivo e o critério de aceite; depois apresente o menor plano possível, escreva o teste que prova o comportamento, execute a mudança, peça revisão e só declare pronto com evidência rodada nesta sessão. Esse arquivo é o ativo — ele sobrevive à sessão, o chat não.
- 05
Abra toda tarefa pelo objetivo, não pelo código
Antes de qualquer arquivo, escreva duas linhas. Objetivo: impedir pedidos duplicados. Critério: duas chamadas com a mesma chave geram um único pedido. Critério que não pode falhar não é critério, é opinião. Com o plugin instalado, peça ao agente para clarear a ideia antes de escrever código: a skill de brainstorming entra sozinha e arranca isso de você antes de liberar a execução.
- 06
Exija o teste que falha antes, e só depois a mudança
Peça primeiro o teste que prova o comportamento esperado e confirme que ele falha pelo motivo certo: teste que nunca falhou pode não estar testando a sua mudança. Só então autorize a execução, e a menor possível. Refatoração de vizinhança, flexibilidade para o futuro e funcionalidade que ninguém pediu não entram no mesmo diff.
- 07
Feche com revisão fresh e evidência rodada agora
Peça a revisão em sessão nova (fresh: contexto limpo, sem o histórico de quem escreveu), porque quem escreveu o código é o pior revisor dele. Achado só bloqueia quando aponta arquivo, linha, a regra violada e uma reprodução. E só aceite pronto com o que rodou nesta sessão: saída do teste, build, diff final e screenshot quando houver tela.
Limites
O que isso não é.
Não é um modelo melhor — é processo em volta do mesmo modelo que você já paga.
Não é automático em projeto sem teste: sem um comando de teste que rode, o gate (porta de validação) do teste vira teatro.
Não é autonomia sem gente — o agente planeja, testa e revisa, mas quem decide que está pronto continua sendo você.
Riscos conhecidos
Erros que matam o projeto.
Instalar em um ambiente e cobrar o comportamento no outro.
Deixar o teste para depois do código.
Aceitar pronto sem evidência rodada na sessão.
Próximo passo
Quer esse processo rodando no repositório e no time que vocês já têm, com os gates ligados de verdade? O diagnóstico é gratuito e a gente te mostra por onde começar.
Continuar aplicando
Este guia é a primeira camada. A Comunidade é o acompanhamento.
Uma entrega prática por semana, o grupo fechado com o Gabriel presente e o acervo do que já foi publicado. Turma fundadora com 40 vagas, R$ 297 por ano — o preço trava enquanto você for assinante.
Ver a Comunidade