tieveto666-code/product-prototype-builder

Construtor de Protótipo de Produto

Use esta habilidade para transformar uma ideia vaga de produto em entregas de três estágios, do zero ao um:

1. Discussão de requisitos
2. Especificação de requisitos (PRD)
3. Protótipo HTML interativo em arquivo único

O usuário pode fornecer apenas uma ideia inicial. Não pule diretamente para a geração de PRD ou protótipo, a menos que o estágio anterior tenha informações suficientes e confirmadas pelo usuário.

Regras Principais

• Quando o usuário usar português, a comunicação e as entregas serão em português por padrão.
• Trate este fluxo como uma exploração colaborativa de produto, não como geração única de documentos.
• Registre continuamente requisitos, decisões, questões em aberto, suposições e mudanças de versão.
• Decisões importantes de produto devem ser confirmadas com o usuário antes de serem incluídas na especificação final.
• Não gere o PRD até que o usuário confirme explicitamente que a discussão de requisitos está suficientemente completa.
• Não gere o protótipo até que o usuário confirme explicitamente que o PRD está correto e que a geração do protótipo pode começar.
• Se o usuário modificar requisitos após a geração do PRD ou protótipo, primeiro atualize o registro de discussão de requisitos e depois crie uma nova versão do PRD ou protótipo com base no escopo do impacto.
• Quando informações de mercado, concorrentes, políticas, tecnologia, preços ou estado da indústria puderem influenciar o julgamento de requisitos, use ferramentas de busca online disponíveis para complementar os dados e resuma as fontes e conclusões. Dados externos são apenas suposições e devem ser confirmados pelo usuário antes de se tornarem conclusões de requisitos.

Estrutura do Workspace

Crie e mantenha a seguinte estrutura no diretório de trabalho atual:

workspace/
├── 01-discussions/
│   └── {nome-do-requisito}-discussao.md
├── 02-specifications/
│   └── {nome-do-requisito}/
│       ├── v001-{nome-do-requisito}-especificacao.md
│       ├── v002-{nome-do-requisito}-especificacao.md
│       └── index.md
└── 03-prototypes/
    └── {nome-do-requisito}/
        ├── v001-{nome-do-prototipo}.html
        ├── v002-{nome-do-prototipo}.html
        └── index.md

Se o projeto já tiver um diretório raiz adequado, use o diretório existente e não crie workspace/ desnecessariamente. Nomes de arquivo devem ser concisos, claros e evitar caracteres especiais que não são adequados para sistemas de arquivos.

Regras de Versionamento

• PRDs e protótipos devem usar números de versão como v001, v002, v003, etc.
• Não substitua arquivos versionados de PRD ou protótipo existentes. Crie a próxima versão para cada modificação importante.
• Cada index.md deve registrar:
  • Número da versão
  • Caminho do arquivo
  • Data de criação ou atualização, se disponível
  • Breve descrição da mudança
  • Status, como draft, confirmed, superseded
• O arquivo de discussão de requisitos é a fonte da verdade em evolução contínua e deve ser atualizado ao longo de todo o processo.

Estágio Um: Discussão de Requisitos

Objetivo: Organizar a ideia inicial do usuário em uma base de requisitos clara, completa e confirmável.

Ações executadas:

1. Crie ou atualize workspace/01-discussions/{nome-do-requisito}-discussao.md.
2. Faça perguntas focadas em estilo de conversa livre. A cada rodada, priorize 3 a 7 perguntas de alto valor.
3. Registre o seguinte:
   • Ideia original
   • Usuários-alvo e cenários de uso
   • Dores do usuário e valor do produto
   • Fluxo de uso principal
   • Requisitos funcionais
   • Objetos de dados e campos-chave
   • Papéis do usuário e permissões
   • Regras de negócio
   • Expectativas de interação
   • Preferências visuais e de estilo
   • Restrições e escopo não alvo
   • Perguntas a confirmar
   • Decisões confirmadas
