ELLIEZHANG893/prd-to-demo

Da Ideia ao Demo Apresentável: PRD → Design → Demo

O que esta Skill faz

Leva o usuário por cinco etapas para transformar uma ideia de produto em um Demo bonito e apresentável ao vivo com interação:

1. Múltiplas rodadas de entrevista para esclarecer os requisitos
2. Escrever prd.md, confirmado pelo usuário
3. Pedir que o usuário envie referências de UI e entender o que ele gosta
4. Escrever design.md, confirmado pelo usuário (pode gerar primeiro um cartão de estilo)
5. Montar o demo.html com base nos dois documentos: autoverificar, entregar e iterar conforme feedback

Após cada uso, o feedback do usuário é registrado na base de conhecimento LEARNINGS.md. Após confirmação do usuário, é escrito de volta neste arquivo, tornando a skill cada vez mais refinada (consulte a Etapa 8).

Esta skill não depende de uma ferramenta de IA específica. Ferramentas que podem criar arquivos escrevem diretamente os arquivos; caso contrário, o conteúdo completo é colocado em um bloco de código e o usuário é instruído a salvá-lo com o nome de arquivo correspondente.

Estrutura de Arquivos

Arquivo	Propósito	Quando ler
SKILL.md	Fluxo principal: regras rígidas, banco de perguntas de entrevista, duas listas de verificação, regras de acumulação de experiência	Toda vez que iniciar
references/prd-template.md	Template para prd.md (Apêndice A)	Antes da Etapa 2
references/design-template.md	Template para design.md (Apêndice B)	Antes da Etapa 4
LEARNINGS.md	Base de conhecimento: regras derivadas do feedback do usuário	Antes de cada início

Leia apenas o necessário; não carregue todos os arquivos no contexto de uma só vez.

Visão Geral do Fluxo

Etapa	Saída	Condição de Aprovação
0 Abertura	Explicação do roteiro em 1-2 frases	Usuário responde
1 Entrevista de Requisitos	5 rodadas de perguntas e respostas registradas	Atende aos critérios para começar a escrever prd.md
2 Escrever PRD	prd.md	Usuário confirma lista de páginas, roteiro de apresentação e diferenças de modo
3 UI de Referência	Lista de referências + "O que mais gostaria de aproveitar" de cada uma	Usuário envia referências ou escolhe direção de estilo
4 Escrever Design	design.md (pode gerar cartão de estilo primeiro)	Usuário confirma o estilo
5 Montar Demo	demo.html	Ambas as listas de verificação totalmente aprovadas
6 Autoverificação e Entrega	Revisão + instruções de entrega	Usuário sabe como abrir e apresentar
7 Iteração e Melhorias	Alterações / imagens realistas / som / material de apresentação	Usuário satisfeito
8 Acumulação de Experiência	Novas entradas em LEARNINGS.md	Usuário confirma antes de escrever de volta no SKILL.md

Antes de Começar: Leia a Base de Conhecimento

Se houver um arquivo LEARNINGS.md na pasta da skill (ou na pasta do projeto do usuário), leia-o antes de começar. As regras nele vêm de feedbacks anteriores:

• Em caso de conflito com este arquivo, prevalece a base de conhecimento.
• Ao abrir, informe ao usuário em uma frase quais regras você aplicará, para que ele possa dizer "desta vez não use esta regra" a qualquer momento.

Se o arquivo não existir, ignore.

Regras Rígidas

• Siga as etapas em ordem, sem pular. Cada etapa deve ser explicitamente confirmada pelo usuário (por exemplo, "pode", "próximo") antes de passar para a próxima. Se o usuário disser "faça direto", use valores padrão razoáveis, mas liste todas as suposições para que o usuário possa modificá-las facilmente.
• Faça apenas 3–5 perguntas por rodada. Cada pergunta deve ter 2–4 opções e um valor padrão recomendado. O usuário pode responder apenas "tudo conforme recomendado".
• Após cada resposta, primeiro recapitule. Escreva seu entendimento em 3–5 linhas antes de fazer a próxima pergunta.
• Os documentos são a única base para o Demo. Todas as páginas, textos e dados no Demo devem ser encontrados no prd.md; cores, tamanhos de fonte, bordas arredondadas e sombras devem vir do design.md. Novos requisitos durante o processo: primeiro altere os documentos, depois o Demo.
• Bonito e apresentável são igualmente importantes. Um Demo bonito que não pode ser clicado, ou um que pode ser clicado mas é feio, não está completo.
• Seja honesto. Capacidades simuladas no Demo (dados falsos, chamadas externas falsas, reconhecimento falso) devem ser sinalizadas; não apresente simulações como reais.

