Aprenda a extrair uma especificação real de uma conversa vaga e validá-la antes de escrever uma linha de código.
A skill de brainstorming do Superpowers muda fundamentalmente o modo como o agente responde a pedidos vagos. Em vez de implementar o que parece razoável, o agente entra em modo socrático: faz perguntas direcionadas para revelar o que você realmente quer antes de escrever uma linha.
Uma sessão de brainstorming de 20 minutos revela requisitos que, se descobertos durante a implementação, custam 2-4 horas de reescrita. O ROI é sempre positivo.
O processo de extrair uma spec começa com a ideia mais vaga possível e a refina através de perguntas até chegar a um documento estruturado. O agente não inventa requisitos — ele os descobre através de diálogo. Ao final, a spec reflete o que você realmente quer, não o que o agente imaginou.
Entrada (ideia vaga)
"Quero um sistema para gerenciar tarefas da minha equipe"
Saída (spec extraída)
Sistema Kanban para 5-10 usuários, persistência em PostgreSQL, autenticação por email, sem mobile por ora, drag-and-drop em cards
Após extrair a spec, o agente não a apresenta inteira de uma vez esperando aprovação global. Em vez disso, apresenta seção por seção e aguarda confirmação explícita antes de continuar. Isso garante que você realmente leu e compreendeu cada parte — não apenas clicou "aprovado" em um texto longo.
"Criar um Kanban board para gerenciamento de tarefas de equipes pequenas (5-10 pessoas). Confirma?"
"Next.js + PostgreSQL + Prisma. Auth via NextAuth com provider de email. Confirma?"
"Criar/mover/deletar cards, drag-and-drop entre colunas, persistência imediata. Confirma?"
Por que seção por seção?
Spec documents completos têm 500-1000 palavras. Aprovação em bloco é ilusória. Seção por seção força leitura real e permite correções cirúrgicas.
Durante o brainstorming, o agente pode iniciar um servidor local que renderiza a spec em tempo real numa interface HTML limpa. Em vez de revisar a spec no chat — onde o contexto se mistura com a conversa — você revisa num browser dedicado que se atualiza conforme o agente escreve.
localhost:3000 por padrãoCom o servidor visual, você pode ter o chat à esquerda e a spec renderizada à direita. Cada aprovação de seção no chat se reflete imediatamente na visualização. A revisão fica muito mais natural e rápida.
Uma spec bem escrita tem seções obrigatórias que cobrem todas as dimensões da feature: o que ela faz, como saberemos que está pronta, o que está fora do escopo e o que ainda está em aberto. Cada seção serve como critério de revisão em fases posteriores.
Atenção: spec incompleta é quase tão ruim quanto sem spec
Se "fora de escopo" estiver em branco, o agente vai adicionar features que parecem razoáveis. Se "em aberto" estiver vazio, decisões serão tomadas sem você. Preencha todas as seções.
Este exercício une todos os tópicos anteriores numa sessão real de brainstorming. A meta é partir de uma ideia propositalmente vaga e chegar a uma spec que poderia ir direto para o módulo de planejamento sem nenhuma ambiguidade.
Critério de conclusão
A spec está pronta quando você consegue responder "sim" a: "Qualquer desenvolvedor poderia implementar isso sem fazer uma única pergunta adicional?"