Plugins Claude Code: como instalar e usar o Superpowers

Plugins Claude Code: o que é o Superpowers?

Superpowers é a biblioteca de skills de engenharia criada por Jesse Vincent, junto com as instruções que orientam um agente de programação a usá-las. No Claude Code, o assistente da Anthropic que trabalha com seu repositório, ele oferece fluxos para entender pedidos, planejar alterações, testar, depurar, delegar e concluir o trabalho em uma branch. Pense no manual de operação de uma oficina: as ferramentas já estão lá; o manual define a ordem do trabalho e as verificações antes da entrega. README do Superpowers

Verificado em 18 de outubro de 2026: o manifesto do código-fonte identifica a versão 7.0.0, e o repositório contém 15 pastas de skills no nível principal, cada uma com um arquivo SKILL.md. Esses dados descrevem o código consultado para este artigo; confira qual revisão o marketplace escolhido instala. Manifesto do plugin, diretório de skills

O principal atrativo prático é deixar visível a sequência de decisões. Antes de alterar uma funcionalidade, Claude pode definir o comportamento esperado. Antes de declarar o trabalho concluído, pode exigir um resultado de teste recém-executado. Essas instruções oferecem algo concreto para você avaliar, mas não garantem que os requisitos ou os testes estejam corretos.

Como instalar Superpowers no Claude Code

Dentro do Claude Code, use uma das formas de instalação documentadas no README do projeto. Os comandos abaixo foram copiados exatamente da seção sobre Claude Code. São comandos interativos iniciados por barra, e não comandos para colar em um terminal comum. Instruções de instalação no README

Plugin Superpowers: comando do marketplace oficial

/plugin install superpowers@claude-plugins-official

O criador também documenta um marketplace próprio. Se preferir essa opção, adicione o marketplace e depois instale o plugin:

/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace

Escolha uma origem que você consiga acompanhar. Não há vantagem em seguir as duas formas de instalação para configurar o mesmo plugin.

Depois de instalar, abra uma nova sessão do Claude Code para acionar o hook de inicialização. Faça um pedido com escopo delimitado, como adicionar um filtro a uma lista de tarefas existente. Observe se o agente anuncia uma skill adequada e segue as instruções dela. Concluir a instalação e ver o fluxo funcionar como esperado são verificações diferentes.

O que muda na sessão depois da instalação?

A primeira mudança está no contexto: um hook de inicialização insere as instruções de uso do Superpowers na conversa. O filtro configurado para SessionStart abrange startup, clear e compact. O script lê using-superpowers, injeta esse texto e orienta Claude a carregar outras skills pela ferramenta Skill. Ele não inclui o conteúdo completo de todas as skills na mensagem inicial. Configuração do hook, script de inicialização

Como Claude escolhe uma skill do Superpowers?

Claude compara a tarefa com as descrições das skills e então lê as instruções relevantes. O guia de criação de skills do plugin explica que a descrição deve indicar quando cada uma se aplica. As instruções iniciais mandam o agente fazer essa checagem antes de responder ou agir, anunciar a skill e usar as skills de processo antes das de implementação. Orientações sobre descoberta de skills

Assim, um pedido para construir algo aponta para brainstorming; um teste que falha aponta para systematic-debugging. Depois, uma skill específica da área pode orientar a implementação. Você também pode pedir uma skill pelo nome, por exemplo: “Use superpowers:systematic-debugging para investigar esta falha antes de propor uma correção.” Instruções de uso

A seleção automática é uma orientação ao modelo, não um mecanismo determinístico acionado por palavras-chave. O hook fornece as instruções iniciais; ainda cabe ao agente reconhecer a situação e seguir o fluxo escolhido. Se ele escolher o fluxo errado, corrija o escopo da tarefa ou peça diretamente a skill relevante.

Skills do Superpowers: quando usar cada uma

A biblioteca cobre todo o ciclo de desenvolvimento, mas cada sessão deve carregar as skills adequadas ao trabalho. Os nomes abaixo são exatamente os encontrados nos arquivos consultados. A coluna de aplicação resume as descrições e instruções; ela não garante que determinada frase sempre acione determinada skill. Diretório atual de skills

