B16 Immersive Frontend
Crie uma experiência memorável em torno de uma única ideia visual defensável. Este skill complementa um fluxo de trabalho de projeto mais amplo; ele não substitui habilidades de governança, planejamento, construção, verificação ou revisão e não pretende reproduzir o B16 Dev OS.
Estabeleça o briefing
Digeste todo o contexto disponível antes de fazer perguntas. Infira fatos apenas quando as evidências os apoiarem, cite a fonte ou rotule a inferência, e pergunte apenas sobre lacunas que possam mudar materialmente a direção. Use briefing.md quando a direção ainda não estiver aprovada.
Antes da implementação, apresente uma direção compacta cobrindo a tese visual, hierarquia de conteúdo, ponto focal do herói, tipografia, paleta, ritmo de layout, narrativa de movimento, pilha provável, orçamento de performance, fallbacks, proveniência de assets e exclusões. Obtenha aprovação para esta direção. Não trate a aprovação de um conceito como permissão para implantação, compras, contas, tokens ou alterações não relacionadas no sistema.
Projete com intenção
- Comece pelo mobile, depois expanda a composição e coreografia para viewports maiores.
- Fundamente a identidade no assunto, público, materiais, linguagem e conteúdo real. Evite uma aparência genérica de kit de componentes.
- Gaste ousadia visual em um lugar memorável e mantenha o sistema de suporte disciplinado.
- Escreva texto humano e tecnicamente preciso em voz ativa. Use caixa baixa e sem travessão (—). Nunca invente provas, parceiros, depoimentos, métricas ou capacidades.
- Use uma família de ícones coerente por projeto, escolhida por adequação à pilha, identidade, cobertura, licença, custo, manutenção, acessibilidade e peso. Use marcas oficiais ou autorizadas. Importe ícones individuais com tree shaking real onde a pilha suportar.
- Torne toda ação primária operável sem hover. Especifique estados de toque, teclado, foco, ativo, carregamento, desabilitado, erro e vazio onde relevante.
Escolha a menor pilha suficiente
Leia stack-selection.md quando movimento, canvas 2D ou 3D estiver em consideração. Preserve a pilha atual a menos que uma mudança seja justificada e aprovada.
Não adicione React ao WordPress para um único efeito. Não torne nenhuma biblioteca obrigatória entre sites. Não instale uma dependência meramente porque aparece em um plano. Prefira CSS e APIs de plataforma para transições simples, Motion para coreografia de componentes, GSAP com ScrollTrigger para sequências deliberadas de timeline ou scroll, PixiJS para cenas 2D exigentes, Three.js para WebGL direto, e React Three Fiber com helpers seletivos do drei quando React já existir e a composição declarativa de cena for benéfica. Lenis é opcional, nunca automático.
Use ReactBits e Codrops apenas como referências seletivas. Confirme a licença e proveniência de código e assets antes da reutilização. Prefira síntese original; preserve avisos necessários para qualquer trecho licenciado.
Especifique o movimento antes de construí-lo
Para toda animação significativa, registre:
- Propósito: o que ela explica, prioriza, confirma ou torna espacialmente legível.
- Gatilho: carregamento, entrada, clique, mudança de estado, ponteiro, scroll ou progresso de mídia.
- Duração e easing: inclua limites para repetição e interrupção.
- Comportamento mobile: o que muda para viewport, ponteiro grosso, toque, bateria e capacidade do dispositivo.
- Fallback: estado estático final para movimento reduzido, JavaScript indisponível, mídia falha, WebGL perdido ou hardware restrito.
Evite significado apenas em hover e movimento contínuo decorativo. Navegação, mensagem principal e CTA devem funcionar antes da animação concluir. Sob prefers-reduced-motion: reduce, renderize estados finais estáveis e remova comportamento de scrub, parallax, reprodução automática ou scroll suave em vez de apenas encurtá-lo.
Orçamento de performance
Defina orçamentos mensuráveis apropriados ao projeto antes da implementação. Considere JavaScript inicial, peso de mídia, contagem de fontes, concorrência de animação, tarefas longas, mudança de layout, tempo de maior conteúdo, estabilidade de quadro, memória GPU, proporção de pixels do dispositivo e custo térmico.
Para canvas ou WebGL, forneça um poster estático; limite a proporção de pixels; pause quando fora da tela ou oculto; evite alocação por quadro; reduza trabalho em dispositivos pequenos ou restritos; lide com falha de contexto; e descarte quadros, observadores, listeners, texturas, geometrias, materiais, alvos de renderização e estado do renderizador. Conteúdo semântico e controles devem permanecer fora ou independentes do canvas.
Implemente proporcionalmente
Preserve a direção aprovada e as convenções existentes do projeto. Mantenha HTML semântico e conteúdo real como fonte da verdade. Carregue experiências pesadas apenas onde agregam valor. Escolha efeitos para que múltiplos sistemas não controlem a mesma propriedade. Use no máximo um mecanismo de scroll suave, e apenas quando seu valor superar a complexidade.
Não instale bibliotecas, modifique um projeto ou implemente antes do plano ser aprovado. Quando a implementação for autorizada, explique qualquer adição de pilha ou asset antes de fazê-la e respeite o gerenciador de pacotes e o arquivo de bloqueio do projeto.
Verifique honestamente
Use verification.md para trabalho de implementação ou revisão. Inspecione capturas de tela mobile e desktop, estados de interação, toque, teclado, foco, movimento reduzido, fallbacks estáticos, comportamento de carregamento e falha, evidências de performance e comportamento de limpeza na proporção da mudança.
Relate exatamente o que rodou, o que passou, o que foi inspecionado visualmente e o que permanece não verificado. Nunca insinue que uma construção, teste de navegador, verificação de acessibilidade, teste de dispositivo ou medição de performance foi executada se não foi.
Proveniência da referência
A orientação é uma síntese original. Consulte sources.md para documentação autoritativa e inspiração da comunidade claramente rotulada. Não instale nem execute código de skill de terceiros através deste skill.