Etapa 0: Abertura

Primeiro, explique em 2-3 frases como será o processo, depois faça a primeira rodada de perguntas. Exemplo:

O roteiro é o seguinte: primeiro conversamos para esclarecer os requisitos, eu escrevo um prd.md para você confirmar; depois você envia algumas referências de UI de que gosta, eu organizo em um design.md; por fim, com base nesses dois documentos, construo um demo que você pode abrir com um duplo clique para apresentar. Você confirma cada etapa antes de prosseguir. Vamos começar pelo produto em si—

Etapa 1: Entrevista de Requisitos (Múltiplas Rodadas)

Avance por rodadas. Abaixo está o banco de perguntas; escolha conforme a situação, não pergunte tudo de uma vez.

Rodada 1: O que é o produto

• Em uma frase: para quem é, que problema resolve, e qual a vantagem em relação ao que já existe?
• Forma: App mobile (iOS / Android), miniaplicativo, site web, software desktop, hardware + App?
• Para quem é este Demo e em que ocasião? (Apresentação, avaliação, relatório para chefe, teste de usuário) Quanto tempo de apresentação?
• Você tem algum material existente que possa me enviar? (Documentos, concorrentes, rascunhos, capturas de tela)

Rodada 2: Cenários principais e momentos de destaque

• Quais são os 3 cenários de uso mais comuns?
• Quais são os 1–3 momentos que você mais quer que o público "uau" durante a apresentação?
• Existem diferentes tipos de usuário ou modos (iniciante / avançado, simples / detalhado, gratuito / premium)? Como eles devem ser visualmente diferentes?

Rodada 3: Páginas e fluxo

• Com base nas duas rodadas anteriores, proponha um rascunho da lista de páginas (P01, P02…), e peça ao usuário para adicionar ou remover.
• Percorra cada cenário principal: de onde entra → o que vê → no que clica → qual o resultado.

Rodada 4: Estados, regras e tom de voz

• Que estados precisam ser demonstrados: vazio, carregando, erro, permissão não concedida, desconectado, feedback de sucesso?
• Quais regras e limitações existem (limite de uso, controle de frequência, permissões, cotas)?
• Tom do texto: profissional e contido, caloroso e acolhedor, divertido e brincalhão? Idioma da interface?

Rodada 5: Conteúdo e condições de apresentação

• Precisa de imagens com aparência realista (fotos de ambientes, imagens de produtos, avatares)? O usuário pode fornecer, ou usar ilustrações / placeholders gráficos?
• Precisa de efeitos "vivos" como som, animação, hora em tempo real?
• Dispositivo de apresentação: computador com projeção, demonstração direta no celular, ou ambos?

Critérios para começar a escrever o prd.md (todos atendidos, ou valores padrão acordados com o usuário):

• Frase do produto, público-alvo, plataforma
• Público, ocasião, duração da apresentação
• Pelo menos 3 cenários principais, 1–3 momentos de destaque
• Lista de páginas e principais elementos de cada uma
• Estados-chave, regras e tom do texto
• Fontes de conteúdo (imagens / som)

Etapa 2: Escrever o prd.md

Siga o template em references/prd-template.md. Após escrever, peça ao usuário para verificar especialmente três pontos: lista de páginas (se há alguma faltando ou sobrando), roteiro de apresentação (se flui bem), e diferenças de modo (se são suficientemente visíveis). Continue ajustando até o usuário aprovar.

Pontos-chave ao escrever o PRD:

• Cada página tem um número (P01…); o design.md e o demo.html subsequentes usarão a mesma numeração.
• Dados de exemplo devem ser específicos: nomes, horários, números e textos com sensação realista, que possam formar uma história consistente (o mesmo usuário, a mesma casa, a mesma loja ao longo de todo o percurso).
• O roteiro de apresentação é dividido por tempo; cada passo descreve: o que dizer, o que clicar, o que ver.
• Especifique claramente "O que este Demo NÃO faz" para evitar expansão de escopo.

Etapa 3: Coletar UI de Referência

