Superpowers no Claude Code: quais skills o plugin traz e para que serve cada uma

O Superpowers não é um pacote de atalhos pra você digitar menos, é um método de trabalho inteiro fatiado em skills

Fala aí, beleza? Se você chegou aqui pesquisando o que o plugin realmente instala, a resposta curta é: um fluxo que vai do brainstorm até o fechamento da branch, cada etapa virando uma skill separada

E isso muda o jogo, porque a skill não é um prompt bonitinho guardado num arquivo, ela é uma REGRA de processo que o agente é obrigado a seguir

Então bora ver o catálogo, uma por uma, com o que cada skill faz e quando ela entra em cena 🙂

O que é o Superpowers e onde essas skills ficam:

O Superpowers é um framework de skills e metodologia de desenvolvimento para agentes, mantido pelo usuário obra no repositório oficial do Superpowers

Pré-inscrição Formação Claude Code

Domine o Claude Code do básico ao avançado

Você vai aprender a criar sistemas completos com Claude Code, sem precisar ser programador. Inscreva-se para ter acesso a um desconto de lançamento e bônus especiais!

Quero minha vaga

O plugin também está listado no diretório oficial de plugins da Anthropic

A instalação acontece dentro do próprio Claude Code, com /plugin install superpowers@claude-plugins-official

Agora a parte que interessa pra entender o catálogo: cada skill mora numa pasta própria dentro do repositório, no padrão skills/<nome-da-skill>/SKILL.md

Ou seja, skills/brainstorming/SKILL.md, skills/writing-skills/SKILL.md, e por aí vai

Que arquivo é esse? O SKILL.md é onde está escrito o comportamento da skill: quando ela dispara, o que ela exige antes de continuar, o que ela entrega no final

Isso é ótimo porque você não precisa confiar em resumo de ninguém (nem no meu haha), dá pra abrir o arquivo e ler o método na fonte

Se a dúvida que te pegou é mais parecida com reaproveitar skill entre projetos, vale a leitura separada, porque a lógica de escopo é a mesma pra qualquer skill

Tem ainda um segundo endereço importante: o repositório de skills editável pela comunidade, aberto a forks e pull requests

Tabela: cada skill do Superpowers e para que ela serve

Essa tabela é o índice do post, se liga nela antes de descer pros detalhes:

Skills de planejamento: brainstorming e writing-plans

brainstorming: a skill que segura sua mão longe do teclado

A brainstorming roda ANTES de qualquer código, em formato socrático: ela te faz perguntas e te apresenta alternativas até ficar claro o que você realmente quer

Parece perda de tempo, mas é o contrário: é onde você descobre que pediu um sistema de notificação quando queria só um alerta por email

O resultado não é conversa jogada fora, é um documento de design salvo em docs/superpowers/specs/

E o próprio SKILL.md já aponta o próximo passo: writing-plans

O cenário em que ela faz MUITA diferença é o clássico "Let’s build X", aquele pedido grande e mal definido que normalmente vira código zoado no modo 100% vibe coder

writing-plans: transformar o design em tarefas que dá pra checar

Com o design aprovado na mão, a writing-plans quebra ele em tarefas pequenas e verificáveis

Verificável é a palavra-chave aqui: tarefa que você consegue olhar e dizer "feito" ou "não feito", sem achismo

O plano é salvo em arquivo com data no nome, no padrão docs/superpowers/plans/AAAA-MM-DD-<feature-name>.md

Isso resolve um problema chato do dia a dia: o plano deixa de morar no chat e passa a morar no repositório, versionado junto com o resto

Skills de execução: executing-plans, subagent-driven-development e using-git-worktrees

executing-plans: rodar o plano que já está escrito

A executing-plans serve pra quando o plano já existe e você quer executá-lo

A orientação é rodar em sessão separada, com pontos de revisão ao longo do caminho

Por que sessão separada? Porque a sessão que planejou está cheia de discussão, alternativa descartada e contexto que só atrapalha na hora de implementar

