brainstorming

Visão geral da skill brainstorming

Para que serve a skill brainstorming

A brainstorming skill é um fluxo estruturado de pré-implementação para transformar uma ideia ainda bruta em um design aprovado antes de qualquer código ser escrito. O objetivo principal não é “gerar ideias” de forma abstrata; é reduzir retrabalho ao trazer à tona escopo, premissas, requisitos e decisões de design logo no início.

Quem deve instalar esta skill brainstorming

Esta brainstorming skill é mais indicada para quem costuma pular rápido demais de “devíamos construir X” para a implementação. Ela é especialmente útil para:

• planejamento de funcionalidades
• design de componentes
• mudanças de comportamento
• propostas de ferramentas internas
• brainstorming para Requirements Planning

Se você já tem um processo disciplinado de especificação, esta skill ainda pode funcionar como uma camada inicial mais leve antes desse processo.

O que diferencia esta skill brainstorming de um prompt comum

O grande diferencial é a regra rígida em SKILL.md: o agente não deve implementar, montar estrutura nem escrever código até apresentar um design e receber aprovação. Parece algo simples, mas isso muda de forma concreta o comportamento em comparação com prompts comuns de “me ajude a construir isso”, em que os assistentes muitas vezes pulam direto para a solução.

O que os usuários realmente querem saber antes de instalar

Antes de instalar, a maioria dos usuários quer responder rapidamente a três perguntas:

1. Isso vai me deixar mais lento?
2. Vai fazer perguntas úteis em vez de perguntas genéricas?
3. Pode ajudar em discussões de design visual?

A resposta é: ela adiciona sobrecarga de processo de propósito, mas essa sobrecarga é pequena quando a ideia também é pequena. A skill argumenta explicitamente que até trabalhos “simples” precisam de uma passada curta de design, porque é justamente aí que premissas ocultas viram erros caros.

Como usar a skill brainstorming

Instalação e configuração da brainstorming skill

Para adicionar a skill a partir do repositório, use:
npx skills add https://github.com/obra/superpowers --skill brainstorming

Depois da instalação, abra estes arquivos primeiro:

• skills/brainstorming/SKILL.md
• skills/brainstorming/visual-companion.md
• skills/brainstorming/spec-document-reviewer-prompt.md

Se você espera fazer exploração visual, também vale inspecionar:

• skills/brainstorming/scripts/start-server.sh
• skills/brainstorming/scripts/frame-template.html

O fluxo principal que a skill brainstorming espera

O padrão de uso de brainstorming é opinativo:

1. explorar o contexto do projeto
2. opcionalmente oferecer o companion visual
3. fazer perguntas de esclarecimento uma por vez
4. sintetizar o design
5. obter aprovação explícita
6. só então avançar para planejamento ou implementação

Se o seu agente salta da ideia para o código, ele não está seguindo esta skill de verdade.

Que tipo de input fornecer para um uso melhor da brainstorming skill

A skill funciona melhor quando você fornece mais do que apenas um título de funcionalidade. Um bom ponto de partida normalmente inclui:

• o problema a resolver
• quem é o usuário
• o contexto atual do sistema ou do repositório
• restrições
• como é o “pronto”
• não objetivos já conhecidos

Um input fraco:

Add notifications.

Um input mais forte:

Add in-app notifications for failed background imports. Users are operations staff, not end customers. We already have email alerts, but they are too slow for live triage. Keep scope to the admin dashboard only. Do not add mobile push or user preference management in v1.

Essa segunda versão dá estrutura suficiente para a brainstorming skill fazer perguntas de acompanhamento mais precisas.

Como transformar uma ideia bruta em um primeiro prompt forte para brainstorming

Um template prático de prompt para brainstorming:

Use the brainstorming skill for Requirements Planning.
Context: [project/repo/product]
Problem: [what is happening now]
Target user: [who is affected]
Constraints: [timeline, stack, compliance, UX, compatibility]
Non-goals: [what not to solve]
Please ask clarifying questions one at a time, then present a proposed design for approval before any implementation.

Isso se alinha ao fluxo pretendido pela skill e reduz a chance de cair em perguntas genéricas.

Como as perguntas de esclarecimento devem funcionar