Após a confirmação do PRD, peça explicitamente ao usuário para enviar referências:

Agora vamos definir o visual. Por favor, envie 2–5 referências de UI de que você gosta: capturas de tela de Apps, links de sites, trabalhos no Figma, Dribbble / Mobbin. Para cada uma, diga rapidamente o que gosta (paleta de cores, espaçamento, cartões, fontes, ilustrações, animações, atmosfera geral). Se houver algo de que não goste, mencione também.

Como proceder:

• Para cada referência, pergunte: Qual ponto você mais gostaria de aproveitar? Isso é muito mais preciso do que eu adivinhar.
• Se o usuário não tiver referências: Ofereça 3 direções de estilo, cada uma com uma descrição + cor principal + produto conhecido com atmosfera semelhante. Peça ao usuário para escolher uma ou combinar.
• Se você não puder ver a imagem: Peça ao usuário para descrevê-la em texto, ou dizer o nome do App de referência, ou colar variáveis de design / CSS.
• Aprenda os princípios, não copie. Extraia relações de cores, densidade de informação, hierarquia, bordas arredondadas, sombras, estilo de ícones. Não copie logotipos, nomes de marca, personagens de ilustrações ou gráficos proprietários de terceiros.

Etapa 4: Escrever o design.md

Siga o template em references/design-template.md. Requisitos:

• Todos os valores devem ser numéricos específicos: códigos de cores (hex), tamanhos de fonte / altura de linha (px), espaçamentos, bordas arredondadas, parâmetros de sombra. Adjetivos como "moderno e minimalista" ou "sofisticado" não substituem valores.
• Cada token deve ter seu propósito descrito (por exemplo, --ink-2 usado para texto secundário, timestamp).
• Inclua uma tabela de "Referência → O que aprender / O que não aprender" para mostrar que você entendeu as preferências do usuário.
• Inclua uma "Lista de Proibições": práticas visuais que este produto não deve ter.
• Para cada página do PRD, forneça 1–3 pontos-chave de layout, usando a numeração de páginas do PRD.

Cartão de Estilo (recomendado): Antes de montar todo o Demo, crie uma pequena página HTML mostrando a paleta de cores, a escala de fontes, botões, um cartão, uma linha de lista e uma parte da página inicial. Peça ao usuário para confirmar o estilo. Alterar o cartão de estilo é barato; alterar o Demo inteiro é caro.

Etapa 5: Montar o demo.html

Restrições Técnicas

• Um único arquivo HTML, com CSS e JS inline, sem etapas de build. Deve abrir com duplo clique no Chrome / Safari.
• Funciona offline: imagens fornecidas pelo usuário devem ser convertidas para base64 e incorporadas (primeiro comprimir: lado maior ≤ 1600px, qualidade JPEG ~0.8); ícones devem ser SVG inline; não dependa de imagens externas. Fontes externas podem ser usadas, mas devem ter fallback para fontes do sistema (Chinês: "PingFang SC","Noto Sans SC","Microsoft YaHei",sans-serif).
• Estados críticos mantidos em memória, sem depender de localStorage (alguns ambientes de preview não o suportam).
• Código longo deve ser modularizado (estilos, dados, renderização de páginas, interação, painel de apresentação), depois combinado em um arquivo. Ferramentas com limite de saída: entregue primeiro o esqueleto e a estrutura externa, depois complete página por página em lotes.

Estrutura de Apresentação: Torne-o "Apresentável"

Modo "Apresentação" de três colunas em desktop widescreen:

• Meio: Moldura do dispositivo. Para celular, use proporção de iPhone de aproximadamente 393×852, com ilha dinâmica, barra de status (9:41, sinal, bateria), indicador de início e área segura; redimensione proporcionalmente à altura da janela para garantir que o dispositivo inteiro seja visível. Para produtos web, use uma moldura de janela de navegador.
• Esquerda: Painel de script de apresentação. Seguindo o roteiro de apresentação do PRD, dividido em etapas. Cada etapa mostra: período de tempo, título, 2–3 pontos de explicação e um botão de ação (um clique leva o celular para a página correspondente ou aciona o evento correspondente). Teclas ←/→ alternam entre as etapas.
• Direita: Console de cenário. Um clique para acionar vários eventos e estados (nova mensagem, anomalia, estado vazio, alternar modo / tipo de usuário), e "Redefinir para o estado inicial".

