Superpowers conserta o Claude Code, mas cobra um preço

Superpowers é um plugin para o Claude Code escrito por Jesse Vincent, que lança ferramentas open source para desenvolvedores desde os anos 1990. Ele publicou o plugin em outubro e, menos de um ano depois, o repositório está em 280.000 estrelas e 25.000 forks, com o último push feito dois dias antes da nossa gravação. O projeto já está na sexta versão principal, com 681 commits na branch main, então não se trata de uma coleção de prompts que alguém abandonou depois do pico do lançamento.

Sinal	Valor
Estrelas no GitHub	280.000
Forks	25.000
Versão principal	6
Commits na main	681
Issues abertas	125

A aposta de Vincent cabe em uma frase: o que falta aos agentes de código não é capacidade, é disciplina. Essa disciplina vem em arquivos markdown simples que qualquer um pode ler, fazer fork e adaptar. Nós instalamos o plugin, lemos as catorze skills linha por linha e analisamos o que ele muda em quatro frentes: produtividade, confiabilidade do código, gasto de tokens e documentação.

Superpowers é um plugin gratuito e open source para o Claude Code. Ele fica no marketplace oficial de plugins da Anthropic e se instala com um único comando. A mesma metodologia existe para mais de uma dúzia de outros harnesses, incluindo Cursor, Codex e Gemini, cada um com seu próprio caminho de instalação.

O núcleo são catorze skills: arquivos de instruções em markdown que o agente carrega sempre que uma situação combina com eles. Brainstorming, escrita de planos, desenvolvimento por subagentes, desenvolvimento guiado por testes e debugging sistemático codificam, cada um, uma forma completa de trabalhar, com seus próprios checklists e guardrails. A skill de debugging proíbe propor uma correção antes de isolar a causa raiz. Uma skill de verificação faz o agente provar que o trabalho terminou, em vez de apenas afirmar isso. Cada skill se anuncia quando carrega, então você sempre sabe em que modo o agente está trabalhando.

Um hook no início da sessão obriga o Claude a checar, antes de cada tarefa, se uma dessas skills se aplica. A regra está escrita na skill de entrada: se houver ao menos um por cento de chance de uma skill ser relevante, o agente tem que carregá-la. O resultado se comporta menos como uma caixa de ferramentas e mais como uma metodologia de desenvolvimento injetada no agente.

Vincent conta a origem no blog dele. Ele criou as skills minerando 2.249 arquivos markdown de lições que os próprios agentes dele tinham aprendido, e depois testou os rascunhos contra esses mesmos arquivos. A metodologia foi extraída de falhas reais de agentes, não escrita a partir da teoria.

Brainstorming é a skill por onde tudo passa. No momento em que você pede uma feature, o Claude a carrega e atua como um especialista em requisitos durante toda a conversa de enquadramento. O método inteiro cabe em um arquivo legível.

O arquivo abre com um bloqueio duro: nada de código, nada de scaffolding, nenhuma skill de implementação de qualquer tipo até que você aprove uma intenção explícita. Nada é construído com base em um palpite, e o bloqueio vale para toda tarefa, por menor que pareça. Em seguida, a skill classifica cada pedido em um de três caminhos.

Caminho	Definição	Saída
Spike	Uma pergunta de viabilidade	Uma resposta, não código que você guarda
Delimitado	Uma mudança pequena em um fluxo que já existe no repositório	Uma mudança com escopo definido
Arquitetural	Qualquer coisa que reestrutura como o projeto se encaixa	Uma spec que você valida, depois um plano de implementação

O agente diz sua classificação em voz alta para que você possa contestá-la, e a catraca só gira em um sentido: complexidade escondida descoberta no meio de uma tarefa sobe o caminho de nível, nunca o contrário. O arquivo traz uma tabela de sinais de alerta, pensamentos como "isso é simples demais para precisar de um design", com a refutação logo ao lado: tarefas simples são exatamente onde suposições não examinadas custam mais caro. Até um spike mantém seu guardrail. O que o agente construir para responder à pergunta fica rotulado como descartável, e manter esse código vira um novo pedido a classificar.

Durante o diálogo, o agente faz as perguntas que um engenheiro líder faria e apresenta o design em seções digeríveis. No nosso próprio pipeline, essa fase já matou features que teríamos construído à toa.