Você não precisa decorar a lista. No desenvolvimento de uma funcionalidade comum, observe as transições: pedido compreendido, plano concreto se necessário, implementação testada, alteração revisada e decisão de integração. No caso de um bug, o ponto de partida útil é a investigação, em vez de uma conversa de concepção de uma nova funcionalidade.

Como o Superpowers convive com o modo de planejamento nativo e suas skills?

Superpowers estabelece um fluxo em torno do planejamento; sua skill writing-plans é distinta do modo de planejamento nativo do Claude Code. As instruções iniciais atuais dizem expressamente para acionar brainstorming antes de entrar nesse modo, caso essa etapa ainda não tenha ocorrido. Portanto, elas definem uma ordem de operações, sem tratar o modo nativo e a skill de elaboração de planos como equivalentes. Instrução atual de planejamento

writing-plans gera um documento no repositório, normalmente em docs/superpowers/plans/, com decisões de implementação e verificações. Ao entregar o plano, pede que o usuário o revise e escolha uma forma de execução, salvo se ela já tiver sido informada. Apenas selecionar um modo não produz esse documento nem essas instruções de tarefa. Para entender os controles e o comportamento do Claude Code, consulte o guia do modo de planejamento do Claude Code.

Suas próprias skills continuam fazendo parte do processo. O arquivo writing-skills do plugin identifica ~/.claude/skills/ como o diretório de skills pessoais do Claude Code. As instruções iniciais também colocam explicitamente as orientações do usuário, incluindo CLAUDE.md e pedidos diretos, acima das instruções das skills. Assim, uma skill específica do projeto pode conter suas convenções, enquanto Superpowers fornece o processo de desenvolvimento. Defina bem essa divisão se ambos estabelecerem como os testes ou as revisões devem funcionar. Arquivo sobre criação de skills, prioridade das instruções

Para entender o conceito de arquivos de instruções por trás desse mecanismo, veja skills para agentes. Superpowers é uma coleção construída com ele e que adota uma forma específica de trabalhar.

Superpowers no Claude Code: uma funcionalidade da ideia ao merge

Um controle “Ocultar concluídas” basta para mostrar o fluxo completo. O exemplo a seguir foi elaborado a partir dos arquivos das skills; não é o registro de uma sessão de teste. Os nomes de arquivos, os casos de aceitação e o resultado são hipotéticos.

Imagine um aplicativo de lista de tarefas que já tenha testes. O usuário pede um controle para ocultar itens concluídos sem excluí-los. Neste passo a passo, ele solicita explicitamente um plano escrito e revisões de tarefas por subagentes. Sem esse pedido, uma mudança tão pequena seria candidata ao caminho mais curto, com o escopo combinado na conversa.

Definir o comportamento: brainstorming

A pergunta central é se “ocultar” afeta apenas a visualização atual ou altera as tarefas armazenadas. Neste exemplo, o comportamento acordado é um filtro que atua só na visualização: o controle começa desativado, os itens concluídos reaparecem quando ele é desativado e, quando o filtro deixa a lista vazia, a interface informa que não há tarefas ativas.

Claude confirma esse escopo com o usuário e obtém sua aprovação. Como o usuário escolheu a opção escrita, a especificação fica em um documento dentro de docs/superpowers/specs/, com uma verificação por quem vai implementar antes da entrega. No caminho habitual para pequenas mudanças, a skill permite que a descrição e o acordo fiquem na conversa. Regras de brainstorming

O que você deve avaliar é o acordo sobre o comportamento. Se ele acrescentar preferências salvas ou alterar o armazenamento das tarefas sem chamar atenção para isso, o escopo já terá crescido antes mesmo de começar a implementação.

Tornar o trabalho verificável: writing-plans

O plano divide a funcionalidade em entregas que podem ser verificadas de forma independente. Uma implementa a função de filtragem em um arquivo ilustrativo, src/tasks/filterTasks.ts, com testes para listas mistas, vazias e com todos os itens concluídos. Outra conecta um controle acessível em src/tasks/TaskList.tsx, usando a interface de função acordada e testando o resultado visível.