subagent-driven-development: um subagente por tarefa

Essa aqui é a mais insana do pacote

Em vez de um agente só tocando o plano inteiro, a subagent-driven-development despacha um subagente NOVO por tarefa

E depois de cada tarefa vem revisão em dois estágios: primeiro conformidade com a spec, depois qualidade de código

É como contratar um cara diferente pra cada item da lista e colocar dois revisores atrás de cada um deles

Detalhe que não é opcional: ela exige workspace isolado, via a skill using-git-worktrees

Se você ainda está mastigando a diferença entre skill e subagente, esse é exatamente o ponto onde os dois conceitos se encontram na prática

using-git-worktrees: o pré-requisito que ninguém deveria pular

A using-git-worktrees cria um workspace isolado em git worktree, e ela é pré-requisito dos fluxos de implementação

Que workspace isolado? É uma cópia de trabalho separada da sua branch atual, pra que o agente mexa à vontade sem pisar no seu código aberto

Os locais suportados são dois: a pasta local do projeto .worktrees/ ou o global ~/.config/superpowers/worktrees/<projeto>/<branch>

Ela honra a preferência documentada no CLAUDE.md, então dá pra deixar isso decidido de uma vez pro repositório inteiro

E quando usa a pasta local do projeto, ela roda git check-ignore e adiciona a pasta ao .gitignore se for preciso

Ou seja: ela evita que você commite o worktree por acidente, o que é o tipo de vacilo que dá dor de cabeça depois

Qual dos dois executores usar?

O critério é simples de aplicar:

• plano curto, tarefas conectadas, você quer acompanhar de perto: executing-plans, com os checkpoints de revisão
• plano com várias tarefas independentes, e você quer contexto limpo e revisão dupla em cada uma: subagent-driven-development, lembrando que aqui o worktree isolado é exigência, não sugestão

Skills de qualidade: test-driven-development, systematic-debugging e requesting-code-review

test-driven-development: o teste falha primeiro, sem exceção

A test-driven-development impõe o ciclo RED (o teste falha), depois GREEN (implementa), depois REFACTOR

A regra que dá dente à skill é essa: o teste PRECISA falhar antes de você escrever a implementação

Parece detalhe bobo, mas é o que separa teste de verdade de teste que passa por acaso

Se o teste passou antes da implementação existir, ele não está testando o que você acha que está testando, beleza?

systematic-debugging: proibido remendar antes de investigar

A systematic-debugging aplica um processo de quatro fases pra caçar bug

A Fase 1 é investigação de causa raiz e tem quatro movimentos: ler o erro COMPLETO, reproduzir o problema, checar mudanças recentes e juntar evidência

E aí vem a regra de ferro da skill: nenhuma correção antes da investigação de causa raiz estar concluída

Essa é a skill que mais briga com o instinto do vibe coder, porque o instinto é colar o erro e pedir "conserta aí"

O resultado desse instinto todo mundo já viu: três correções empilhadas em cima de uma causa que nunca foi entendida…

requesting-code-review: revisor com contexto montado na hora

A requesting-code-review despacha um subagente revisor, e o pulo do gato é que o contexto dele é montado na hora, NÃO é o histórico da sessão

Por que isso importa? Porque o histórico da sessão já contém as justificativas do próprio agente que escreveu o código, e revisor contaminado não revisa, concorda

O template tem campos definidos: WHAT_WAS_IMPLEMENTED, PLAN_OR_REQUIREMENTS, BASE_SHA, HEAD_SHA e DESCRIPTION

O diff é montado a partir dos SHAs do git, então a revisão olha exatamente o intervalo de commits que você delimitou

O retorno vem organizado em pontos fortes, problemas priorizados em Critical / Important / Minor e uma avaliação geral

E o template do agente revisor está no próprio repositório, em skills/requesting-code-review/code-reviewer.md, se você quiser ler a régua antes de confiar nela

