O Superpowers pode orientar um usuário do Claude Code em uma alteração substancial em um repositório Git sob seu controle: combinar o projeto, aprovar um plano de tarefas, implementar com testes, revisar cada tarefa e inspecionar a branch concluída. Este guia segue os manuais oficiais do Superpowers 7.0.0 consultados em 20 de outubro de 2026. A BIG CHANGE examinou a documentação; não instalamos o plugin nem executamos esse processo em um projeto.

A grande mudança

  • O que mudou: Um projeto e um plano de implementação aprovados dão aos agentes de programação uma tarefa específica e restrições antes de editarem o repositório.
  • Por que importa: O fluxo documentado combina falhas e aprovações observadas nos testes com pareceres separados de especificação e qualidade do mesmo revisor, seguidos de uma revisão mais ampla de toda a branch.
  • O que observar: O responsável ainda confere o diff completo e resultados recentes de aceitação e decide o destino da branch. Um fluxo de agentes concluído pode manter problemas divulgados.

Antes de começar

Escolha uma alteração autorizada de várias etapas em um repositório que você controla ou pode editar. Ela deve se dividir em tarefas revisáveis e ter comportamento testável. Registre o comportamento solicitado, a área afetada, as exclusões, o comando original de aceitação e o commit inicial. Execute esse comando e as verificações existentes relevantes antes de trabalhar. Se o estado inicial já falhar, identifique a falha agora: um resultado posterior verde ou vermelho precisa de um ponto de partida conhecido.

Você precisa de Git, uma instalação autenticada do Claude Code, permissão para instalar plugins e criar uma branch ou worktree e capacidade suficiente no plano ou API para o Claude Code e seus subagentes. Confira as regras da organização para acesso ao código-fonte e plugins. Examine conteúdo do plugin, permissões efetivas, termos de dados do fornecedor e controles de gastos antes da ativação. A Anthropic alerta que hooks e processos de servidor de plugins podem executar com seus privilégios de usuário fora do isolamento das chamadas de ferramentas; as solicitações comuns de permissão não abrangem todo esse código. Mantenha segredos, dependências, gravações externas, envios e lançamentos dentro da autoridade que você realmente tem. A documentação de segurança de plugins do Claude Code explica esse limite.

O caminho abaixo usa a habilidade do Superpowers subagent-driven-development para uma alteração com várias tarefas. Os manuais também descrevem um caminho direto executing-plans e permitem acordos de projeto mais simples para trabalhos pequenos. Escolha o caminho com o responsável antes de implementar, em vez de presumir que todo projeto precisa da sequência completa.

1. Instale o plugin e verifique a versão ativa

Em uma sessão interativa do Claude Code, digite o comando do catálogo oficial:

Text
/plugin install superpowers@claude-plugins-official

O Claude Code abre um painel de detalhes do plugin antes da instalação. Inspecione o conteúdo e escolha um escopo permitido. O escopo local o ativa para você neste repositório; o de projeto afeta as configurações do repositório dos colaboradores. Leia o resumo da instalação e a aba Errors. Siga as instruções de ativação da sessão ou reinicie, confira a aba Installed e execute claude plugin list em um terminal. Registre Version, Scope e Status exibidos e confirme que as habilidades Superpowers estão disponíveis na sessão ativa. O comando do catálogo não fixa o commit de referência deste guia. Se a versão instalada ou o texto da habilidade diferir de 7.0.0, ajuste o procedimento à versão instalada antes de prosseguir. Uma instalação com falha ou desativada exige parar, e não prova que o fluxo foi carregado. O guia de instalação do Claude Code documenta essas verificações.

2. Aprove o projeto e depois o plano

Informe ao Claude Code a alteração real, os critérios de aceitação, o resultado inicial e as edições proibidas. Use o processo do Superpowers brainstorming para definir intenção, escolhas de projeto e restrições. Nesta alteração de várias etapas, examine o projeto escrito e os resultados da verificação de construção, resolva as questões do responsável e aprove a descrição completa. A aprovação deve descrever o comportamento a construir; não deve ser deduzida do fato de o agente continuar falando. O manual de projeto permite um acordo mais simples ou uma dispensa explícita para trabalhos pequenos, portanto aqui o caminho completo é uma escolha deliberada para uma tarefa substancial.