O plano especifica arquivos, interfaces, asserções de teste, comandos de teste do projeto e resultados esperados. Também registra que a filtragem deve manter intacta a coleção original de tarefas. O usuário revisa o plano e confirma a execução com subagentes. É aqui que uma orientação vaga passa a ser concreta o suficiente para que quem implementa e quem revisa possam apontar divergências com precisão. Instruções para elaboração de planos

Preparar o ambiente de trabalho: using-git-worktrees

Ao preparar a execução, Claude verifica se o trabalho já está isolado. Uma worktree do Git é outro diretório de trabalho do repositório, normalmente em uma branch própria. A skill dá preferência ao mecanismo nativo de worktrees do ambiente e respeita uma preferência já informada pelo usuário; caso contrário, pergunta antes de criar uma.

Neste exemplo, o usuário concorda em usar uma worktree para a funcionalidade. Claude executa ali os testes existentes do projeto antes de alterar o aplicativo. Falhas que já existam nesse estado inicial precisam de atenção antes que falhas posteriores possam ser atribuídas ao novo controle. Instruções sobre o ambiente de trabalho

Implementar as tarefas: subagent-driven-development e test-driven-development

O agente coordenador aciona um novo agente de implementação para a tarefa de filtragem e depois encaminha a tarefa para revisão. Só após essa etapa ele passa à tarefa de interface. A versão atual da skill de subagentes verifica a conformidade com a especificação e a qualidade do código na revisão de cada tarefa; depois, exige uma revisão mais ampla da branch concluída. Também mantém um registro de progresso e decisões específico para o plano. Fluxo com subagentes

Durante a implementação, test-driven-development fornece o ciclo vermelho-verde-refatoração. Aqui, um teste primeiro demonstra que solicitar a visualização filtrada ainda retorna uma tarefa concluída. Só depois de observar essa falha o agente implementa a filtragem, executa o teste novamente e melhora a organização do código mantendo os testes aprovados. Instruções de TDD

Na entrega de interface, a asserção útil verifica o que o usuário vê depois de acionar o controle. Um teste que apenas confira se uma função foi chamada não comprova o comportamento visível da funcionalidade.

A alternativa é executing-plans: Claude implementa o plano na própria sessão e, quando há subagentes disponíveis, aciona ao final um novo revisor para toda a branch. Escolha esse caminho quando a revisão de cada tarefa entre agentes não for a estrutura de revisão de que você precisa. Instruções de execução na própria sessão

Tratar os problemas encontrados: skills de revisão e systematic-debugging

Na revisão final da branch, requesting-code-review organiza o encaminhamento ao revisor. Suponha que ele descubra que desativar o controle não faz as tarefas concluídas reaparecerem. receiving-code-review orienta verificar essa observação no código e no comportamento esperado antes de alterar qualquer coisa. Solicitação de revisão, recebimento de comentários

Se a falha for reproduzida, systematic-debugging orienta a investigação. Suas fases passam por investigação da causa raiz, análise de padrões, teste de hipóteses e implementação. No exemplo, uma hipótese seria que o código substituiu a coleção original pela coleção filtrada. Examine esse fluxo de dados, reproduza a perda e corrija a causa com um teste de regressão. Não se limite a forçar o estado visual do controle para que ele pareça correto. Instruções de depuração

Comprovar a conclusão e decidir o merge

verification-before-completion exige resultados de comandos recém-executados antes de qualquer afirmação de sucesso. Para essa funcionalidade, isso significa apresentar evidências do comportamento do filtro, da interação com o controle e das verificações relevantes do projeto, deixando claras as falhas ainda não resolvidas. Instruções de verificação

Em seguida, finishing-a-development-branch verifica a suíte completa e apresenta as opções de integração. Em uma branch comum com nome definido, o arquivo atual oferece fazer o merge local, enviar a branch ao remoto e criar um pull request, ou manter a branch. Ele aguarda a decisão do usuário; a aprovação em uma revisão não autoriza implicitamente o merge.

Para concluir o exemplo, o usuário escolhe fazer o merge local na branch base confirmada. Claude faz o merge, testa o resultado integrado e só remove a worktree e a branch da funcionalidade depois que os testes passam. Se a escolha fosse criar um pull request, o trabalho ficaria aguardando o processo de merge do repositório. Instruções de conclusão