4. Ao encontrar requisitos irracionais, arriscados, contraditórios ou ausentes, aponte o problema, explique o impacto e ofereça opções.
5. Quando necessário, consulte produtos similares, práticas da indústria, restrições políticas ou viabilidade técnica. Resuma os resultados da consulta e pergunte ao usuário se deseja adotar as suposições relacionadas.
6. Durante a discussão, resuma periodicamente os requisitos atuais e sincronize-os com o arquivo de discussão.

Portão de Estágio:

• Antes de entrar no Estágio Dois, pergunte ao usuário se ele confirma que os requisitos estão suficientemente completos para gerar o PRD.
• Confirmações aceitáveis incluem “pode gerar o PRD”, “requisitos OK”, “gerar documento de requisitos” e expressões sinônimas.
• Se o usuário solicitar a geração do PRD prematuramente, primeiro resuma as lacunas atuais e depois faça apenas as perguntas mais necessárias.

Estágio Dois: Especificação de Requisitos (PRD)

Objetivo: Gerar um documento PRD em Markdown completo e bem estruturado.

Crie a próxima versão no seguinte caminho:

workspace/02-specifications/{nome-do-requisito}/v00N-{nome-do-requisito}-especificacao.md

Estrutura recomendada do PRD:

# Documento de Requisitos do Produto {nome-do-requisito} v00N

## 1. Objetivo do Requisito
## 2. Contexto e Dores do Usuário
## 3. Papéis do Usuário e Cenários Principais
## 4. Escopo dos Requisitos
## 5. Escopo Não Alvo
## 6. Arquitetura do Produto
## 7. Fluxo de Uso
## 8. Estilo do Produto e Layout Funcional
## 9. Detalhamento de Funcionalidades e Lógica de Interação
## 10. Objetos de Dados e Campos
## 11. Estados, Regras e Tratamento de Exceções
## 12. Lista de Páginas do Protótipo
## 13. Critérios de Aceitação
## 14. Perguntas em Aberto
## 15. Histórico de Versões

Requisitos de qualidade do PRD:

• O conteúdo deve ser específico o suficiente para sustentar a geração do protótipo.
• Não liste apenas nomes de funcionalidades; descreva o comportamento em nível de página e componente.
• Conforme necessário, descreva estados vazios, estados de carregamento, estados de erro, estados de permissão e limites importantes.
• A estrutura do produto deve ser esteticamente agradável, fácil de usar e com lógica funcional clara.
• Todas as suposições devem ser claramente marcadas, indicando se estão confirmadas ou pendentes.

Após a entrega:

• Atualize o index.md na área de especificações.
• Pergunte ao usuário se precisa modificar o PRD.
• Se o usuário solicitar modificações, primeiro atualize o arquivo de discussão de requisitos e depois crie uma nova versão do PRD.

Portão de Estágio:

• Não entre no Estágio Três até que o usuário confirme explicitamente que o PRD está correto e que a geração do protótipo pode começar.
• Confirmações aceitáveis incluem “PRD OK”, “pode gerar o protótipo”, “começar o HTML” e expressões sinônimas.

Estágio Três: Protótipo HTML Interativo

Objetivo: Gerar um protótipo HTML em arquivo único, bonito, unificado, operável e experienciável.

Ao entrar neste estágio, leia e execute a especificação de qualidade do protótipo em references/prototype-quality.md.

Antes de gerar o arquivo:

• Informe brevemente ao usuário o efeito esperado do protótipo, incluindo as principais páginas, profundidade de interação, estilo visual e lógica de simulação.
• Explique as limitações críticas apenas quando necessário.
• Gere uma “lista de interações do protótipo”, especificando o comportamento interativo de cada página, navegação, botão, aba, filtro, busca, formulário, modal, gaveta, operações CRUD e componentes dinâmicos.
• Para componentes complexos como orquestração de fluxo, gráficos visuais, diagramas de fluxo, kanban, arrastar e soltar, e relacionamentos entre nós, indique quais interações dinâmicas serão implementadas; não faça apenas exibição estática.

Crie a próxima versão no seguinte caminho:

workspace/03-prototypes/{nome-do-requisito}/v00N-{nome-do-prototipo}.html

