Você já pediu pro Claude “implementar uma funcionalidade X” e recebeu de volta um código que funciona, mas que você nunca colocaria em produção sem reescrever a metade? O Superpowers existe justamente pra resolver isso.
É um framework open-source (github.com/obra/superpowers, MIT, criado por Jesse Vincent e o time da Prime Radiant) que empacota uma metodologia inteira de desenvolvimento de software em arquivos markdown. Hoje tem mais de 230 mil estrelas no GitHub e funciona em Claude Code, Cursor, Codex, Gemini CLI, Copilot CLI e mais alguns agentes.
A ideia central é simples: o problema dos agentes de IA programando não é falta de capacidade, é falta de disciplina. E disciplina, ao contrário do que parece, pode ser distribuída como texto puro — um conjunto de “skills” que o próprio Claude consulta antes de qualquer tarefa.
O que muda na prática
Sem Superpowers, você pede uma feature e o Claude parte direto pro código. Com Superpowers instalado, ele primeiro recusa — educadamente — a escrever qualquer linha antes de passar por um processo de verdade.
O fluxo completo, do “tenho uma ideia” até o merge:
Brainstorming
Antes de qualquer código, o Claude faz perguntas socráticas pra entender o que você realmente quer. Explora alternativas, te apresenta o design em pedaços curtos o suficiente pra você de fato ler, e só avança com sua validação explícita.
Git worktree isolado
Com o design aprovado, cria uma branch nova em um workspace isolado, roda o setup do projeto e confirma que os testes existentes passam antes de tocar em qualquer coisa.
Plano de implementação
Quebra o trabalho em tarefas de 2 a 5 minutos cada, com caminho de arquivo exato, código completo e critério de verificação. O padrão de qualidade é “um júnior entusiasmado, sem contexto do projeto e sem instinto pra testar conseguiria seguir isso sem se perder”.
TDD sem negociação
Cada tarefa segue RED → GREEN → REFACTOR: escreve o teste que falha, confirma que falha, escreve o mínimo de código pra passar, só então refatora.
Subagentes + revisão dupla
Com o plano pronto, você diz “go” e cada tarefa vira um subagente novo, sem o contexto acumulado da conversa principal. Depois de cada uma, revisão em duas etapas: primeiro contra o plano, depois contra qualidade de código.
Fechamento da branch
Testes verificados de novo, e você escolhe: merge, abrir PR, manter a branch ou descartar. O worktree é limpo no final.
Por que vale usar
O ganho não é só “código mais bonito”. São três coisas concretas.
Primeiro, rastreabilidade: cada subagente recebe uma tarefa pequena e isolada, sem o contexto poluído de uma conversa longa. Isso reduz o efeito de “o Claude esqueceu o que combinamos há 40 mensagens”.
Segundo, verificação antes de afirmação: a filosofia do projeto é “evidência antes de alegação” — o agente não declara algo como resolvido, ele mostra o teste passando.
Terceiro, portabilidade: o mesmo conjunto de skills funciona em times que usam ferramentas diferentes (Claude Code, Cursor, Codex), porque é tudo markdown e instruções, não código amarrado a uma plataforma.
A contrapartida é velocidade na primeira interação: você não tem código em 10 segundos, tem uma sessão de brainstorming. Pra protótipo descartável é overkill. Pra qualquer coisa que vai pra produção, é exatamente o atrito que falta hoje.
Exemplo: montando um bolão da Copa
Vamos seguir o fluxo real com um projeto concreto — um bolão pra Copa do Mundo, com pontuação por palpite de placar.
1. Brainstorming. Você escreve: “quero montar um bolão pra Copa”. O Claude, com Superpowers ativo, não escreve uma linha. Em vez disso, pergunta: quantos participantes? A pontuação é só “quem ganha” ou o placar exato vale mais? Fase de grupos e mata-mata pontuam igual? Existe ranking público ou só o total final? Depois de três ou quatro rodadas dessas, ele resume o design em um documento curto e pede seu “ok”.
2. Plano. Com o design fechado — palpite de placar exato vale 10 pontos, acertar só o resultado (vitória, empate, derrota) vale 5, errar vale 0 — o plano vira tarefas como: modelo de Partida, modelo de Palpite, função calcularPontos, endpoint de ranking. Cada uma com arquivo e teste esperado.
3. TDD na prática. O subagente que pega a tarefa de pontuação escreve primeiro o teste:
test("acerta o placar exato", () => {
const pontos = calcularPontos({
palpite: { golsCasa: 2, golsFora: 1 },
resultado: { golsCasa: 2, golsFora: 1 },
});
expect(pontos).toBe(10);
});
test("acerta só o vencedor", () => {
const pontos = calcularPontos({
palpite: { golsCasa: 3, golsFora: 0 },
resultado: { golsCasa: 1, golsFora: 0 },
});
expect(pontos).toBe(5);
});
test("erra tudo", () => {
const pontos = calcularPontos({
palpite: { golsCasa: 1, golsFora: 0 },
resultado: { golsCasa: 0, golsFora: 2 },
});
expect(pontos).toBe(0);
});Roda os testes. Falham — calcularPontos nem existe ainda. Isso é o RED, e é esperado. Só depois disso vem a implementação mínima:
function calcularPontos({ palpite, resultado }) {
if (palpite.golsCasa === resultado.golsCasa && palpite.golsFora === resultado.golsFora) {
return 10;
}
const vencedorPalpite = Math.sign(palpite.golsCasa - palpite.golsFora);
const vencedorResultado = Math.sign(resultado.golsCasa - resultado.golsFora);
return vencedorPalpite === vencedorResultado ? 5 : 0;
}Testes passam — GREEN. Só então entra refatoração, se fizer sentido.
4. Revisão. Antes de seguir pra próxima tarefa (o endpoint de ranking), um segundo subagente revisa: a implementação bate com o plano? Os nomes de variável e a estrutura do arquivo seguem o padrão do resto do projeto? Problema crítico bloqueia o avanço; o resto vira nota.
5. Fechamento. Com Partida, Palpite, calcularPontos e o ranking implementados e testados, o Claude pergunta se você quer abrir PR, mergear direto ou manter a branch pra mais ajustes.
O ponto não é que isso seja mágico. É que cada etapa fica registrada — design, plano, teste, código, revisão — em vez de um commit gigante que “parece funcionar”.