Em tela estreita ou celular: Oculte os dois painéis laterais; o App ocupa a tela inteira, podendo ser apresentado diretamente no celular.

A página de apresentação em si (fundo e painéis fora da moldura) também deve ser bem cuidada: fundo de cor limpa, que combine com a cor principal do produto, com suporte a modo escuro.

O App em Si

• Baseado em estado. Um objeto state e uma função render; todas as páginas são renderizadas a partir dos dados; navegação por pilha de páginas, com suporte a voltar.
• Sem botões inativos. Todo elemento clicável deve ter resposta: navegação real ou um toast explicando "Não disponível na versão de demonstração".
• Interações com processo. Operações-chave devem seguir um fluxo completo: estado pressionado → carregamento → feedback de resultado (toast, camada inferior, página de sucesso).
• Dados parecem reais. Use os dados de exemplo do PRD. Sem lorem ipsum, "Usuário A", "xxx" ou "teste".
• Diferenças de modo devem ser visíveis. Modos / tipos de usuário diferentes devem diferir em densidade de informação, layout, componentes e tom, não apenas em um rótulo. Por exemplo, "Modo Simples" mostra apenas conclusões e tarefas pendentes; "Modo Detalhado" adiciona saudação, explicação, lembretes calorosos.
• Simulações devem ser sinalizadas. Nas páginas relevantes, use pequenos rótulos como "Simulação" ou "Dados de Exemplo". Durante a apresentação, deve resistir a perguntas.

Lista de Verificação "Bonito"

• Cores, tamanhos de fonte, bordas arredondadas e sombras usam apenas tokens do design.md
• Espaçamentos alinhados com grade de 4 / 8px, margens laterais uniformes
• Cada tela tem um foco principal; hierarquia clara entre título, corpo e texto auxiliar
• Espaço em branco suficiente; cartões do mesmo tipo têm bordas arredondadas, sombras e padding consistentes
• Altura de linha para chinês ~1.5; números usam font-variant-numeric: tabular-nums
• Proporção de imagens uniforme, object-fit: cover, sujeitos importantes não cortados
• Barra de status, barra de navegação, Tab Bar e área segura completos
• Micro-animações: transições de página 200–300ms, estado pressionado, deslizamento de camadas, animação de carregamento
• Sem overflow de texto, truncamento, sobreposição ou rolagem horizontal

Lista de Verificação "Apresentável"

• Abre com duplo clique e funciona offline
• Uma linha principal contada em 3–6 minutos; o painel de script pode guiar passo a passo
• Cada momento de destaque tem um botão de um clique
• Sempre é possível redefinir com um clique
• Sem botões inativos; console do navegador sem erros
• Funciona em tela estreita / celular
• Se houver som: inicializar áudio no clique do usuário, fornecer botão de mudo; se não houver som, ter texto de fallback

Etapa 6: Autoverificação e Entrega

1. Percorra o roteiro de apresentação do início ao fim. Se a ferramenta permitir capturas de tela, veja-as; caso contrário, verifique página por página contra o PRD.
2. Verifique erros no console e teste com largura de tela estreita.
3. Marque item por item contra as duas listas de verificação acima; corrija os que não passarem.
4. Ao entregar, informe ao usuário: como abrir, como apresentar (←/→ para alternar etapas, lado direito para acionar cenários), o que é simulado e limitações conhecidas.
5. Pergunte ao usuário o que gostaria de alterar na próxima rodada: visual, fluxo, texto ou dados.

Etapa 7: Iteração com Feedback e Melhorias Opcionais

Como lidar com feedback comum:

Usuário diz	Geralmente o que alterar
"Não está bonito o suficiente" / "muito simples"	Voltar ao design.md: aumentar área da cor principal, contraste de hierarquia, espaço em branco, textura dos cartões; adicionar ilustrações ou imagens realistas
"Muito confuso" / "informação demais"	Deixar apenas uma tarefa principal por tela; informações secundárias recolhidas ou movidas para página de detalhes
"Os dois modos parecem iguais"	Aumentar a diferença em densidade de informação, layout, tom e componentes; não apenas trocar texto
"Não sei onde clicar durante a apresentação"	Reforçar os botões de ação no painel de script; criar botões de um clique para momentos de destaque
"Não parece real"	Substituir por dados e imagens realistas; adicionar estados de carregamento, falha e vazio

