Você terminou o prompt. Apertou enter.
O agent começou a escrever código antes de você tirar a mão do teclado. Escolheu uma biblioteca que você não queria, criou arquivo no lugar errado, e ignorou dois requisitos — porque nunca perguntou o que você precisava.
Quando você percebe, já está debugando uma saída que você não especificou.
O Superpowers existe pra corrigir exatamente isso. Não deixando o modelo mais inteligente — mas tornando impossível pra ele pular a disciplina que todo dev sênior aplica antes de encostar no codebase.
Informações verificadas no repositório oficial e nas notas de versão em agosto de 2026.
O que é o Superpowers em um parágrafo
É um framework open-source de agentic skills pra coding agents, construído por Jesse Vincent e o time da Prime Radiant.
Ele instala um conjunto de "skills" combináveis — guias de comportamento obrigatórios escritos como arquivos SKILL.md — que seu coding agent precisa ler e seguir antes de agir. A pilha padrão impõe um fluxo estruturado: primeiro discute o design com você, cria um git worktree isolado, escreve um plano de micro-tarefas com passos de verificação, e só então executa via subagents.
Está no GitHub com licença MIT e, em agosto de 2026, passa de 270 mil estrelas. Número de estrela mede atenção, não qualidade — mas nessa escala, pelo menos indica que muita gente tem o mesmo problema.
O problema que ele resolve
O modo de falha que ele ataca é específico e conhecido por qualquer um que usou coding agent em produção. Escrevi acima: você pede uma feature, o agent começa a escrever código na hora.
A causa raiz não é inteligência, é comportamento padrão. Modelos de linguagem são treinados pra serem imediatamente úteis. Esse instinto empurra eles a produzir saída o mais rápido possível. O que fica de fora é tudo o que um dev sênior faz primeiro: fazer as perguntas certas, esboçar a arquitetura, escrever o que vai construir antes de construir.
O Superpowers intercepta esse instinto no nível da sessão e passa ele por portões estruturados.
Lucas: Isso descreve com precisão a diferença entre "o agent entregou rápido" e "o agent entregou o que o cliente pediu". Já perdi tempo suficiente com a primeira pra saber que a segunda é a que fatura.
Quem construiu
Jesse Vincent criou o Request Tracker (o sistema de tickets open-source usado amplamente na comunidade Perl e além), foi responsável pelas releases da linguagem Perl 5, e cofundou a Keyboardio.
Ele escreveu a primeira versão do Superpowers em outubro de 2025 — na mesma semana em que a Anthropic lançou o sistema de plugins do Claude Code — e usa em desenvolvimento ativo desde então. A Prime Radiant, empresa que ele fundou no início de 2026, é hoje a casa organizacional do projeto.
Como o sistema de skills funciona
O que são as skills e como elas disparam
Uma "skill" no Superpowers é um arquivo SKILL.md com um guia de comportamento estruturado: quando ativar, quais passos seguir, qual verificação executar. O agent lê a skill relevante e segue. O mecanismo é isso. Sem modelo customizado, sem camada de inferência especial — apenas instruções estruturadas que o agent é obrigado a consultar.
A palavra-chave é "obrigado". A skill mestre (using-superpowers SKILL.md) é injetada no início de toda sessão via session hook. No texto dela está: "IF A SKILL APPLIES TO YOUR TASK, YOU DO NOT HAVE A CHOICE. YOU MUST USE IT." O modelo checa se existe skill relevante antes de qualquer resposta — inclusive antes de responder perguntas de esclarecimento.
As skills disparam por detecção de contexto, não por comando. Quando você descreve algo que soa como começar uma feature ("me ajuda a construir X", "quero adicionar Y"), a skill de brainstorming ativa. Quando o design foi acordado, a skill de worktree ativa.
O session hook é o que torna isso invisível: você não digita comando pra ativar o Superpowers — ele já está rodando desde que a sessão abriu.
Existe uma hierarquia de prioridade importante: instruções suas no CLAUDE.md, GEMINI.md ou AGENTS.md têm precedência sobre as skills. Se o arquivo do seu projeto diz "não use TDD", a skill que impõe TDD cede. Skills sobrescrevem o comportamento padrão do modelo, não a sua configuração explícita.
O fluxo central
O fluxo completo tem quatro fases obrigatórias:
Brainstorm — Antes de qualquer código, o agent pergunta o que você está tentando construir de verdade. Trabalha o design com você em blocos curtos o suficiente pra ler e responder, levanta edge cases, explora alternativas, e só produz um documento de design escrito quando você aprovou explicitamente.
Workspace isolado — Aprovado o design, a skill de worktree cria uma branch nova em um worktree isolado. Sua main não é tocada. O agent roda o setup do projeto e verifica uma baseline de testes limpa antes de qualquer coisa ser escrita.
Plano — A skill writing-plans produz um plano de micro-tarefas escrito, nas palavras dela, para "um dev júnior entusiasmado, sem bom gosto, sem julgamento, sem contexto do projeto e com aversão a testes". Cada tarefa tem 2–5 minutos de trabalho, caminhos de arquivo exatos, o código esperado completo e um passo de verificação.
Execução com TDD — Subagents percorrem o plano com disciplina estrita de red/green/refactor: escreve o teste, vê falhar, escreve o código, vê passar. Cada subagent começa limpo e passa por duas revisões antes de ter a saída aceita — primeiro conformidade com a spec, depois qualidade de código.
No meio do ano houve duas mudanças nesse fluxo que se sentem na prática. O padrão "executa três tarefas e para pra revisão" foi removido — planos agora rodam continuamente e param só quando aparece um bloqueio. E os comandos /brainstorm, /write-plan e /execute-plan estão sendo descontinuados; agora apontam pras skills correspondentes.
As skills principais da pilha padrão
brainstorming — o portão de design antes do código
Ativa quando o agent detecta que você está começando algo novo. A função é transformar um pedido vago em documento de design validado, por diálogo socrático. O agent não pergunta só "o que você quer" — ele expõe trade-offs de arquitetura, pergunta sobre edge cases que você não mencionou e apresenta o design em seções digeríveis pra sua aprovação.
Nada avança sem você aprovar. Esse portão evita o modo de falha mais caro: começar a construir a coisa errada.
Lucas: Pra freelancer isso vale dinheiro literal. O documento de design que sai daqui é o que você manda pro cliente antes de fechar escopo — e é o que te protege quando ele "lembra" de um requisito no final.
using-git-worktrees — ambiente isolado de execução
Cada sessão de desenvolvimento ganha seu próprio git worktree — um diretório isolado, na própria branch, separado da sua árvore de trabalho principal. A skill cuida da escolha de diretório, da verificação de segurança e do setup do projeto. O agent pode trabalhar numa feature enquanto você continua desenvolvendo na main sem conflito. Terminado o trabalho, a skill finishing-a-development-branch guia nas opções de merge, PR e limpeza.
Detalhe: os arquivos temporários gerados durante o SDD não ficam mais dentro de .git/, e sim num diretório .superpowers/sdd/ que se auto-ignora. O motivo é concreto — o Claude Code trata .git/ como caminho protegido e recusava escrita do agent, o que travava um subagent no meio da execução.
writing-plans — tarefas pequenas com verificação
O plano que o agent escreve é deliberadamente específico demais. Cada tarefa traz caminhos exatos, o código esperado completo e passos explícitos de verificação — o nível de detalhe que seria necessário se quem executa não soubesse nada do projeto.
À primeira vista parece burocracia. Até você entender por que funciona: isso obriga a fase de planejamento a expor toda suposição antes da execução começar. Ambiguidades que causariam retrabalho no meio da implementação são resolvidas em texto, que é barato, durante o planejamento.
subagent-driven-development — execução paralela
Em plataformas que suportam subagents, cada tarefa do plano é executada por um subagent novo em vez do agent principal continuar no próprio contexto. Isso resolve a deriva de contexto — a tendência de agents de longa duração se afastarem devagar da spec original conforme a janela de contexto enche de histórico irrelevante.
Cada subagent recebe só a tarefa que precisa cumprir e a seção relevante do plano. Depois vêm duas revisões: conformidade com a spec, e qualidade de código.
Em plataformas sem suporte a subagent, a skill executing-plans oferece alternativa sequencial. Segundo as notas de versão, a writing-plans não oferece mais escolha entre as duas — detectada a capacidade de subagent, o subagent-driven-development é obrigatório.
O que o Superpowers não é
Não é modelo nem ferramenta nova — é camada de comportamento
O Superpowers não mexe em pesos de modelo, não adiciona camada de inferência própria, não muda como o modelo raciocina. São arquivos SKILL.md e um session hook. Quem faz o trabalho continua sendo o Claude, o Codex ou a plataforma que você usa — o Superpowers só determina o que esse agent faz antes de começar a escrever código.
O framework é agnóstico de modelo por design: quando a Anthropic lança um Claude melhor, o Superpowers se beneficia automaticamente. A restrição imposta é de procedimento, não de arquitetura.
Isso importa pra decisão de adoção. Você não está apostando num novo provedor de modelo nem numa stack proprietária. Está adotando uma metodologia de desenvolvimento codificada como prompts estruturados. Se a metodologia não servir pro seu time, você remove o plugin. Nada na sua infraestrutura muda.
Mais uma mudança estrutural: as skills não vivem mais dentro do plugin. Foram pra um repositório separado (obra/superpowers-skills), atualizam sozinhas no início da sessão e podem ser forkadas. Ou seja, adaptar o conjunto de skills ao seu time não exige mais forkar o plugin inteiro.
Lucas: "Remove o plugin e nada muda" é o argumento que faz eu testar sem medo. O custo de errar aqui é meia hora, não uma migração.
Onde ele te atrasa
O pipeline brainstorm → plano → executa adiciona sobrecarga real: diálogo estruturado antes de o código começar. Pra um bug fix de duas linhas, isso é absurdo. Em prototipação exploratória, onde você está testando coisas de propósito sem spec definida, a fase obrigatória de brainstorming briga com o que você está tentando fazer.
Na real: o Superpowers funciona melhor quando você tem uma feature ou refactor claro e quer que seja feito de forma confiável. É a ferramenta errada pra "deixa eu testar uma coisa e ver o que acontece".
Dito isso, essa crítica ganhou uma resposta concreta no meio do ano: a cerimônia agora escala com a tarefa. Os pedidos são classificados como spike, bounded ou architectural; tarefas pequenas pulam o ritual de dois documentos. Mas todo caminho ainda para pra sua aprovação antes da implementação. Ou seja, a objeção do "pesado demais pra coisa pequena" não desaparece por completo, mas perdeu força.
Plataformas suportadas
Claude Code — plataforma principal, suporte completo a subagent, listado no marketplace oficial da Anthropic desde janeiro de 2026 (claude plugin add obra/superpowers), session-start hook totalmente suportado.
Codex (CLI e app) — suporte completo a subagent.
Cursor — suporte a plugin, executing-plans sequencial.
OpenCode e Copilot CLI — suportados; o Copilot CLI recebeu suporte a session-start hook numa versão recente.
Factory Droid, Devin CLI e Hermes Agent — entraram na documentação de instalação. No Devin, devin plugins install obra/superpowers funciona e as skills disparam sozinhas no início da sessão. O Grok Build CLI também aparece na documentação.
Gemini CLI — não é mais suportado. O Google descontinuou o Gemini CLI em 18 de junho de 2026; a extensão não pode mais ser instalada nem atualizada. O Gemini foi removido da documentação de instalação, das listas de plataformas com suporte a subagent e da descrição do eval harness, e a referência de mapeamento de ferramentas foi apagada. Material de abril ainda mostra ele como suportado — ignore.
As capacidades da plataforma determinam qual modo de execução está disponível: subagent-driven-development onde há suporte a subagent, executing-plans sequencial no resto.
Quando vale a pena
Use quando:
- Você está construindo uma feature com escopo grande o suficiente pra que começar sem spec te custe tempo de debug depois- Você já viu agents se desviarem do requisito original no meio da implementação e quer isso impedido estruturalmente- Você quer TDD imposto sem precisar lembrar o agent a cada tarefa- Você trabalha num codebase onde desfazer suposições iniciais erradas é caro- Você está delegando trabalho sério a um agent que vai rodar sozinho por uma sessão longa
Pule (ou invoque skills seletivamente) quando:
- A tarefa é uma correção de uma ou duas linhas com o problema já especificado- Você está explorando o espaço de solução de propósito, sem direção definida- O custo de tempo do planejamento supera o custo provável da execução não estruturada naquela tarefa
A pergunta certa é a da sobrecarga. O Superpowers paga o custo de planejamento em tarefas complexas — onde um agent não estruturado produziria saída errada exigindo correção pesada. Em tarefa trivial, não paga.
FAQ
P: Funciona com o Claude Code?
Sim — o Claude Code é a plataforma principal. A instalação sai pelo marketplace oficial da Anthropic (claude plugin add obra/superpowers) ou direto do repositório. O session-start hook integra completamente, as skills disparam sozinhas e o subagent-driven-development está disponível porque o Claude Code suporta subagents nativos.
P: A sobrecarga compensa em bug fix rápido?
Em geral não. Brainstorming e planejamento foram feitos pra trabalho em nível de feature, não pra correção pontual. Pra um fix pequeno e bem especificado, o Superpowers só adiciona processo. O próprio framework sabe disso: a skill mestre using-superpowers checa o contexto antes de invocar qualquer coisa, e pedidos simples que não casam com o padrão "estou construindo algo" podem não disparar o fluxo completo. Além disso, os pedidos agora são classificados como spike, bounded ou architectural, e tarefas pequenas pulam o processo de dois documentos. Ainda assim, se você quer certeza de que ele vai ficar fora do caminho em tarefa pequena, rode aquela sessão sem o plugin.
P: É gratuito e open source?
Licença MIT, totalmente gratuito. Sem limite de uso, sem assinatura, sem coleta de dados das suas sessões. O repositório de skills (obra/superpowers-skills) também é MIT e editável pela comunidade — você pode forkar, modificar skills pro seu projeto ou contribuir de volta. O plugin em si é uma camada leve que gerencia uma cópia local do repositório de skills; elas atualizam sozinhas no início da sessão.
P: Qual a diferença pro CLAUDE.md ou AGENTS.md?
CLAUDE.md e AGENTS.md são arquivos de instrução específicos do projeto — você escreve pra dar contexto persistente sobre projeto, preferências e restrições. É documentação que o agent lê no início da sessão. As skills do Superpowers são fluxos procedurais: não dizem só o que é o seu projeto, especificam qual processo seguir em cada tipo de tarefa. Os dois sistemas se complementam e foram desenhados pra coexistir. Em caso de conflito, as skills cedem às instruções do CLAUDE.md — se o arquivo do projeto sobrescreve um comportamento de skill, o arquivo do projeto ganha.
Conclusão
O Superpowers funciona. Mas não é pra todo mundo.
O valor está em recolocar a disciplina que o agent pula, e fazer isso sem você precisar lembrar toda vez. Você não está apostando num modelo novo — está instalando uma metodologia em markdown, e removendo se não servir.
Se você está construindo uma feature de escopo indefinido, ou já viu o agent se desviar da spec, vale testar. Instalação é um comando, licença é MIT, e desfazer é remover o plugin.
Pra uma correção de duas linhas, nem abre. Não foi feito pra isso, e ele mesmo diz.
Lucas: A parte que me convenceu não foi o TDD forçado. Foi o documento de design saindo antes do código — porque esse documento é exatamente o que falta na hora de discutir escopo com quem paga.