Fechamento e meta-skills: finishing-a-development-branch, using-superpowers e writing-skills

finishing-a-development-branch: teste como portão, worktree limpo no fim

A finishing-a-development-branch fecha o ciclo em quatro movimentos: verificar testes, apresentar opções, executar a escolha e limpar

O teste vem primeiro de propósito: ele funciona como portão, não como formalidade no fim

As opções de destino são quatro:

• merge local
• abrir pull request
• manter a branch como está
• descartar, com confirmação

E o destino do worktree muda conforme a escolha: ele é removido no merge local e no descarte, e preservado quando a branch é mantida ou vira PR

Faz todo sentido, né? Se o trabalho ainda vai ser mexido, o workspace continua de pé

using-superpowers: a skill que escolhe a skill

Quando mais de uma skill se aplica, alguém precisa desempatar

Esse é o papel da using-superpowers, que fica em skills/using-superpowers/SKILL.md

A regra dela é clara: skills de PROCESSO vêm primeiro, como brainstorming e systematic-debugging

E tem um gatilho explícito bem legal: um pedido do tipo "Let’s build X" aciona brainstorming antes de qualquer skill de implementação

Ou seja, é ela que impede o atalho que todo mundo tenta dar 😀

writing-skills: estender o framework com processo seu

A writing-skills existe pra você escrever novas skills dentro do próprio framework

O arquivo é skills/writing-skills/SKILL.md, com exemplos e boas práticas

Esse é o ponto em que o Superpowers deixa de ser um pacote fechado: seu processo interno de time pode virar skill do mesmo jeito que os outros

Como instalar o Superpowers e em que ordem acionar as skills

A instalação é feita de dentro do Claude Code, com o comando do diretório oficial de plugins:

/plugin install superpowers@claude-plugins-official

Com o plugin no lugar, a ordem de uso é essa aqui:

1. Instalar pelo comando acima, dentro do Claude Code. O erro comum deste passo é procurar instalação manual ou baixar pasta na mão: o comando do diretório oficial já resolve
2. Começar por brainstorming, não por "implementa pra mim". O erro comum deste passo é pular o brainstorm porque "a ideia já está clara na minha cabeça": clara na sua cabeça não é clara no design doc, e o documento que sai em docs/superpowers/specs/ é o que vai alimentar a próxima etapa
3. Gerar o plano com writing-plans. O erro comum aqui é aceitar tarefa grande demais: se o item do plano não dá pra verificar objetivamente, ele ainda não é uma tarefa, é um desejo
4. Escolher o executor e criar o worktree antes. Com plano curto, executing-plans e seus checkpoints; com várias tarefas, subagent-driven-development. O erro comum, e é o mais caro de todos, é rodar subagent-driven-development sem workspace isolado: essa skill exige o worktree criado pela using-git-worktrees
5. Revisar com requesting-code-review e fechar com finishing-a-development-branch. O erro comum deste passo é fechar a branch sem passar pelos testes, justamente o portão que a skill de fechamento coloca no caminho. E se apareceu bug no meio, systematic-debugging primeiro: nada de correção antes da investigação de causa raiz

Conclusão

O valor do Superpowers não está em prompt mágico nem em atalho secreto, está no MÉTODO que as skills obrigam você a seguir

Pensar antes de codar, planejar em tarefas verificáveis, isolar o workspace, deixar o teste falhar primeiro, investigar antes de corrigir, revisar com contexto limpo e fechar a branch direito

É tudo coisa que a gente já sabia que devia fazer, só que agora está escrito em arquivo e o agente cobra

Seu próximo passo concreto: instala, roda um brainstorming numa feature PEQUENA (nada de reescrever o sistema inteiro no primeiro teste) e depois abre o SKILL.md da skill que mais te interessou, no repositório oficial ou no repositório da comunidade

Ler o método na fonte vale mais que qualquer resumo, inclusive esse aqui haha

até o próximo post!