A skill de escrita de planos abre com uma instrução que dá o tom: escreva o plano para um desenvolvedor competente que não tem nenhum contexto sobre o seu código e, nas palavras do próprio arquivo, tem gosto questionável.

Na prática, o trabalho é cortado em tarefas em que cada passo leva de dois a cinco minutos: escrever o teste que falha, rodá-lo para garantir que falha, escrever o código mínimo que passa, rodar os testes de novo, fazer commit. Uma ação, uma verificação, e o trabalho avança em commits frequentes. Esse é o ciclo do desenvolvimento guiado por testes, imposto por outra skill do plugin, então cada tarefa carrega seu próprio ciclo de testes.

Cada tarefa lista os arquivos exatos a criar ou tocar, até o número da linha. O plano abre com um cabeçalho obrigatório: o objetivo em uma frase, a arquitetura em duas ou três, a stack técnica, um link para a spec e as restrições globais do projeto copiadas palavra por palavra. Se a spec cobre vários subsistemas independentes, a skill exige planos separados, um por subsistema, cada um gerando software testável por conta própria.

O tamanho das tarefas é o coração do argumento de confiabilidade. Uma tarefa curta significa um agente que termina o trabalho com uma janela de contexto ainda quase vazia. Ele nunca chega ao momento em que a sessão estoura, o agente perde o fio e começa a inventar funções que não existem. Nenhuma demo de cinco minutos mostra esse problema, mas ele decide tudo em um projeto real: a qualidade de um agente no fim de uma sessão não tem nada a ver com a qualidade dele no primeiro prompt. Contexto menos saturado significa, mecanicamente, menos alucinações, e código que faz o que o plano dizia.

Na hora da execução, uma skill dedicada isola o trabalho em um worktree do git, uma cópia de trabalho separada do repositório, para que o plano rode sem atropelar o que você estiver fazendo ao lado.

A skill de execução conduz o desenvolvimento por meio de subagentes. Seu princípio cabe em uma linha do arquivo: um subagente novo por tarefa, um review depois de cada tarefa e um review amplo de toda a branch no final. Sua sessão principal vira um orquestrador. Ela não programa mais, ela despacha. Cada subagente recebe exatamente o contexto de que sua tarefa precisa e nunca o histórico da sua sessão, o que evita poluição de contexto e mantém sua própria janela livre para a coordenação.

O subagente pode fazer perguntas antes de começar, depois implementa, testa, faz commit e revisa o próprio trabalho. Quando termina, o orquestrador executa um review em duas partes, conformidade com a spec primeiro e qualidade do código depois, com um revisor dedicado para cada tarefa. Nada é improvisado: a skill traz um prompt modelo para cada papel (implementador, revisor da tarefa e o revisor que reconfere as correções), que o orquestrador preenche com o contexto da tarefa.

Resultado do review	O que acontece
Aprovado	O orquestrador registra a conclusão em um registro e avança no plano
Reprovado, rodadas 1 a 3	O implementador original retoma, já que conhece o código e as próprias escolhas
Reprovado, rodada 4	Um implementador novo é despachado em um modelo mais capaz
Reprovado, rodada 5	Um disjuntor dispara e o próprio orquestrador decide sobre cada ponto em aberto

A skill também evita o excesso oposto: um lote de tarefinhas mecânicas sai como um único despacho agrupado, revisado como uma unidade. Nada é mergeado sem passar por um revisor. O resultado é o que um time humano chama de processo de code review, só que roda sozinho, tarefa após tarefa.

O sistema de despacho abre a porta para um terceiro ganho: a economia de tokens. A skill tem uma seção de seleção de modelo que começa com uma regra: use o modelo menos potente que dê conta de cada papel. O orquestrador avalia a dificuldade de cada tarefa do plano e atribui o modelo correspondente.

Tarefa	Nível de modelo
Tarefa mecânica bem especificada em um ou dois arquivos, ou um plano que já contém o código a escrever	O nível mais barato (implementar vira transcrever e testar)
Coordenação entre vários arquivos, debugging	Um modelo padrão
Arquitetura, o review final da branch	O modelo mais capaz disponível

