Como fazer o Claude Code perguntar antes de codar com o Superpowers

Tem uma cena que todo vibe coder já viveu: você descreve a feature em três linhas, aperta enter, e trinta segundos depois o agente já criou quatro arquivos, mexeu na estrutura de pastas e resolveu um problema que não era o seu 😅

O Superpowers existe justamente pra inverter essa ordem. É um framework de skills e metodologia de desenvolvimento criado por Jesse Vincent (o obra no GitHub) junto com o pessoal da Prime Radiant, open source com licença MIT, e a ideia central é chata de propósito: primeiro perguntas, depois design aprovado por você, só então código

Neste post você vai sair com o fluxo inteiro montado: instalar o plugin, acionar a etapa de brainstorming, responder as perguntas do agente, validar o design em partes, achar o documento de especificação gerado e transformar ele num plano quebrado em tarefas de poucos minutos, cada uma com caminho de arquivo e passo de verificação

Bora?

O que você precisa antes de começar:

A lista é curta, e é bom conferir antes pra não travar no meio

• Claude Code instalado e uma sessão aberta no diretório do projeto, porque a instalação do plugin acontece dentro da sessão, não no terminal cru
• O projeto sob git, e isso não é firula: o documento de design entra no repositório, cada tarefa do plano já diz o que commitar, e a etapa de execução recomenda um workspace isolado via superpowers:using-git-worktrees
• A decisão de qual caminho de instalação usar: o marketplace oficial de plugins do Claude Code da Anthropic (o Superpowers foi aceito lá em 15 de janeiro de 2026) ou o marketplace próprio do autor

Um ponto de expectativa antes de seguir: o portão de aprovação não transforma o agente em outra coisa, ele só muda ONDE você entra na conversa. Continua valendo saber o que o Claude não faz bem antes de delegar decisão de arquitetura pra ele

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

Passo a passo: do rascunho ao código com o Superpowers

1. Instale o plugin pelo marketplace oficial. Dentro da sessão do Claude Code, roda o comando de barra:

/plugin install superpowers@claude-plugins-official

Depois sai e reabre o Claude Code

O erro comum deste passo: não reiniciar. O comando roda, aparece que instalou, você sai testando na mesma sessão e acha que o plugin não funciona

2. Se preferir o marketplace do autor, use o caminho alternativo. São dois comandos, na ordem:

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

O erro comum deste passo: inverter a ordem. Sem adicionar o marketplace antes, o install não tem de onde puxar

3. Acione o brainstorming descrevendo a intenção em linguagem natural. Não precisa de comando de barra, é só falar o que você quer fazer, tipo "quero um sistema de tags nos posts, vamos pensar juntos antes de escrever código". O sistema nativo de skills seleciona a skill adequada

O erro comum deste passo: sair caçando /superpowers:brainstorm na lista de comandos. Os comandos de barra com namespace do plugin (/superpowers:brainstorm, /superpowers:write-plan, /superpowers:execute-plan) aparecem como deprecados, os nomes que valem hoje são as skills: brainstorming, writing-plans e executing-plans

4. Deixe o agente explorar o contexto antes de responder qualquer coisa. A skill começa varrendo arquivos, docs e commits recentes. Parece tempo perdido, não é: é ele descobrindo como o SEU projeto faz as coisas antes de propor algo genérico

O erro comum deste passo: atropelar com "não precisa olhar nada, só faz". Aí você volta pro agente chutando padrão

5. Responda as perguntas de esclarecimento uma de cada vez. O fluxo é assim de propósito: uma pergunta, sua resposta, próxima pergunta

O erro comum deste passo: despejar um textão respondendo tudo de uma vez. Quando você faz isso, metade das respostas fica vaga e você volta ao rascunho confuso do começo, que era exatamente o problema que a skill tenta resolver

6. Escolha entre as abordagens propostas. Nesse ponto o agente coloca de 2 a 3 abordagens na mesa, com os trade-offs de cada uma e uma recomendação dele

Aqui é onde tu decide de verdade: a recomendação é opinião do agente, não sentença. Se a abordagem recomendada te obriga a manter uma camada que você odeia, fala isso

7. Valide o design seção por seção. O design é apresentado em seções, dimensionadas pela complexidade, e ele pede sua aprovação depois de CADA seção