Em seguida, peça ao processo writing-plans que transforme o projeto em tarefas. Revise limites de arquivos, interfaces, restrições globais, comandos de teste e Review Focus do plano. Cada tarefa deve ser pequena o suficiente para inspeção e seu teste deve medir o comportamento combinado. Aprove o plano e a execução por subagentes antes de alterar código. O manual de planejamento define a passagem de trabalho. Um plano plausível não autoriza adicionar dependências nem alterar arquivos sem relação com a tarefa.

Na execução, using-git-worktrees verifica um espaço de trabalho existente adequado ou prepara um isolado com o consentimento necessário. Registre a branch real, o commit de base e o estado inicial limpo. Use o suporte nativo do Claude Code a worktrees quando disponível. Se houver edições alheias no espaço, resolva a responsabilidade por elas antes de prosseguir. O manual de worktrees descreve as verificações e a criação.

3. Observe cada teste e revisão de tarefa

Com o plano aprovado, use subagent-driven-development para tarefas revisáveis de forma independente. O manual atual atribui um implementador à tarefa e depois envia a implementação e o diff para um único revisor de tarefa. Esse revisor retorna dois pareceres: se a tarefa corresponde à especificação e se a qualidade da implementação é aceitável. São dois pareceres de uma revisão, não dois agentes revisores em sequência. Pequenas tarefas de mesmo formato podem ser agrupadas pelas regras do manual. O fluxo das tarefas e o prompt do revisor estabelecem essa sequência.

Para cada comportamento adequado a testar primeiro, exija um ciclo vermelho-verde observável: adicione o teste de comportamento, execute e veja a falha esperada; faça a menor implementação, execute novamente e veja a aprovação; depois refatore mantendo as verificações verdes. Erro de importação ou estrutura de testes quebrada não é o resultado vermelho esperado. Guarde comando, saída e commit ou diff relevante de cada tarefa. O manual de desenvolvimento orientado a testes descreve exceções que exigem acordo humano; este guia pressupõe uma tarefa apropriada ao caminho habitual de teste primeiro.

Leia os dois pareceres e o diff real. Resolva cada item de “não é possível verificar pelo diff” com o plano e o repositório antes de aceitar a tarefa. Inspecione reparos e suas novas revisões limitadas; uma nova afirmação de sucesso não é resultado recente de teste. O fluxo 7.0.0 limita o ciclo de reparos e pode adiar problemas com decisões escritas. Preserve esses problemas para a revisão posterior. Uma tarefa marcada como concluída não necessariamente tem revisão sem ressalvas.

Quando as tarefas terminarem, inspecione a revisão separada de toda a branch. Ela pode encontrar interações entre tarefas e retomar problemas adiados que um revisor não conseguiu resolver por um único diff. Peça as evidências e decisões por trás de cada questão aberta. Guarde projeto, plano, saídas dos testes, relatórios de revisão e diff completo antes da limpeza do espaço temporário do plugin. Se uma habilidade esperada não foi acionada, confira status, versão ativa e diagnóstico documentado do plugin; a instalação não prova que o fluxo foi imposto.

4. Confira a branch e escolha seu destino

Execute novamente o comando original de aceitação no código final, junto com a suíte completa de testes do projeto. Inspecione saídas recentes, o diff de toda a branch e os problemas pendentes. O manual de verificação do Superpowers exige evidências do estado atual antes de declarar conclusão. Se a suíte falhar, identifique a falha exata e repare ou deixe a branch para revisão; não se chega ao menu documentado de finalização com a suíte falhando.

Em uma branch nomeada, finishing-a-development-branch apresenta mesclagem local, envio e criação de pull request ou manutenção da branch como está. Um HEAD destacado oferece pull request e manter. Descartar só ocorre após pedido explícito do responsável e confirmação digitada; não é uma quarta opção de rotina. O manual de finalização de branch explica essas escolhas. Mostre ao responsável verificações, diff e ressalvas restantes antes da decisão. Mesclagem, envio, exclusão ou lançamento precisa da autoridade correspondente.

A saída útil é uma branch revisável ligada ao requisito original: projeto e plano aprovados, resultados observados de testes, ambos os pareceres de tarefa, revisão da branch completa, diff integral e resultado recente de aceitação. Se instalação, acesso, orçamento ou alguma verificação interromper a execução, preserve os artefatos verificados e indique a última etapa concluída. A documentação descreve um processo; não demonstra que a alteração não executada deste guia levou menos tempo, custou menos ou teve menos defeitos.

Fontes e leituras adicionais

Para reparar uma única verificação de aceitação, consulte o guia da BIG CHANGE para verificar uma checagem de repositório com falha. O processo aqui começa antes, com projeto e plano de uma alteração de várias tarefas.