Quando uma tarefa pequena pede menos processo?

O processo vira burocracia quando insiste em pedir decisões que o próprio pedido já resolveu. Trocar um texto visível por outro já definido não deveria exigir a mesma preparação que mudar a forma de armazenar o estado das tarefas. Essa é uma avaliação do trabalho adicional imposto pelo fluxo, não uma medição de tempo gasto.

O arquivo atual de brainstorming distingue três portes de tarefa:

• Tarefa rápida e clara: o pedido já traz a descrição necessária; basta executá-lo.
• Pequena mudança: combine a descrição na conversa e depois implemente pelo fluxo normal.
• Projeto: aprove uma especificação escrita e então produza um plano completo de implementação de software.

O mesmo arquivo permite que o usuário peça explicitamente para pular as perguntas, encerrando essa etapa obrigatória de brainstorming. Essa dispensa não cancela automaticamente as demais instruções de teste ou verificação. Regras sobre porte da tarefa e dispensa das perguntas

Uma instrução útil é: “Esta é uma pequena mudança. Mantenha a descrição na conversa, use a estrutura de testes existente e não amplie a funcionalidade.” Para uma correção de texto já decidida, informe a redação exata e o escopo. São restrições de tarefa reconhecidas pela hierarquia de instruções do plugin, não comandos secretos para contorná-la.

O limite aqui é o custo adicional do processo: conversas extras, documentos de planejamento, acionamento de agentes e revisões podem ser desproporcionais à incerteza que ainda existe. O código-fonte documenta essas etapas; ele não informa quantos minutos a sua mudança específica vai levar. Se a sessão ignorar repetidamente o escopo, o repositório oferece diagnosing-superpowers para investigar o que aconteceu com base nos registros da conversa. Skill de diagnóstico de sessões

Onde o entusiasmo com Superpowers passa do ponto?

Seguir um fluxo prescrito não comprova que o software está correto nem que o trabalho ficou mais rápido. Um teste que falha pode representar um requisito errado, um plano pode ignorar uma restrição de integração e um agente revisor pode deixar um defeito passar. Avalie as asserções e o diff, não o tom de confiança da mensagem de conclusão.

Trabalhar com subagentes também não significa executar todas as tarefas de implementação ao mesmo tempo. A skill atual proíbe explicitamente subagentes de implementação em paralelo nesse fluxo para evitar conflitos. dispatching-parallel-agents é uma skill separada, voltada a problemas independentes. Regras de acionamento de agentes de implementação

A instalação também não elimina sua responsabilidade pelo escopo da tarefa ou pela integração. O próprio procedimento de conclusão do plugin mantém a decisão de merge com o usuário. Sua principal promessa está no processo: dizer a Claude o que verificar e quais evidências apresentar. A utilidade disso depende do trabalho e de o agente seguir essas instruções.

Para quem vale instalar e o que testar primeiro?

Instale quando o problema recorrente for pular decisões de engenharia. Se você desenvolve sozinho e seu agente passa direto pelos requisitos, comece com uma funcionalidade delimitada que tenha um caso de falha relevante. Observe se a sessão define o comportamento antes da implementação e apresenta evidências depois.

Em uma equipe de desenvolvimento já estabelecida, primeiro alinhe as convenções de planejamento, testes e revisão com as instruções do plugin. Se suas skills atuais já descrevem o processo desejado, um fluxo geral adicional pode duplicá-lo. Se a maior parte do trabalho são edições mínimas e totalmente especificadas, há menos motivo para adotar o método inteiro só para executá-las.

Na segunda-feira, escolha uma mudança bem delimitada e anote seus critérios de aceitação. Use Superpowers, confira as skills escolhidas, revise o diff final e avalie se cada documento ou registro adicional ajudou você a tomar uma decisão. Mantenha o fluxo porque suas verificações foram úteis, não porque ele produziu um plano longo.

Para conhecer ferramentas complementares que resolvem outros problemas, veja os melhores plugins para Claude Code.

Dúvidas sobre Claude Superpowers

Para receber orientações práticas sobre desenvolvimento com IA, assine a newsletter.