O arquivo acrescenta duas sutilezas. Primeiro, sempre nomeie o modelo explicitamente ao despachar: um subagente sem isso herda o modelo da sua sessão, geralmente o mais caro, o que anula toda a seção em silêncio. Segundo, o número de turnos vale mais que o preço do token. Os modelos mais baratos gastam mais turnos em trabalhos com muitos passos e acabam custando mais no total, e é por isso que revisores e implementadores que trabalham a partir de prosa recebem um piso um nível acima, em vez do mais barato.

Esse arranjo torna viável algo contraintuitivo: rodar Opus ou Fable, os modelos mais caros do catálogo, no plano Pro de 20 dólares. O modelo caro só trabalha nas poucas decisões que merecem, e o resto do plano roda em modelos que consomem uma fração da sua cota.

O último ganho é aquele em que ninguém pensa ao instalar o plugin. Specs e planos não são mensagens de chat que somem quando a sessão acaba. São arquivos markdown salvos dentro do repositório e commitados junto com o trabalho. A skill define o local: uma pasta de planos datada, um arquivo por feature, com o objetivo, a arquitetura e o link para a spec no cabeçalho.

A spec viaja com o plano, e conflitos entre os dois se resolvem a favor da spec: o documento é a autoridade, não a memória do agente. O histórico do git não diz mais apenas o que mudou. Ele diz o porquê, e o que o agente tinha decidido na época. Seis meses depois, mencionar o arquivo do plano em um prompt permite ao agente retomar o contexto da feature original na hora, e uma feature nova que toca o mesmo subsistema se apoia na spec existente em vez de redescobrir o terreno.

Não existe mais tarefa sem rastro: tudo que um agente fez no código deixou um documento para trás, do primeiro brainstorm ao último commit. O projeto resume sua filosofia em dois princípios, sistemático acima do ad hoc e evidência acima de afirmações. A documentação sai do processo por conta própria.

O limite é real e o repositório não o anuncia: toda essa disciplina tem um custo fixo, e esse custo nunca desliga. A skill de entrada é direta. Na menor dúvida, o agente tem que carregar a skill, e o arquivo de brainstorming afirma que a cerimônia escala com a tarefa, mas a aprovação humana nunca.

Em uma correção de duas linhas, isso significa responder perguntas de enquadramento, aprovar um design de duas frases e depois esperar o ciclo completo antes de ver a correção. Para um erro de digitação em um arquivo de config, o processo completo é simplesmente mais lento do que corrigir você mesmo. A orquestração em si consome tokens: briefs de despacho, dois reviews por tarefa e o registro são pagos toda santa vez, e é nas menores tarefas que você mais sente isso.

Também existe o sintoma oposto, e ele responde diretamente à pergunta do Reddit. Se suas estatísticas de uso mostram o plugin em uns poucos por cento, seus pedidos quase nunca acionam as skills, então você paga a checagem de entrada em toda sessão sem nunca tocar nos ganhos. Um loop de correção que vai até as cinco rodadas são cinco diffs, cinco reviews a mais e uma arbitragem, para uma tarefa que devia levar minutos. O projeto também nunca para quieto: foi da primeira versão à sexta em menos de um ano e ainda tem 125 issues abertas, então as skills que você lê hoje terão mudado na próxima atualização.

O plugin planeja a própria saída. Suas instruções colocam as suas diretivas acima das skills, então você pode dizer ao agente, explicitamente, para pular o processo. Nossa regra: Superpowers ligado por padrão para qualquer trabalho de feature, e um skip deliberado nas correções mínimas.

Seu uso do Claude Code	Veredito
Features que levam horas	Instale: o enquadramento evita que você implemente a coisa errada, as tarefas curtas mantêm o agente longe da saturação de contexto, a seleção de modelo estica sua cota, e você herda uma documentação que nunca teria escrito
Scripts descartáveis e correções pequenas	Passe reto: você pagaria o custo fixo do processo em tarefas que não precisam dele
No meio-termo	Instale e aprenda a dizer skip: uma frase no seu prompt devolve o controle para você

Se quiser testar sem adotar tudo, deixe só a skill de brainstorming rodar por alguns dias. Ela carrega a maior parte do ganho, e as outras skills se encaixam naturalmente depois dela. O plugin cumpre suas quatro promessas desde que você o alimente com features dignas da sua cerimônia. Ele agora roda nos nossos próprios projetos, e a fase de brainstorming é a que não desligaríamos mais. O repositório é gratuito e open source, com 280.000 pessoas na fila antes de você.