Há um comportamento sutil, mas importante: a skill espera perguntas uma por vez, não um questionário gigante de descoberta. Isso importa porque as respostas muitas vezes mudam a próxima pergunta. Se o seu agente despeja 15 perguntas de uma vez, você perde o refinamento interativo que este guia de brainstorming foi feito para gerar.

Quando usar o companion visual

O repositório inclui um companion visual baseado em navegador. Use quando o usuário entender melhor as opções ao vê-las:

• wireframes
• comparações de layout
• fluxos de UI
• diagramas de arquitetura
• visuais de estado ou relacionamento

Não use só porque o tema menciona UI. Uma pergunta conceitual como “isso deveria ser um wizard ou um modal?” pode ficar em texto. Já uma pergunta como “qual destes dois layouts de wizard está mais claro?” combina fortemente com o caminho visual.

Como o companion visual é servido na prática

O helper visual não é apenas documentação; há scripts para rodar uma sessão local:

• scripts/start-server.sh
• scripts/stop-server.sh
• scripts/server.cjs
• scripts/helper.js

start-server.sh inicia um servidor local em uma porta alta aleatória e pode armazenar arquivos de sessão em /tmp ou dentro de um diretório do projeto, como .superpowers/brainstorm/. Isso é útil se você quiser que os mockups persistam entre sessões.

Observações práticas de ambiente antes de depender dos visuais

O fluxo visual pressupõe um ambiente acessível via navegador. Se você estiver em um container remoto, VM ou fluxo via SSH, preste atenção em:

• --host
• --url-host
• persistência do diretório de sessão

Para uso estritamente local, os padrões são simples. Em ambientes compartilhados ou remotos, planeje os detalhes de rede antes de estruturar o fluxo em torno de feedback via navegador.

Melhor sequência de leitura dos arquivos para adoção rápida

Se você quer o caminho mais curto até um uso realmente bom, leia nesta ordem:

1. SKILL.md para entender o contrato de comportamento
2. visual-companion.md para saber quando o suporte em navegador ajuda
3. spec-document-reviewer-prompt.md para entender o que é “bom o suficiente para implementar”
4. scripts/start-server.sh se você precisar do caminho visual

Assim você absorve primeiro a lógica de decisão e depois as ferramentas opcionais.

Como deve ser uma boa saída da skill brainstorming

Uma sessão de brainstorming bem-sucedida deve terminar com um design concreto o bastante para revisão, incluindo:

• objetivo e usuário
• limites de escopo
• decisões principais
• riscos ou premissas em aberto
• especificidade suficiente para planejar a implementação

Se a saída for apenas uma lista solta de ideias, a sessão parou cedo demais.

Como usar brainstorming para Requirements Planning

Para brainstorming para Requirements Planning, use a skill como etapa pré-spec:

1. esclarecer o problema e as restrições
2. rascunhar o formato do design ou dos requisitos
3. obter aprovação
4. escrever a spec
5. rodar o template de prompt do revisor de spec, se necessário

Esse é um dos usos mais fortes da skill, porque ela captura deriva de escopo e ambiguidades antes de o planejamento ficar engessado.

FAQ da skill brainstorming

A brainstorming skill serve só para projetos grandes?

Não. A skill rejeita explicitamente a ideia de que trabalho “pequeno” pode pular a etapa de design. Em uma mudança minúscula, o design esperado pode ser curto, mas a etapa de design continua importando. Muitas vezes, o valor é ainda maior em mudanças supostamente simples, nas quais premissas passam sem teste.

Ela é melhor do que prompts comuns de brainstorming?

Na maioria dos casos, sim, se o seu objetivo real é chegar a uma clareza pronta para execução, e não apenas volume de ideias. Um prompt comum de brainstorming pode gerar várias opções. Esta brainstorming skill é melhor quando você precisa de pensamento convergente: entender o contexto, afunilar escolhas e produzir um design aprovado.

A brainstorming skill é amigável para iniciantes?

Sim, especialmente para quem trabalha sozinho e ainda não criou o hábito de planejar. A estrutura compensa um erro comum de iniciantes: implementar a primeira ideia plausível sem esclarecer antes requisitos ou tradeoffs.