Requisitos do protótipo:

• Entregue um único arquivo .html independente.
• HTML, CSS e JavaScript devem estar todos inline no mesmo arquivo por padrão.
• O arquivo deve poder ser aberto diretamente em navegadores modernos.
• O protótipo deve ser um protótipo funcional e interativo, não uma captura de tela estática.
• Implemente estados de UI realistas, navegação entre páginas, formulários, modais, gavetas, abas, filtros, buscas, validações, fluxos simulados e lógica de negócio, conforme os requisitos.
• Todos os elementos clicáveis devem ter um resultado interativo perceptível. Botões principais, menus, abas, botões de ícone e pontos de entrada operacionais que pareçam clicáveis não podem ficar sem reação.
• Botões CRUD devem ter lógica simulada, como adicionar dados, editar com preenchimento, confirmar exclusão, visualizar detalhes, filtrar por busca, atualizar estado ou fornecer feedback.
• O layout da página deve ser verificado quanto a espaçamento, evitando problemas como barra lateral e área de conteúdo coladas, botões muito próximos, texto sobreposto, elementos sobrepostos ou conteúdo oculto.
• Use dados simulados e estado do lado do navegador. Quando necessário para melhorar a experiência, use localStorage para salvar dados temporários.
• Por padrão, não dependa de serviços de backend, bancos de dados reais, etapas de build, instalação de pacotes ou APIs externas.
• A menos que o usuário concorde explicitamente, não dependa de CDNs externas.
• O sistema visual geral deve ser uniforme, incluindo espaçamento, fontes, cores, estilos de componentes, botões, tabelas, cartões, formulários, gráficos, navegação e estados de feedback.
• Todos os fluxos principais devem poder ser demonstrados com dados de exemplo.
• A profundidade da interação deve ser suficiente para que o usuário experimente o comportamento principal do produto.

Observações importantes:

• “Protótipo HTML em arquivo único” não significa “sem interação”.
• Significa que o protótipo pode ser executado localmente no navegador, implementando interação e lógica de negócio por meio de simulação front-end.
• Se o usuário solicitar login real, API real, persistência em banco de dados, pagamento, armazenamento de arquivos ou implantação em produção, explique que isso está além do escopo de um protótipo de arquivo único e pergunte se ele deseja simular no protótipo ou migrar para um plano de implementação de engenharia.

Requisitos de verificação:

• Verifique se o HTML gerado contém referências quebradas.
• Se houver navegador ou ferramenta de renderização disponível, abra o HTML e valide o layout, a responsividade e as interações principais.
• Antes de entregar, corrija problemas óbvios de sobreposição de layout, fluxos quebrados, estados ausentes ou erros de JavaScript.
• Use a lista de verificação pré-entrega em references/prototype-quality.md para auto-inspeção item por item. Se encontrar itens não implementados, sem resposta ou com layout irracional, corrija antes de entregar.

Após a entrega:

• Atualize o index.md na área de protótipos.
• Informe ao usuário o caminho do arquivo e o número da versão criada.
• Primeiro resuma o que o protótipo contém e depois peça feedback.

Modo de Conversação

• Mantenha-se proativo, mas respeite rigorosamente os portões de estágio.
• Faça perguntas apenas quando elas melhorarem significativamente o resultado.
• Quando o usuário estiver incerto, ofereça de 2 a 4 opções concretas e dê uma recomendação.
• Quando o usuário pedir para acelerar, crie a primeira versão com base em suposições razoáveis, mas ainda assim obtenha confirmação antes de cruzar os estágios.
• Quando o usuário solicitar modificações, avalie se elas afetam a discussão de requisitos, o PRD, o protótipo ou todos os três.
• Quando o usuário solicitar uma reversão, use o index.md correspondente e os arquivos versionados para localizar a versão alvo.

Nota de Migração

Esta habilidade foi escrita como instruções de fluxo de trabalho Markdown genéricas. Ao migrar para uma ferramenta diferente do Codex, use references/portable-prompt.md como prompt do sistema, instrução personalizada, regra de projeto ou regra de agente.