O erro comum deste passo: dar um "ok, tá tudo bom" geral só pra andar rápido. Você acabou de jogar no lixo o único ponto de controle do fluxo. Aprovação incremental existe pra você pegar o erro na seção 2, não na hora de rodar o código

8. Confira a auto-revisão do documento. Antes de entregar o spec, a skill roda checagens no que escreveu: varredura de placeholders (TBD, TODO, seções incompletas), consistência interna entre as seções, escopo adequado a um único plano de implementação e ambiguidade, ou seja, requisito que dá pra ler de mais de uma forma

Vale ler a saída dessa revisão com atenção. "Ambiguidade" aqui costuma ser o lugar exato onde você e o agente entenderam coisas diferentes

9. Localize o spec e commite. O documento de design é salvo em caminho e nome definidos:

docs/superpowers/specs/AAAA-MM-DD-<topico>-design.md

O erro comum deste passo: tratar esse arquivo como rascunho descartável. Ele é o contrato do que vai ser feito, e é o que o próximo passo lê

10. Peça o plano de implementação com a skill writing-plans. Ela pega o design aprovado e escreve o plano como se quem fosse executar não tivesse NENHUM contexto do código e nenhum critério próprio pra decidir nada

O resultado é o que interessa pra quem já viu agente se perder no meio da tarefa: passos quebrados em tarefas de 2 a 5 minutos, cada uma dizendo quais arquivos tocar, o código exato, como rodar os testes, qual saída esperar e o que commitar. O arquivo sai assim:

docs/superpowers/plans/AAAA-MM-DD-<nome-da-feature>.md

Com os passos em formato de checkbox de markdown (- [ ]). Se você tem preferência de onde guardar plano no seu projeto, sua preferência tem prioridade sobre esse padrão

Antes de seguir, abre esse arquivo e lê. É markdown puro, dá pra ler em dois minutos, e é você quem diz se ele bate com o design que você aprovou. Nada te obriga a mandar executar enquanto tu não estiver satisfeito com o plano

11. Execute com a skill executing-plans. Ela carrega o plano, revisa criticamente, cria o TodoWrite se não tiver ressalva, marca cada tarefa como in_progress e completed, roda as verificações indicadas e obedece condições de parada: bloqueio, dependência ausente, falha repetida de verificação

O erro comum deste passo: rodar tudo direto na branch principal. A própria skill orienta trabalhar em workspace isolado via superpowers:using-git-worktrees. E se você tem subagentes disponíveis, a recomendação dela é usar superpowers:subagent-driven-development no lugar

Onde esse fluxo compensa (e onde é peso morto)

Sejamos honestos: tanta etapa de aprovação não é de graça. O ganho depende MUITO do tipo de tarefa

O padrão que aparece na tabela é um só: o fluxo paga quando existe DECISÃO envolvida. Quando não existe decisão, só execução óbvia, você tá pagando pedágio numa estrada vazia

E isso não é exclusividade de quem escreve código o dia inteiro. O mesmo raciocínio de fechar o desenho antes de sair executando aparece em quem está aprendendo n8n sem saber programar: decidir o fluxo primeiro custa uma conversa, refazer depois custa a tarde inteira

Conclusão

O valor aqui não está no plugin em si, está em separar decisão de execução. O Superpowers só torna essa separação obrigatória: perguntas antes, design aprovado seção por seção, plano com verificação, e só então o código

Próximo passo concreto pra hoje: instala, escolhe uma feature pequena e REAL do seu projeto, roda o brainstorming e leia o documento de design gerado antes de deixar qualquer linha de código ser escrita. É nessa leitura que você descobre se vocês dois estavam falando da mesma coisa

Sobre o projeto estar vivo: a versão mais recente publicada nas releases é a v6.2.0, de 23/07/2026, com melhorias no Subagent-Driven Development, e a entrada no marketplace oficial de plugins do Claude Code foi em 15 de janeiro de 2026. O repositório acumula algo em torno de 271,5 mil stars pela leitura do histórico em agosto de 2026. Movimento tem, e ele corta nas duas direções: uma release recente removeu o suporte ao Gemini CLI depois que o Google encerrou o Gemini CLI em 18/06/2026, então acompanhar as notas de versão faz parte do combo

Até o próximo post! 😀