1LunarVeil/frontend-aesthetics

Estética de frontend

frontend-design define a postura: comprometer-se com uma direção e evitar padrões que ninguém escolheu. Este skill fornece as regras de decisão, os números, os dados de precedentes e as verificações que tornam essas escolhas verificáveis. Abra as referências e os nomes dos passos quando precisar; não os leia todos de uma vez.

1. Leia as regras do projeto primeiro

• Procure por um brief ou contrato antes de projetar: DESIGN.md, PRODUCT.md, um arquivo de tokens (tokens.css, theme.*, tailwind.config.*) ou um documento de contrato como FRONTEND_CONTRACT.md. Estes têm precedência sobre os padrões deste skill.
• Se o projeto roteia valores visuais através de tokens, um novo valor bruto de hex, px ou rgba em um componente é uma descoberta, não uma escolha de estilo.
• Mantenha o que já funciona: alternância de tema, chaves de i18n, comportamento de acessibilidade, componentes existentes. Reformule o escopo solicitado, não o aplicativo inteiro.

2. Brief

Escreva o brief descrito em references/principles.md: assunto, público e contexto, o trabalho da tela principal, densidade, idiomas e as cinco dimensões (tipografia, cor, layout, movimento, detalhes). Adicione três recusas: padrões com os quais este design não deve se parecer. Se o usuário não descreveu um gosto, proponha uma direção e diga por quê. Não interrogue o usuário.

3. Precedentes

Execute a partir do diretório base do skill:

python scripts/design_lookup.py "saas dashboard dark" --ux --motion

Use palavras-chave em inglês. A saída fornece o tipo de produto correspondente, seus estilos, uma paleta com pares de texto e UI verificados por contraste, combinações tipográficas e regras de raciocínio. Trate como evidência, não como resposta. Seu primeiro estilo é frequentemente uma escolha de tendência (glassmorphism, neon, bento) que é errada para ferramentas densas. Os pares de texto falham em apenas uma das 192 linhas da paleta, mas a maioria das paletas tem uma borda abaixo de 3:1 contra o fundo, então toda paleta precisa ter seus pares de UI verificados antes do uso.

4. Direção

Escolha uma direção de references/directions.md, ou defina a sua própria, e diga por que ela se encaixa neste brief e por que a alternativa mais próxima não serve. Gaste ousadia em um lugar: um elemento de assinatura. Tudo ao redor dele é disciplinado.

5. Tokens antes de componentes

Defina funções de cor, escala tipográfica, espaçamento, raios, elevação e durações de movimento como variáveis primeiro (references/color-and-type.md, references/layout-and-motion.md). Verifique cada par de texto que você enviar:

python scripts/wcag.py "#1f2937" "#ffffff" "#556070" "#f6f7f9"

6. Construção

Cubra todos os estados, não apenas o caminho feliz (references/components-and-states.md). Mantenha o texto nos idiomas do produto e teste a tradução mais longa.

7. Verifique antes de relatar

• Renderize e observe. python scripts/visual_capture.py <url> --out shots --matrix fornece visualizações padrão, 150% de escala, estreita e de telefone, aguarda um quadro estabilizado e relata erros de console. Leia references/visual-review.md; uma revisão sem captura não é uma revisão visual.
• Após uma alteração, capture novamente e execute scripts/image_diff.py before.png after.png. Se a região alterada não corresponder ao que você afirma ter alterado, a afirmação está errada.
• python scripts/slop_scan.py <caminhos alterados>. Status de saída 1 significa descobertas bloqueadoras.
• Contraste para cada par de texto e UI que você realmente enviou (wcag.py).
• Uma passagem apenas com teclado, uma passagem com movimento reduzido e o teste de quebra com dados de pior caso.
• Erros de console são falhas. Assim como uma captura relatada como blank; trate uma relatada como não estabilizada como suspeita.

Quando nenhum navegador puder ser acessado, escreva "não verificado visualmente", nomeie os estados que você pulou e não reivindique nada sobre a aparência da UI renderizada.

8. Relatório

Nomeie a direção e a razão para ela, forneça o bloco de tokens e liste cada verificação com seu comando e resultado. Liste o que não foi verificado.

Pisos (nunca troque estes por aparência)

• Contraste de texto de pelo menos 4,5:1. Texto grande (24px ou 18,66px negrito) e limites de UI ou indicadores de foco precisam de pelo menos 3:1.
• Cada elemento interativo tem um indicador de foco de teclado visível que difere do seu estado de hover.
• A cor nunca carrega significado por si só.
• Movimento respeita prefers-reduced-motion. Nada pisca mais de três vezes por segundo.
• O texto do corpo tem pelo menos 16px na web e 14px em UI de desktop densa. Nenhum texto abaixo de 12px.
• Todo estado existe: carregando, vazio, erro, desabilitado e dados parciais.
• Nenhum texto de placeholder é enviado. Erros dizem o que aconteceu e o que fazer em seguida.
• O texto sobrevive à string realista mais longa: traduções, CJK, caminhos longos e nomes de modelo.

Regras de gosto

• Um neutro dominante faz a maior parte do trabalho. Um acento cobre no máximo cerca de 10% da tela. Cores de sucesso, aviso e perigo permanecem fixas entre os temas.
• No máximo duas famílias tipográficas, mais uma face mono se necessário. Uma escala de proporção. A hierarquia vem de tamanho, peso, cor e espaço antes de caixas.
• Menos bordas e menos cartões aninhados. Raio de uma escala pequena. Sombras tingidas com a paleta, com no máximo três níveis de elevação.
• Movimento: um momento proposital por tela, transform e opacity apenas, e nenhuma animação em ações repetidas muitas vezes em uma sessão.
• Texto: letra inicial maiúscula em frases, verbos simples e o mesmo nome para uma ação no botão, na mensagem de resultado e no menu.

O teste da escolha

Cada padrão (fonte, paleta, raio, sombra, layout, conjunto de ícones) deve ser escolhido para este breve. Se você não puder nomear o motivo, mude-o. Um padrão que você escolheu não é um indício. references/anti-slop.md lista os indícios comuns e a regra do scanner que sinaliza cada um.

Arquivos

• references/principles.md: ordem de decisão, modelo de brief, recusas.
• references/directions.md: nove direções com tokens iniciais verificados.
• references/color-and-type.md: paletas, modo escuro, contraste, escala tipográfica, carregamento de fontes, CJK.
• references/layout-and-motion.md: grade, densidade, espaçamento, raios, elevação, movimento.
• references/components-and-states.md: componentes, matriz de estados, texto, teste de quebra.
• references/desktop-app.md: regras para WebView e aplicativos desktop.
• references/anti-slop.md: indícios, por que são lidos como padrões, perguntas a fazer, IDs de regras do scanner.
• references/critique.md: procedimento de revisão, nove pilares, gravidade, formato de saída.
• references/visual-review.md: como renderizar, capturar, ler e refazer o diff da UI.
• references/sources.md: de onde veio cada regra e o que foi deliberadamente não usado.
• scripts/wcag.py, scripts/design_lookup.py, scripts/slop_scan.py, scripts/visual_capture.py, scripts/image_diff.py: somente leitura, sem pacotes de terceiros, sem rede. Use py -3 se python não estiver no PATH.
• data/: dados CSV licenciados MIT, provenientes de ui-ux-pro-max (veja data/PROVENANCE.md).