Protótipo UIUX
Projete interfaces de produto em torno de tarefas reais. Entregue HTML revisável antes da implementação do aplicativo. Trabalhe no idioma do usuário; use explicações em português por padrão, com os termos técnicos em inglês quando necessário. Esta skill é autocontida: skills upstream e serviços de referência pagos são opcionais, não dependências.
1. Estabeleça o produto e preserve sua linha de base
Leia primeiro os arquivos AGENTS.md, HANDOFF.md, DESIGN.md existente e os arquivos de protótipo atuais. Identifique os usuários, cenário, entrada, tarefa principal, resultado, valor de negócio, superfícies solicitadas e o que está fora desta versão. Preserve as decisões de marca existentes e as edições de outras pessoas. Resolva detalhes rotineiros você mesmo; pergunte apenas por informações faltantes que alterem materialmente o design.
Concorde com um inventário delimitado de telas/fluxos a partir do briefing, não um número arbitrário de páginas. Cubra cada superfície solicitada (web, mini programa, mobile, desktop); não invente um aplicativo irrelevante. Se o escopo da superfície for desconhecido e o projeto não puder estabelecê-lo, pergunte uma vez antes de prosseguir. Uma UI herdada recebe uma auditoria e uma versão que não sobrescreve, não um redesign não solicitado.
Leia as seções de regras de decisão relevantes (§1–7) em source-synthesis.md; use seu mapa de fonte (§8–10) quando uma compensação precisar de explicação. Ele integra todos os sete repositórios de origem. A clareza da tarefa do produto, os contratos de design existentes e as escolhas do usuário têm precedência sobre convenções de landing page, proibições de estilo e temas aleatórios.
2. Pesquise referências, depois PARE para uma decisão de estilo
Leia reference-research.md. Comece pelo Dribbble; use 即时设计 e Behance como fallbacks ou suplementos. Pesquise pela categoria do produto, pela tarefa do usuário e pela plataforma relevante, não apenas "UI bonita". Use ferramentas de navegação/pesquisa disponíveis; registre quais páginas e imagens foram realmente inspecionadas. Não considere um trecho de pesquisa como uma revisão visual. Observe as restrições de acesso; se os casos reais não puderem ser visualizados, relate isso e peça referências fornecidas ou uma renúncia explícita à pesquisa.
Crie uma nova versão em docs/prototype/versions/vX.Y.Z/ (ou na raiz de protótipo estabelecida do projeto). Use a CLI abaixo para começar com segurança. Escreva style-reference.html primeiro: normalmente 2–3 direções diferenciadas e apropriadas para a tarefa, links/criadores de casos reais, evidências observadas versus sua interpretação, amostras de tokens e um pequeno estudo de UI original da MESMA tarefa para comparação. Inclua adequação à plataforma, limitações e sua recomendação. Preserve as escolhas de marca conhecidas; quando o usuário já forneceu uma direção, valide-a em vez de forçar alternativas.
Entregue o style-reference.html real e peça ao usuário para escolhê-lo ou revisá-lo. Pare aqui. Não crie as telas completas do aplicativo, design-system.html ou DESIGN.md final até que o usuário aprove explicitamente uma direção nomeada (ou delegue essa escolha exata na tarefa atual). Um botão de rádio/card selecionado localmente, uma recomendação preferida, tempo decorrido ou um registro de CLI não é autorização do usuário. Mantenha a evidência de aprovação junto com o SHA-256 do HTML aprovado; uma alteração material nesse quadro precisa de uma nova decisão. Não trate esta porta como permissão para perguntar novamente sobre trabalho não relacionado já autorizado.
3. Construa o protótipo HTML completo após a aprovação
Leia prototype-contract.md e apenas as seções relevantes de platforms-and-quality.md. Registre a decisão real do usuário; o helper registra a evidência, não pode verificar quem a deu. Em seguida, prepare e substitua os scaffolds gerados por artefatos projetados e funcionais:
index.html: protótipo home/navegação com versão, entradas de superfície, fluxos principais, referência de estilo e links de especificação visual. Cada aplicativo também tem sua própria home orientada a tarefas. Mantenha detalhes de implementação/status neste hub de revisão, não no chrome do produto.design-system.html: especificação visual completa para componentes usados nesta versão: cores semânticas, tipografia, espaçamento, layout/densidade, ícones, superfícies, estados de componente aplicáveis, interação/movimento e diferenças responsivas/de plataforma. Mostre exemplos renderizados reais, não apenas tabelas de nomes.DESIGN.md: decisões canônicas, valores de tokens, inventário de telas/fluxos, interações, sobreposições de plataforma, acessibilidade, proveniência e limitações conhecidas do protótipo. DESIGN.md por superfície explica apenas variações relevantes.- Telas HTML de cada superfície solicitada: caminhos críticos completos acordados, dados sintéticos rotulados plausíveis, navegação e mudanças de estado significativas. Tokens semânticos compartilhados; interação apropriada à plataforma, não uma captura de tela de desktop reduzida.
Use HTML semântico, variáveis CSS e pequenos scripts locais por padrão. Reutilize o framework/componentes existentes quando isso reduzir a complexidade; sem React, Tailwind, shadcn ou dependência de rede obrigatória. Um protótipo HTML estático deve abrir através de um servidor HTTP local e deve permanecer navegável com URLs de arquivo quando viável. Os ativos necessários para revisar o protótipo devem ser locais e licenciados. Mantenha o protótipo separado do código-fonte do aplicativo.
4. Verifique, versione e entregue
Use platforms-and-quality.md para revisar o resultado renderizado em viewports estreitas e largas, foco do teclado, zoom e movimento reduzido; inspecione o comportamento aplicável do dispositivo/plataforma. Teste os caminhos primários reais, além dos estados vazio/carregamento/erro/sucesso e de conteúdo extremo que importam. Não afirme aceitação de dispositivo ou SDK nativo a partir de simulação de navegador. Corrija os problemas observados e verifique novamente os caminhos afetados.
Execute a validação estrutural e, em seguida, registre evidências do navegador, tamanhos de viewport, fluxos testados e problemas não resolvidos em QA.md. A validação estrutural não pode provar qualidade visual, integridade de negócios, aplicação de permissões, integração externa ou prontidão para produção. Relate itens não testados explicitamente. Para trabalho de implantação, meça os custos relevantes de carregamento/tempo de execução/recursos em vez de relatar apenas verificações funcionais; protótipos locais comuns não exigem um conjunto de benchmarks de produção.
Mantenha as versões anteriores intactas. Leia versioning.md para invalidação de aprovação, revisões, snapshots selados, changelog e navegação da versão mais recente. Não edite silenciosamente um quadro aprovado ou sobrescreva um protótipo mais antigo. Entregue links para os arquivos reais, como abri-los, o que foi verificado e o que permanece simulado.
Helper (Python 3, biblioteca padrão)
Resolva <skill-dir> para o diretório desta skill instalada. Os comandos operam apenas no projeto especificado; eles não publicam ou alteram o código-fonte do aplicativo.
python3 <skill-dir>/scripts/prototype.py init --project <project> --version v0.1.0 --surfaces web miniapp mobile desktop
# Edite style-reference.html com pesquisa real; obtenha a decisão do usuário.
python3 <skill-dir>/scripts/prototype.py record-approval --project <project> --version v0.1.0 --direction "B" --evidence "Decisão exata do usuário nesta conversa"
python3 <skill-dir>/scripts/prototype.py prepare --project <project> --version v0.1.0
# Substitua cada scaffold pendente, implemente os fluxos acordados e renderize/reveja.
python3 <skill-dir>/scripts/prototype.py validate --project <project> --version v0.1.0 --complete
python3 <skill-dir>/scripts/prototype.py seal --project <project> --version v0.1.0 --summary "Escopo revisado e alterações materiais"
record-approval armazena um registro de fluxo de trabalho, não uma identidade ou limite de segurança. Nunca invente sua evidência. prepare produz scaffolds, não um protótipo finalizado. seal registra hashes de arquivos; não é uma aprovação visual ou armazenamento imutável. Use o manifesto e a evidência de QA juntos.