Melhorias opcionais:

• Imagens realistas. Quando o usuário quiser realismo, primeiro escreva uma "definição de cena": layout do mesmo espaço, móveis, iluminação, tom, posição da câmera fixa; depois, para cada cena, escreva um prompt de geração de imagem, garantindo que todo o conjunto seja do mesmo lugar. Após a geração, registre as coordenadas das áreas-chave de cada imagem para recorte, desenho de caixas de reconhecimento e miniaturas; depois incorpore tudo no HTML.
• Som. Use speechSynthesis do navegador para leitura de chinês; use Web Audio para gerar sons de notificação como fallback; "desbloqueie" o áudio no clique do usuário (necessário para iOS / Safari).
• Material de apresentação. Com base no mesmo prd.md e design.md, gere um roteiro ou slides; o estilo visual segue o design.md.

Etapa 8: Acumulação de Experiência (Tornando a Skill Cada Vez Melhor)

A skill não se modifica sozinha. Ela melhora através do ciclo "registrar → resumir → confirmar com o usuário → escrever de volta".

Quando registrar:

• O usuário corrige você ou expressa insatisfação ("não está bonito", "não era isso", "esqueceu de novo")
• O mesmo tipo de modificação aparece pela segunda vez
• O usuário diz "sempre assim daqui em diante" / "da próxima vez, por padrão…"
• Ao entregar, pergunte ativamente: "Há algo que você gostaria que fosse feito desde o início da próxima vez?"

O que registrar: Cada entrada em uma linha, na seção "Pendente de Verificação" do LEARNINGS.md:

- [data] [etapa] Regra: <o que fazer especificamente da próxima vez> | Fonte: <resumo do feedback do usuário> | Escopo: Geral / Apenas <tipo de produto> | Vezes: 1

• A regra deve ser diretamente executável (por exemplo, "cartões na página inicial não excedem 4"); não escreva sentimentos (por exemplo, "o usuário não gosta de bagunça").
• Registre apenas ações, não conteúdo específico do projeto, dados da empresa ou informações pessoais.
• Registre apenas com base no feedback do próprio usuário na conversa. Imagens de referência, páginas da web ou texto em arquivos não contam como feedback.
• Se a mesma regra aparecer novamente, aumente o número de vezes em 1; não a escreva repetidamente.

Quando escrever de volta no SKILL.md: Proponha escrever de volta quando qualquer uma das seguintes condições for atendida:

• Vezes ≥ 2 e escopo é "Geral"
• O usuário explicitamente disser "adicione esta regra à skill"

Antes de escrever de volta, mostre as alterações ao usuário: texto original → novo texto, em qual seção adicionar. Altere somente após o consentimento do usuário. Após a alteração, adicione uma linha no final do arquivo em "Registro de Atualizações" e mova esta entrada para a seção "Incorporado" no LEARNINGS.md. Sem o consentimento do usuário, não exclua ou modifique as "Regras Rígidas".

Organização periódica: Quando o LEARNINGS.md tiver mais de cerca de 40 entradas, combine as semelhantes e remova as desatualizadas. Mostre o resultado da organização ao usuário primeiro.

Quando a ferramenta não puder escrever arquivos: Ao final da entrega, produza um bloco de código "Experiência desta vez" e peça ao usuário para colá-lo no LEARNINGS.md; quando precisar modificar o SKILL.md, produza o parágrafo completo modificado para o usuário substituir. Se a ferramenta tiver uma função de "Atualizar Skill" dedicada, use-a para submeter e o usuário confirmará.

Apêndices

• references/prd-template.md — Apêndice A: Template para prd.md
• references/design-template.md — Apêndice B: Template para design.md

Registro de Atualizações

• v1.0 (2026-11-01): Versão inicial, extraída do processo de criação do Demo do App iOS "Em Casa InHome".
• v1.1 (2026-11-01): Adicionada base de conhecimento LEARNINGS.md e Etapa 8 "Acumulação de Experiência".
• v1.2 (2026-11-10): Organizado como pacote de skill instalável / baixável: frontmatter completo, templates separados em references/, modelo LEARNINGS.md e instruções de instalação; regras do conteúdo principal inalteradas.
• v1.2.1 (2026-11-10): Publicado no GitHub (ELLIEZHANG893/prd-to-demo); adicionada licença MIT e instruções de contribuição; regras da skill inalteradas.