Em que casos brainstorming não é uma boa escolha?

Vale pular ou encurtar quando:

• a tarefa é puramente mecânica e já está totalmente especificada
• você não está tomando uma decisão de design ou comportamento
• o usuário já aprovou uma spec detalhada e só precisa de execução

Ainda assim, confirme se a regra rígida não conflita com o seu fluxo. Esta skill é intencionalmente estrita.

Esta skill gera código?

Não, e isso é deliberado. A brainstorming skill deve parar antes da implementação até que haja aprovação. Se você quer geração de código, use esta skill primeiro e depois passe para uma skill de planejamento ou implementação após a aprovação.

Preciso do companion visual para extrair valor?

Não. O caminho via navegador é opcional. O uso de brainstorming só em texto ainda entrega a maior parte do valor em discussões sobre requisitos, escopo e tradeoffs técnicos. As ferramentas visuais importam mais quando a própria decisão é visual.

Como melhorar a skill brainstorming

Dê à brainstorming skill um contexto de projeto mais rico

A forma mais rápida de melhorar os resultados é ancorar a conversa na realidade:

• arquivos ou pastas relevantes
• comportamento existente
• mudanças recentes
• restrições técnicas conhecidas
• usuários afetados

A própria skill orienta o agente a explorar primeiro o contexto do projeto. Ajude indicando onde esse contexto vive.

Declare restrições e não objetivos logo no começo

Muitas saídas fracas de brainstorming vêm de limites mal definidos. Diga à skill o que ela precisa preservar ou evitar:

• compatibilidade retroativa
• limites de performance
• requisitos de compliance ou segurança
• limites de prazo ou equipe
• funcionalidades explicitamente fora de escopo

Isso gera designs mais estreitos e mais úteis para tomada de decisão.

Peça um design, não apenas ideias

Se você quer uma saída pronta para implementação, deixe isso claro. Peça que a brainstorming skill termine com:

• um design proposto
• premissas
• perguntas não resolvidas
• checkpoint explícito de aprovação

Isso empurra a sessão para longe de ideação sem fim e na direção de um artefato utilizável.

Use prompts mais fortes para brainstorming visual

Para trabalho visual, não diga apenas “show mockups”. Especifique o que o visual precisa comparar:

Show two dashboard layout options for failed import alerts: one optimized for fast triage, one optimized for detail review. Keep the existing navigation shell. Highlight which option better supports keyboard-heavy operators.

Esse tipo de prompt ajuda o companion visual a produzir algo orientado à decisão, e não telas meramente decorativas.

Fique atento ao principal modo de falha: partir cedo demais para a solução

O maior modo de falha é mergulhar em detalhes de implementação antes de o problema estar realmente entendido. Se isso acontecer, redirecione a sessão:

Pause implementation thinking. What assumptions are we making about the user workflow, edge cases, and scope boundaries?

Isso mantém o guia de brainstorming alinhado ao seu propósito central.

Melhore a primeira saída com uma rodada de revisão

Depois do design inicial, peça uma revisão focada em vez de recomeçar do zero:

• o que está ambíguo?
• o que está elaborado demais?
• o que atrapalharia o planejamento da implementação?
• o que falta para aprovação?

O spec-document-reviewer-prompt.md do repositório é útil aqui porque calibra a revisão em torno de bloqueios reais de planejamento, não de edições cosméticas.

Mantenha o artefato de brainstorming pequeno, mas completo para decisão

Um erro comum é inflar o design com detalhes desnecessários. Brainstorming melhor não significa brainstorming mais longo. Para trabalhos simples, alguns parágrafos enxutos cobrindo objetivo, escopo, restrições, abordagem e aprovação podem bastar. O padrão não é o tamanho do documento; é se a próxima etapa consegue avançar com menos achismo.

Combine brainstorming com uma etapa de revisão de spec

Se você for adotar esta skill a sério, combine-a com uma revisão posterior da spec ou do design produzido. O template de revisão incluído verifica:

• placeholders
• contradições
• requisitos ambíguos
• escopo amplo demais
• complexidade não solicitada

Isso torna a brainstorming skill mais útil em um fluxo real de entrega, e não apenas dentro do chat.