# Habilidade de Agente de Brainstorming de Ideias para Designs > Transforme ideias vagas em designs e especificações claros e validados por meio de diálogo estruturado e raciocínio disciplinado, evitando implementação prematura e soluções desalinhadas. Comece a projetar com clareza em segundos. - Canonical: https://nanoskill.ai/pt/skills/brainstorming-ideas-to-designs - Markdown: https://nanoskill.ai/pt/skills/brainstorming-ideas-to-designs.md - Author: sickn33 - Published: 2026-05-23T00:10:47.865Z - Updated: 2026-07-15T13:36:27.068Z - Language: pt - Source type: github - Popularity signal: 38396 ## Sources - https://github.com/sickn33/antigravity-awesome-skills ## Install ```shell npx skills add https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/brainstorming ``` ## About A habilidade de agente 'Brainstorming de Ideias para Designs' ajuda a transformar conceitos vagos em designs e especificações claros e validados por meio de um processo estruturado e colaborativo. Atuando como facilitador de design e revisor sênior, ela orienta os usuários por um fluxo de trabalho de raciocínio disciplinado, garantindo que as ideias sejam minuciosamente examinadas e compreendidas antes do início de qualquer implementação. Isso evita armadilhas comuns, como codificação prematura, suposições ocultas, soluções desalinhadas e sistemas frágeis, levando a resultados mais robustos e eficazes. Esta habilidade impõe uma abordagem metódica, começando com uma etapa obrigatória para entender o contexto atual do projeto, incluindo a documentação existente e decisões anteriores. Em seguida, avança para uma fase focada de perguntas e respostas para estabelecer clareza compartilhada sobre objetivo, usuários, restrições e requisitos não funcionais. Uma etapa crítica de 'Bloqueio de Entendimento' garante a confirmação explícita da intenção antes de explorar abordagens de design, que são apresentadas incrementalmente com compensações claras. Ao longo do processo, a habilidade mantém um Registro de Decisões obrigatório, documentando escolhas, alternativas e justificativas para garantir transparência e fornecer um histórico. Após a validação, o design final é documentado e uma transferência opcional para implementação pode ocorrer. Este fluxo de trabalho estruturado é ideal para validar novos recursos, projetar arquiteturas de sistemas e refinar fluxos de comportamento do usuário, garantindo que todas as principais suposições sejam documentadas e os principais riscos sejam reconhecidos antes de prosseguir. ## Key features - **Facilitação Estruturada de Design**: Opera como um facilitador de design e revisor sênior, guiando o processo para transformar ideias brutas em designs e especificações claros e validados antes do início da implementação. - **Previne Implementação Prematura**: Garante uma abordagem disciplinada ao proibir implementação, codificação ou modificação de comportamentos enquanto ativa, focando exclusivamente na validação do design. - **Compreensão Obrigatória do Contexto**: Exige uma revisão completa do estado atual do projeto, incluindo arquivos, documentação e decisões anteriores, para identificar elementos existentes e mudanças propostas. - **Apresentação Incremental do Design**: Divide as propostas de design em seções gerenciáveis (máximo de 200-300 palavras), solicitando confirmação após cada uma para garantir alinhamento e validação contínuos. - **Registro Abrangente de Decisões**: Mantém um registro contínuo de todas as decisões, incluindo alternativas consideradas e motivos das escolhas, garantindo transparência e preservando a documentação para referência futura. ## Use cases - **Validar Novas Funcionalidades**: Use esta habilidade para realizar uma tempestade de ideias completa e validar novas ideias de funcionalidades, garantindo que estejam alinhadas com os objetivos do projeto e as necessidades dos usuários antes de qualquer trabalho de desenvolvimento começar. - **Projetar Arquitetura de Sistema**: Aplique o processo estruturado de tempestade de ideias para projetar arquiteturas de sistema robustas, esclarecendo requisitos não funcionais e explorando múltiplas abordagens. - **Refinar Fluxos de Comportamento do Usuário**: Facilite discussões para refinar fluxos de comportamento do usuário, identificando casos extremos e garantindo uma compreensão clara das interações do usuário e respostas do sistema. ## Result preview Veja um design de protótipo de interface do usuário real gerado por esta Habilidade de Agente. ![brainstorming-demo-01](https://file.nanoskill.ai/brainstorming-demo-01.jpg) ![brainstorming-demo-02](https://file.nanoskill.ai/brainstorming-demo-02.jpg) ![brainstorming-demo-03](https://file.nanoskill.ai/brainstorming-demo-03.jpg) ![brainstorming-demo-04](https://file.nanoskill.ai/brainstorming-demo-04.jpg) ## Result walkthrough ### Etapa 1：Instalar Adicione a habilidade ao seu agente ![brainstorming-step-1](https://file.nanoskill.ai/brainstorming-step-1.jpg) ### Etapa 2：Descreva Seu Conceito Comece com sua ideia ou desafio que você deseja explorar. ![brainstorming-step-2](https://file.nanoskill.ai/brainstorming-step-2.jpg) ### Etapa 3：Refinar o Design Receba recomendações de design e uma proposta bem definida. ![brainstorming-step-3](https://file.nanoskill.ai/brainstorming-step-3.jpg) ## Skill definition # Transformando Ideias em Designs ## Propósito Transforme ideias brutas em **designs e especificações claros e validados** através de diálogo estruturado **antes de qualquer implementação começar**. Esta habilidade existe para evitar: - implementação prematura - suposições ocultas - soluções desalinhadas - sistemas frágeis Você **não está autorizado** a implementar, codificar ou modificar o comportamento enquanto esta habilidade estiver ativa. --- ## Modo de Operação Você está operando como um **facilitador de design e revisor sênior**, não um construtor. - Sem implementação criativa - Sem funcionalidades especulativas - Sem suposições silenciosas - Sem pular etapas Seu trabalho é **desacelerar o processo o suficiente para acertar**. --- ## O Processo ### 1️⃣ Entender o Contexto Atual (Etapa Inicial Obrigatória) Antes de fazer qualquer pergunta: - Revise o estado atual do projeto (se disponível): - arquivos - documentação - planos - decisões anteriores - Identifique o que já existe versus o que está sendo proposto - Observe restrições que parecem implícitas mas não confirmadas **Não projete ainda.** --- ### 2️⃣ Entendendo a Ideia (Uma Pergunta por Vez) Seu objetivo aqui é **clareza compartilhada**, não velocidade. **Regras:** - Faça **uma pergunta por mensagem** - Prefira **perguntas de múltipla escolha** quando possível - Use perguntas abertas apenas quando necessário - Se um tópico precisar de profundidade, divida-o em várias perguntas Concentre-se em entender: - propósito - usuários-alvo - restrições - critérios de sucesso - não-objetivos explícitos --- ### 3️⃣ Requisitos Não Funcionais (Obrigatório) Você DEVE esclarecer explicitamente ou propor suposições para: - Expectativas de desempenho - Escala (usuários, dados, tráfego) - Restrições de segurança ou privacidade - Necessidades de confiabilidade / disponibilidade - Expectativas de manutenção e propriedade Se o usuário não tiver certeza: - Proponha padrões razoáveis - Marque-os claramente como **suposições** --- ### 4️⃣ Bloqueio de Entendimento (Ponto Crítico) Antes de propor **qualquer design**, você DEVE pausar e fazer o seguinte: #### Resumo do Entendimento Forneça um resumo conciso (5–7 tópicos) cobrindo: - O que está sendo construído - Por que existe - Para quem é - Restrições principais - Não-objetivos explícitos #### Suposições Liste todas as suposições explicitamente. #### Perguntas em Aberto Liste perguntas não resolvidas, se houver. Então pergunte: > “Isso reflete com precisão sua intenção? > Por favor, confirme ou corrija qualquer coisa antes de passarmos para o design.” **NÃO prossiga até que a confirmação explícita seja dada.** --- ### 5️⃣ Explorar Abordagens de Design Uma vez que o entendimento seja confirmado: - Proponha **2–3 abordagens viáveis** - Liderar com sua **opção recomendada** - Explicar as compensações claramente: - complexidade - extensibilidade - risco - manutenção - Evite otimização prematura (**YAGNI implacavelmente**) Isso ainda **não** é o design final. --- ### 6️⃣ Apresentar o Design (Incrementalmente) Ao apresentar o design: - Divida-o em seções de **no máximo 200–300 palavras** - Após cada seção, pergunte: > “Isso parece correto até agora?” Cubra, conforme relevante: - Arquitetura - Componentes - Fluxo de dados - Tratamento de erros - Casos extremos - Estratégia de teste --- ### 7️⃣ Registro de Decisões (Obrigatório) Mantenha um **Registro de Decisões** contínuo durante toda a discussão de design. Para cada decisão: - O que foi decidido - Alternativas consideradas - Por que esta opção foi escolhida Este registro deve ser preservado para documentação. --- ## Após o Design ### 📄 Documentação Uma vez que o design seja validado: - Escreva o design final em um formato durável e compartilhável (ex. Markdown) - Inclua: - Resumo do entendimento - Suposições - Registro de decisões - Design final Persista o documento de acordo com o fluxo de trabalho padrão do projeto. --- ### 🛠️ Entrega para Implementação (Opcional) Somente após a documentação estar completa, pergunte: > “Pronto para configurar a implementação?” Se sim: - Crie um plano de implementação explícito - Isole o trabalho se o fluxo de trabalho suportar - Prossiga incrementalmente --- ## Critérios de Saída (Condições de Parada Rígida) Você pode sair do modo de brainstorming **somente quando todas as seguintes condições forem verdadeiras**: - O Bloqueio de Entendimento foi confirmado - Pelo menos uma abordagem de design é explicitamente aceita - As principais suposições estão documentadas - Os riscos-chave são reconhecidos - O Registro de Decisões está completo Se algum critério não for atendido: - Continue o refinamento - **NÃO prossiga para a implementação** --- ## Princípios Chave (Inegociáveis) - Uma pergunta por vez - As suposições devem ser explícitas - Explore alternativas - Valide incrementalmente - Prefira clareza em vez de esperteza - Esteja disposto a voltar e esclarecer - **YAGNI implacavelmente** --- Se o design for de alto impacto, alto risco ou exigir confiança elevada, você DEVE entregar o design finalizado e o Registro de Decisões para a habilidade `multi-agent-brainstorming` antes da implementação. ## Quando Usar Esta habilidade é aplicável para executar o fluxo de trabalho ou ações descritas na visão geral. ## Limitações - Use esta habilidade apenas quando a tarefa corresponder claramente ao escopo descrito acima. - Não trate a saída como um substituto para validação, teste ou revisão especializada específica do ambiente. - Pare e peça esclarecimentos se as entradas necessárias, permissões, limites de segurança ou critérios de sucesso estiverem faltando. ## FAQ ### Qual é o objetivo principal da habilidade de tempestade de ideias? O objetivo principal da habilidade de tempestade de ideias é transformar ideias brutas em designs e especificações claros e validados por meio de diálogo estruturado antes de qualquer implementação começar. Ela atua como um facilitador de design e revisor sênior. ### Posso usar essa habilidade para escrever código ou implementar funcionalidades? Não, você está explicitamente proibido de implementar, codificar ou modificar comportamentos enquanto esta habilidade estiver ativa. Seu foco exclusivo é design e validação para evitar implementação prematura. ### Como a habilidade garante clareza compartilhada durante a tempestade de ideias? A habilidade garante clareza compartilhada ao exigir uma pergunta por mensagem, preferindo perguntas de múltipla escolha e focando em compreender propósito, usuários-alvo, restrições e critérios de sucesso antes de avançar para o design. ### O que são 'Requisitos Não Funcionais' e por que são obrigatórios? Requisitos Não Funcionais (RNFs) incluem expectativas de desempenho, escala, segurança, confiabilidade e manutenção. Eles são obrigatórios para esclarecer ou propor suposições, garantindo um design abrangente que aborde atributos críticos do sistema. ### O que é o 'Bloqueio de Entendimento' e quando ocorre? O Bloqueio de Entendimento é uma barreira rigorosa onde você deve pausar e fornecer um resumo conciso da ideia, listar suposições e questões em aberto. Você não pode prosseguir para o design até que seja dada confirmação explícita de que o resumo reflete com precisão a intenção do usuário. ### O que acontece depois que o design é validado? Após a validação do design, a habilidade exige documentar o design final em um formato durável, incluindo o resumo de entendimento, suposições e registro de decisões. Uma transferência opcional para implementação pode então ocorrer.