AIDive

Pack de vídeo

Superpowers para Claude Code: tabela de veredito, fontes, checklist e guia para ir além

9 min de leitura

TL;DR

  • Superpowers é um processo, não uma caixa de ferramentas: catorze skills em markdown que condicionam cada feature a uma sessão de brainstorming, um plano escrito e uma cadeia de subagentes novos, todos revisados.
  • Instale se as suas sessões de Claude Code constroem features que levam horas. Pule se o seu uso é script descartável e correção de duas linhas: a verificação de entrada roda em toda tarefa e nunca desliga.
  • O argumento dos tokens é real, mas vem de uma única seção de um único skill: Model Selection. O orquestrador atribui o modelo mais barato capaz de assumir o papel, então o modelo caro só toca na arquitetura e na revisão final da branch.
  • O repositório está saudável: 280,597 stars, 25,138 forks, 681 commits na main, release v6.3.0 em 2026-08-12, criado em 2025-10-09.
  • A reclamação que deu origem ao vídeo, estatísticas de uso de 1 a 3 por cento, não é um bug: significa que os skills nunca disparam no seu trabalho, então você paga o gate e não recebe nada em troca.
  • O caminho do meio cabe em uma frase no seu prompt: diga ao agente para pular o processo nas correções pequenas e deixe só o brainstorming rodar por alguns dias antes de adotar o resto.

O que as fontes dizem

Os números do repositório foram lidos em 2026-09-02: 280,597 stars, 25,138 forks e 681 commits na branch main, com o último commit na main datado de 2026-08-12 (v6.3.0) e um push posterior em 2026-08-31 numa branch que não é a main s1. A aba Issues mostrava 125 issues abertas naquele dia; o valor de 350 da API inclui as 225 pull requests abertas, então cite a aba, não a API, ao comparar com outros plugins s6. O projeto foi criado em 2025-10-09 e traz catorze skills s2. O post de lançamento do autor resume a aposta em uma linha: agentes de código não têm falta de capacidade, têm falta de disciplina, e essa disciplina pode ser distribuída como simples arquivos markdown que qualquer pessoa pode ler, fazer fork e editar s5. O plugin está listado na marketplace oficial, então a instalação é um único comando e as atualizações acompanham a marketplace s4.

O ponto de entrada é um skill que o hook de início de sessão carrega antes de qualquer outra coisa. Ele diz ao agente que, se houver qualquer dúvida sobre a aplicabilidade de um skill, ele deve carregá-lo e verificar, antes de responder ou escrever código. Essa regra é a fonte tanto do benefício quanto do custo fixo s14.

O brainstorming abre com um HARD-GATE: nada de código, nada de scaffolding, nenhum skill de implementação até você validar uma intenção explícita. Em seguida ele classifica o pedido em um de três caminhos: spike, quando o resultado é uma resposta e não código; bounded, para uma mudança pequena dentro de um fluxo que o repositório já tem; architectural, para tudo que reestrutura o projeto. O agente anuncia a classificação para você poder contradizê-la, e a catraca só gira para um lado: complexidade escondida descoberta no meio da tarefa sobe o caminho, nunca desce s9.

O skill de escrita de plano pede um plano escrito para um desenvolvedor competente que não conhece nada da sua codebase e, nas palavras do próprio arquivo, tem gosto questionável. O trabalho é cortado em tarefas cujos passos levam de dois a cinco minutos cada: escrever o teste que falha, rodar para vê-lo falhar, escrever o código mínimo, rodar os testes de novo, commit. Cada tarefa lista os arquivos exatos a criar ou modificar, até os números de linha, e o plano abre com um cabeçalho obrigatório s10.

A execução é o skill subagent-driven development: um subagente novo por tarefa, uma revisão depois de cada tarefa, uma revisão da branch inteira no final. A sessão principal para de programar e despacha. Cada subagente recebe apenas o contexto da sua tarefa, nunca o histórico da sua sessão, o que mantém a sua janela livre para coordenar. Depois que o subagente implementa, testa, faz commit e se autorrevisa, o orquestrador roda uma revisão em duas partes, primeiro conformidade com a spec, depois qualidade do código, com um lugar de revisor reservado para cada tarefa. O arquivo limita o loop a cinco rodadas no máximo por tarefa s11. O isolamento do trabalho é delegado a um skill de worktree, então um plano nunca roda no seu checkout atual s13.

A seção Model Selection começa com uma regra: use o modelo menos capaz que consiga assumir o papel. Uma tarefa mecânica bem especificada que toca um ou dois arquivos vai para um modelo pequeno; quando o plano já contém o código a escrever, implementar é transcrição mais testes, então o nível mais barato basta. Coordenação multiarquivo e debugging vão para um modelo padrão. Arquitetura e a revisão final da branch pedem o modelo mais capaz disponível. Dois detalhes importam na prática: sempre nomeie o modelo explicitamente no despacho, e deixe o orquestrador avaliar a dificuldade de cada tarefa antes de escolher s12. Esse é o mecanismo que torna o modelo caro viável no plano Pro de vinte dólares: ele só trabalha nas decisões que o merecem.

