O Superpowers pode orientar um utilizador do Claude Code numa alteração substancial de um repositório Git sob o seu controlo: acordar o desenho, aprovar um plano de tarefas, implementar com testes, rever cada tarefa e inspecionar a branch final. Este guia segue os manuais oficiais do Superpowers 7.0.0 consultados em 20 de outubro de 2026. A BIG CHANGE analisou a documentação; não instalámos o plugin nem executámos o processo num projeto.

A grande mudança

  • O que mudou: Um desenho e um plano de implementação aprovados dão aos agentes de programação uma tarefa concreta e restrições antes de editarem o repositório.
  • Porque é importante: O fluxo documentado associa falhas e aprovações observadas nos testes a pareceres separados sobre especificação e qualidade do mesmo revisor, seguindo-se uma revisão mais abrangente de toda a branch.
  • O que observar: O responsável continua a verificar o diff completo e resultados recentes de aceitação e decide o destino da branch. Um fluxo de agentes concluído pode conservar problemas divulgados.

Antes de começar

Escolha uma alteração autorizada de vários passos num repositório que controla ou pode editar. Deve dividir-se em tarefas passíveis de revisão e ter comportamento testável. Registe o comportamento pedido, 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 começar. Se o estado inicial já falhar, identifique essa falha agora: um resultado posterior verde ou vermelho exige um ponto de partida conhecido.

Precisa de Git, de uma instalação autenticada do Claude Code, de autorização para instalar plugins e criar uma branch ou worktree e de capacidade suficiente no plano ou API para o Claude Code e os seus subagentes. Verifique as regras da organização relativas a código-fonte e plugins. Analise o conteúdo do plugin, permissões efetivas, condições de dados do fornecedor e controlos de despesa antes de o ativar. A Anthropic avisa que hooks e processos de servidor dos plugins podem executar com os seus privilégios de utilizador fora do isolamento das chamadas de ferramentas; os pedidos normais de autorização não abrangem todo esse código. Mantenha segredos, dependências, escritas externas, envios e lançamentos dentro da autoridade que realmente tem. A documentação de segurança de plugins do Claude Code explica este limite.

O percurso abaixo utiliza a competência Superpowers subagent-driven-development para uma alteração com várias tarefas. Os manuais também descrevem um percurso direto executing-plans e permitem acordos de desenho mais simples para pequenos trabalhos. Escolha o percurso com o responsável antes de implementar, em vez de assumir que todos os projetos têm de seguir a sequência completa.

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

Numa sessão interativa do Claude Code, introduza 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 âmbito autorizado. O âmbito local ativa-o para si neste repositório; o de projeto afeta as definições do repositório dos colaboradores. Leia o resumo da instalação e o separador Errors. Siga as instruções de ativação da sessão ou reinicie, verifique o separador Installed e execute claude plugin list num terminal. Registe os valores apresentados de Version, Scope e Status e confirme que as competências Superpowers estão disponíveis na sessão ativa. O comando do catálogo não fixa o commit de referência usado neste guia. Se a versão ou o texto das competências instaladas diferir de 7.0.0, reconcilie o procedimento com essa versão antes de continuar. Uma instalação falhada ou desativada exige parar; não prova que o fluxo ficou carregado. O guia de instalação do Claude Code documenta estas verificações.

2. Aprove o desenho e depois o plano

Indique ao Claude Code a alteração real, os critérios de aceitação, o resultado inicial e as edições proibidas. Utilize o processo Superpowers brainstorming para definir intenção, escolhas de desenho e restrições. Para esta alteração de vários passos, examine o desenho escrito e os resultados da verificação de construção, resolva as questões que cabem ao responsável e aprove a descrição completa. A aprovação deve descrever o comportamento a construir; não deve ser inferida de o agente continuar a falar. O manual de desenho permite um acordo mais leve ou uma dispensa explícita para pequenos trabalhos, pelo que aqui o percurso completo é uma escolha deliberada para uma tarefa substancial.

A seguir, peça ao processo writing-plans que transforme o desenho em tarefas. Reveja limites de ficheiros, interfaces, restrições globais, comandos de teste e Review Focus do plano. Cada tarefa deve ser suficientemente pequena para ser inspecionada, e o teste deve medir o comportamento acordado. Aprove o plano e a execução com subagentes antes de alterar código. O manual de planeamento define a passagem de trabalho. Um plano plausível não autoriza novas dependências nem alterações em ficheiros sem relação com a tarefa.

Na execução, using-git-worktrees verifica se existe um espaço de trabalho adequado ou prepara um isolado com o consentimento necessário. Registe a branch real, o commit de base e o estado inicial limpo. Use o suporte nativo a worktrees do Claude Code quando disponível. Se o espaço contiver edições alheias, resolva a responsabilidade por elas antes de avançar. 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 que possam ser revistas separadamente. O manual atual atribui um implementador a uma tarefa e depois entrega a implementação e o diff a um único revisor de tarefa. Este devolve dois pareceres: se a tarefa corresponde à especificação e se a qualidade da implementação é aceitável. São dois pareceres da mesma revisão, não dois agentes revisores sucessivos. Pequenas tarefas do mesmo formato podem ser agrupadas segundo as regras do manual. O fluxo das tarefas e o prompt do revisor estabelecem esta sequência.

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

Leia os dois pareceres e o diff real. Resolva qualquer item de “não é possível verificar pelo diff” recorrendo ao plano e ao repositório antes de aceitar a tarefa. Inspecione reparações e a respetiva nova revisão limitada; uma nova afirmação de sucesso não é um resultado de teste recente. O fluxo 7.0.0 limita o ciclo de reparações e pode adiar problemas com decisões escritas. Conserve-os para a revisão posterior. Uma tarefa marcada como concluída não implica uma revisão sem reservas.

Quando as tarefas terminarem, inspecione a revisão separada de toda a branch. Pode identificar interações entre tarefas e retomar problemas adiados que um revisor não podia resolver a partir de um único diff. Peça as provas e decisões de cada questão em aberto. Guarde desenho, 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 competência esperada não for ativada, verifique o estado e a versão do plugin ativo e o diagnóstico documentado; não presuma que a instalação impôs o fluxo.

4. Verifique a branch e decida o seu destino

Execute novamente o comando original de aceitação sobre o código final, juntamente com toda a bateria de testes do projeto. Inspecione novas saídas, o diff completo da branch e todos os problemas pendentes. O manual de verificação do Superpowers exige provas do estado atual antes de declarar conclusão. Se os testes falharem, identifique a falha concreta e repare-a ou deixe a branch para revisão; não se chega ao menu documentado de finalização com testes a falhar.

Numa branch com nome, finishing-a-development-branch apresenta fusão local, envio e criação de pull request, ou manutenção da branch tal como está. Um HEAD desligado tem as opções pull request e manter. Descartar só se trata após pedido explícito do responsável e confirmação digitada; não é uma quarta opção habitual. O manual de finalização de branches explica estas escolhas. Mostre ao responsável verificações, diff e reservas restantes antes da decisão. Fusão, envio, eliminação ou lançamento exigem a autoridade adequada à ação.

O resultado útil é uma branch passível de revisão ligada ao requisito original: desenho e plano aprovados, resultados de testes observados, 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 uma verificação interromperem a execução, mantenha os artefactos 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 foi mais rápida, barata 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 um controlo de repositório que falha. O processo aqui começa antes, com desenho e plano de uma alteração com várias tarefas.