O ganho em documentação é um efeito colateral do processo. Specs e planos não são mensagens de chat que somem; são arquivos markdown salvos no repositório e commitados junto com o trabalho, então um revisor lê depois por que uma mudança foi feita, não só o que mudou s3.

O custo é o que o repositório não anuncia. O thread que originou o vídeo relata estatísticas de uso de 1 a 3 por cento e pergunta qual é a desvantagem além de não usar s7. A resposta nos arquivos é que o brainstorming adapta a cerimônia à tarefa, mas nunca pula a validação humana s9. Numa correção de duas linhas você ainda responde perguntas de enquadramento, aprova um design de duas frases e espera o ciclo completo. Briefs de despacho, duas revisões por tarefa e o registro de acompanhamento são tokens que você paga toda vez, e isso aparece nas menores tarefas. Estatísticas de uso baixas significam que os skills não casam com o seu trabalho, e esse é o sinal real a ler.

Veredito por tipo de uso

Seu uso de Claude Code Instalar? Por quê
Features que levam horas, vários arquivos, uma branch Sim O enquadramento evita construir a coisa errada, tarefas curtas mantêm o agente longe da saturação de contexto, a seleção de modelo estica a cota, a documentação nasce do processo
Misto: features em alguns dias, correções na maioria Sim, com uma regra de pulo Mantenha o gate para features, diga ao agente no prompt para pular o processo nas correções pequenas
Scripts descartáveis, typos de config, correções de duas linhas Não O custo fixo do gate roda em tarefas que não precisam dele
Curioso, mas ainda não pronto para adotar o método inteiro Só brainstorming Ele carrega a maior parte do ganho; os outros skills se encaixam naturalmente depois

Faça isto na segunda

  • Instale pela marketplace oficial e abra o cache do plugin: leia uma vez os catorze arquivos SKILL.md, são curtos e são o produto inteiro.
  • Passe uma feature real pelo gate de ponta a ponta: brainstorming, plano, despacho de subagentes, revisão da branch. Julgue o processo por isso, não por uma correção.
  • Confira suas estatísticas de uso depois de uma semana. Abaixo de poucos por cento, os skills não casam com o seu trabalho: ou suas tarefas são pequenas demais ou você precisa formular os pedidos como features.
  • Adicione uma regra de pulo às instruções do seu projeto: em correções de um único arquivo com poucas linhas, vá direto à mudança, sem brainstorming.
  • Copie a escada do Model Selection para os seus próprios prompts de subagentes mesmo que abandone o plugin: nomeie o modelo explicitamente em todo despacho.
  • Faça commit das specs e dos planos que o plugin escreve em vez de apagá-los; eles são o seu registro de design.
  • Conte as issues abertas na aba Issues, não pelo número da API, antes de comparar o projeto com outro plugin.

Para ir além

  • Leia o post de lançamento para entender a intenção de design antes dos arquivos de skills: ele explica por que a disciplina é distribuída como markdown e não como código s5.
  • A seção philosophy do README é a versão curta do método e o lugar para checar se ele combina com o seu jeito de trabalhar s3.
  • A seção skills library lista os catorze skills com uma linha de propósito cada; é mais rápido do que navegar pelo diretório s16.
  • O limite de cinco rodadas por tarefa do skill de subagentes é uma parada dura que vale copiar em qualquer orquestração que você escrever à mão s11.
  • Um thread pergunta se esse tipo de plugin sobrevive a modelos mais fortes; o que sobrevive é o gate de enquadramento e os planos commitados, o que os modelos absorvem é a mecânica s19.
  • Um relato de limite semanal de uso queimado pela cerimônia de orquestração é o contraexemplo a ler antes de adotar em trabalho pequeno s20.
  • A comparação com outro conjunto de instruções mostra a troca: menos skills, mais rígidos, contra um grande catálogo de regras s18.
  • A lista de issues abertas é a leitura mais rápida do que quebra hoje para outros usuários s6.

Fontes

FAQ

O Superpowers economiza tokens ou queima tokens?

Os dois. Em features, a seleção de modelo manda as tarefas mecânicas para modelos pequenos e guarda o modelo caro para a arquitetura e a revisão da branch, então a cota estica. Em correções pequenas, os briefs, as duas revisões por tarefa e o registro são overhead puro.

O que significam estatísticas de uso de 1 a 3 por cento?

Os skills só disparam quando uma situação casa com eles. Um número baixo quer dizer que as suas tarefas não são features no sentido do plugin, então você paga a verificação de entrada e nunca chega na parte que se paga.

Posso ficar só com uma parte?

Sim. O brainstorming sozinho carrega a maior parte do ganho, e a escada do Model Selection funciona em qualquer prompt de subagente escrito à mão. Diga ao agente para pular o processo nas correções mínimas e você mantém o controle.