MonoKelvin/mono-ui-prototype

Design de Protótipos de UI de Alta Qualidade

1. Objetivo Principal

Fazer tudo para criar interfaces de produto bonitas e, ao mesmo tempo, funcionais.

A entrega deve se parecer com um produto real feito por um designer experiente, e não com um protótipo genérico feito com modelos prontos, empilhamento de cartões ou troca de cores. O foco está na atmosfera geral, hierarquia visual, desempenho tipográfico, composição, relações de cores, linguagem gráfica, animações e riqueza de detalhes.

• Estética em primeiro lugar, sem sacrificar a usabilidade: O visual e a funcionalidade são projetados juntos; não se corta funcionalidades em troca de uma simplicidade superficial.
• O estilo é ditado pelo produto: Permita designs contidos, sofisticados, vibrantes, vanguardistas, elaborados ou experimentais. "Minimalismo elegante" não é a única resposta.
• Design autônomo e ousado: Não espere o usuário fornecer cores, fontes, layout e parâmetros de animação. Após entender os requisitos, explore proativamente soluções melhores.
• Rejeite a aparência de modelo: Não use layouts comuns de SaaS, paletas de cores fixas, cartões uniformes ou combinações de componentes padronizados como padrão.
• Derivação independente: Mesmo para a mesma categoria de produto, a expressão visual deve ser baseada em seu conteúdo e posicionamento, sem reutilizar mecanicamente o esquema visual da rodada anterior.

Princípios de Design de Referência

As decisões de design podem se basear nos seguintes princípios maduros, mas não os copie como exemplos ou os transforme em parâmetros fixos:

• Hierarquia visual, proporção, equilíbrio, contraste, Gestalt e ponto focal visual.
• Grade, composição, ritmo, espaço em branco, unidade e identidade de marca.
• Consistência, descoberta, divulgação progressiva, feedback e acessibilidade.
• Personalidade tipográfica, qualidade dos glifos, cenário de leitura e combinações de fontes.
• Continuidade de animação, aceleração/desaceleração natural, relações espaciais e feedback interativo.

Referências: Princípios de Design Visual do NNGroup · Princípios de Design de UI do Figma · IBM Design Language · Apple HIG Motion

Não Reutilize Páginas Existentes

• Para novas páginas, não leia, não tire screenshots, não analise páginas existentes em ui/ e não copie seu HTML/CSS/JS como ponto de partida.
• Não reutilize as cores, fontes, estrutura de layout, combinações de componentes e parâmetros de animação da rodada anterior. A diferença de design não pode ser apenas uma mudança de cor, texto ou imagem; a estrutura da informação e a expressão visual devem ser repensadas.
• É permitido apenas ler este skill, skills/ui-metadata/SKILL.md, as instruções de uso de tools/ e as referências fornecidas pelo usuário na sessão atual.
• Se o usuário solicitar explicitamente a modificação de uma página existente, leia apenas a página correspondente.

2. Entenda o Produto Primeiro, Depois Decida o Design

Antes de determinar a direção visual, avalie o posicionamento do produto, o público-alvo, o cenário de uso, as características do conteúdo e o temperamento da marca. Não trate a categorização abaixo como modelos; elas são apenas direções de design a serem exploradas:

Temperamento do Produto	Expressões de Design a Explorar
Internacional / Marca em Inglês	Texto conciso, fontes expressivas, tipografia em grande escala, kerning e espaço em branco, fotografia e simbolismo
Tendência / Criativo / Jovem	Composição ousada, fontes com forte personalidade, ícones e símbolos, formas geométricas, números visualizados e relações de cores flexíveis
Ferramenta Profissional / Software Desktop	Organização clara da informação, fontes refinadas, densidade de informação confortável, feedback de estado sutil e cores contidas
Tecnologia / IA / Produto de Dados	Fontes modernas, visualização de dados, gráficos estruturais, feedback dinâmico e visuais de tecnologia com identidade própria
Cultura / Arte / Marca de Conteúdo	Tipografia editorial, fontes com serifa ou especiais, fotografia, texturas, espaço em branco e cores com carga emocional
Consumo de Luxo / Estilo de Vida	Fontes refinadas, imagens de produto, textura e luz/sombra, detalhes táteis e expressão de marca contida, mas marcante

Você pode misturar diferentes direções ou propor uma direção original mais adequada ao produto atual. Não aplique mecanicamente um nome de estilo.

Contêiner de Entrega

Tipo	Critério de Decisão	Moldura Externa e Rolagem	Limite da Tela
A - Software	Backoffice, ferramenta, dashboard	Exibição em janela completa; rolagem local para listas longas e texto extenso	Bloqueado dentro da janela; sobreposições não ultrapassam
B - Web	Marca, landing page, site de conteúdo, portfólio	Fluxo de documento natural; rolagem vertical da página inteira	A viewport é a tela; sem limites fixos
C - App	Mobile-first, App/ celular / miniprograma explícito	Moldura na proporção do celular; rolagem apenas dentro da moldura	Bloqueado dentro da moldura do celular
D - Componente	Player, lightbox, campo de upload, etc.	Tamanho natural conforme o conteúdo; rolagem local interna	Bloqueado dentro do componente

Se o usuário especificar um tipo, siga-o. Caso contrário, deduza pela funcionalidade. O contêiner determina apenas o modo de exibição, não o estilo visual.

Pontos-Chave de Design do Contêiner

A - Software

• A janela, o fundo e o conteúdo devem formar uma relação de exibição completa; a moldura serve ao produto e não deve receber decoração extra para efeito de flutuação.
• Priorize a coexistência natural de informações principais e operações comuns; conteúdos complexos são acomodados por meio de zoneamento razoável e rolagem local.
• Primeiro, projete a alocação de espaço e o layout responsivo; depois, decida as áreas de rolagem. Não mascare problemas de layout com corte, ocultação da barra de rolagem ou redimensionamento geral.
• Em telas estreitas, priorize a reorganização, o agrupamento e o ajuste da apresentação da informação; não permita que funcionalidades principais desapareçam.
• A largura do software não deve exceder 85% da largura total da janela, e a altura não deve exceder 90%. Deixe espaçamento ao redor para centralizar.

B - Web

• Escolha entre narrativa de página longa, navegação modular, primeira tela imersiva ou outra estrutura adequada com base no conteúdo.
• A página deve ter ritmo visual e hierarquia de conteúdo. Evite repetir o mesmo layout em cada bloco.
• Animações acionadas por rolagem podem ser adicionadas conforme necessário para a narrativa; não force efeitos de rolagem apenas para cumprir regras.

C - App

• Use navegação adequada para dispositivos móveis, layout de coluna única ou adequado ao cenário e controles fáceis de operar.
• Personalize visualmente os controles nativos conforme necessário, mas não prejudique a acessibilidade e a experiência do usuário.
• As áreas de toque, a navegação inferior e a rolagem de conteúdo devem estar de acordo com os hábitos de uso em dispositivos móveis reais.
• Recomenda-se usar as dimensões de um iPhone para o design (não é necessário criar o Dynamic Island ou componentes de câmera frontal).

D - Componente

• O componente deve tomar forma naturalmente com base em sua finalidade e conteúdo, sem usar um invólucro de software completo.
• Foco no design dos estados: vazio, hover, foco, carregamento, conclusão e erro. Todas as mudanças de estado devem ser claras, coerentes e compreensíveis.

Os limites de sobreposição para as quatro categorias acima são padronizados na próxima seção.

Limites do Contêiner: Trave a Interface na Tela (Obrigatório para Software / App / Componente)

Isso é uma restrição rígida, não uma preferência de estilo. O limite da página web é a viewport do navegador. Software, App e Componentes têm seus próprios limites. Fora da tela, existe apenas o "palco" (fundo da plateia). Uma vez que diálogos, gavetas, máscaras e desfoques Gaussianos ultrapassam os limites da tela, a interface se degrada de "um software de verdade" para "uma captura de tela de página web" - esta é a falha mais comum nesse tipo de protótipo.

Estrutura de Três Camadas

O corpo do produto é colocado dentro do canvas, e o stage é responsável apenas por centralizar e fornecer o fundo. Nenhum elemento semântico do produto deve ser colocado no stage.

body > .stage          Palco: centralização + fundo, não contém conteúdo do produto
       └ .canvas       Tela: limite da interface do produto
          ├ Conteúdo do produto (barra de título / área principal / barra lateral …)
          └ .layer      Grupo de sobreposições: diálogos, gavetas, dropdowns, Toast
              ├ .scrim  Máscara: escurecimento + desfoque
              └ .dialog Corpo do diálogo

Propriedades-chave (pseudocódigo):

.canvas {
  position: relative;    /* Referência para posicionamento de sobreposições */
  contain: paint;        /* Recorte + faz com que descendentes com fixed se ancorem ao canvas, indispensável */
  overflow: hidden;      /* Corta todo conteúdo que ultrapassar */
  isolation: isolate;    /* Isola empilhamento e amostragem de fundo dentro do canvas */
  container-type: size;  /* Opcional: permite usar cqw/cqh internamente para dimensionamento */
  width: min(1440px, 100%);
  height: min(900px, calc(100svh - 2 * var(--stage-pad))); /* Se container-type for usado, altura/largura explícitas são obrigatórias */
}

.layer  { position: absolute; inset: 0; }              /* Referencia o canvas, nunca use fixed */
.scrim  { position: absolute; inset: 0;               /* Tamanho igual ao canvas → desfoque estritamente dentro do canvas */
          background: rgb(8 10 14 / .45); backdrop-filter: blur(10px); }
.dialog { position: relative; width: min(720px, 78cqw); max-height: 82cqh;
          display: flex; flex-direction: column; }
.dialog-body { flex: 1; min-height: 0; overflow: auto; }  /* Apenas a área de conteúdo rola */

Por que contain: paint Deve Ser Escrito Explicitamente

Testado (Edge, 1400×1200): Apenas com overflow: hidden, elementos position: fixed dentro do canvas ainda se posicionam em relação à viewport do navegador e escapam. Somente adicionando contain: paint (ou transform / filter / will-change: transform / contain: layout) é que o fixed se ancora ao canvas e é cortado. container-type: size sozinho não funciona; deve coexistir com contain: paint. Se cqw/cqh não for necessário, remova container-type.

Proibido

• Usar position: fixed para posicionar sobreposições dentro do canvas - o sistema de referência é a viewport, inerentemente transbordante.
• Usar vw / vh / dvh para dimensionar elementos dentro do canvas - unidades de viewport inevitavelmente rompem o canvas.
• Aplicar máscaras, desfoques ou sombras em elementos fora do canvas, como body, .stage ou outros.
• Usar transform: scale() para redimensionar todo o canvas para "encaixá-lo" na tela - texto, desfoque e sombras ficarão borrados. A abordagem correta é definir o tamanho com min() + adaptação interna.
• Permitir que o palco fora do canvas exiba conteúdo semântico do produto (texto explicativo, botões, gráficos decorativos não são permitidos).

Especificações de Tamanho de Diálogo (Obrigatório para Software)

Padrão paisagem: largura > altura. Diálogos de software devem priorizar o design widescreen.

Quantidade de Conteúdo	Orientação da Proporção	Tamanho Sugerido (relativo ao canvas)	Observação
Muito (tabelas, gráficos, formulários longos, editores)	Largura > Altura, usar 16:9 ou 4:3	Largura 60%–80% do canvas, altura não excede 75% do canvas	Priorizar 16:9, depois 4:3; necessário para layout lado a lado sem desperdiçar espaço horizontal
Médio (painéis de configuração, formulários com vários campos)	Largura > Altura	Largura 480–640px, altura 320–420px	Manter paisagem, sem ocupar toda a tela
Pouco (confirmação, campo único, dica)	Pode ser aproximadamente quadrado	Largura 320–420px, altura 220–320px	Vertical também é razoável; não forçar largura desnecessariamente
Lista vertical (lista longa, árvore, seletor)	Altura > Largura	Largura 320–400px, altura 60%–80% do canvas	Vertical é uma exceção permitida: listas únicas são naturalmente verticais
Workspace (agenda, kanban, editor em tela cheia)	Próximo ao tamanho total do canvas	Margem de 16–24px dentro do canvas	Ainda não é fixed, ainda está dentro do canvas

Ordem de decisão: Primeiro pergunte "o conteúdo precisa ser lado a lado?". Se precisar, ou se houver requisitos de legibilidade horizontal (tabelas, gráficos, código, linha do tempo) → Paisagem. Lista única / estrutura de árvore / formulário em etapas → Pode ser vertical.

Implementação: Use aspect-ratio para definir a proporção, max-height como fallback, largura com cqw, altura com cqh.

.dialog--wide   { width: min(72cqw, 860px); aspect-ratio: 16 / 9; max-height: 78cqh; }  /* Conteúdo abundante */
.dialog--panel  { width: min(56cqw, 680px); aspect-ratio: 4 / 3;  max-height: 78cqh; }  /* Conteúdo abundante e compacto */
.dialog--compact{ width: min(32cqw, 380px); aspect-ratio: 5 / 4; }                        /* Pouco conteúdo */
.dialog--tall   { width: min(30cqw, 360px); height: min(72cqh, 620px); }                   /* Lista vertical única */

Se o conteúdo for muito alto, max-height entra em ação e a proporção pode ser quebrada - isso é intencional: é melhor uma proporção ligeiramente diferente do que o conteúdo transbordar para fora do canvas.

Outras restrições:

• O diálogo deve ser centralizado dentro do canvas, com espaçamento mínimo de 24px em todos os lados; não deve tocar as bordas ou sair do canvas.
• Quando o conteúdo exceder, apenas .dialog-body deve rolar; o cabeçalho e o rodapé permanecem fixos.
• A máscara de escurecimento deve ter rgb(0 0 0 / .35) a rgb(0 0 0 / .5), com desfoque de 8–16px; o escopo da máscara deve ser estritamente igual ao canvas.
• Diálogos do mesmo software que aparecem em grupo devem ter tamanhos consistentes (mesmo tamanho para o mesmo tipo); não use um 16:9 e outro estreito e alto.

3. Processo de Design

Antes de começar, leia skills/ui-metadata/SKILL.md e escreva metadata.json no diretório da página de acordo com suas especificações.

0. Declaração de Fonte de Entrada de Imagem (imageToUI)

Quando o usuário usa "uma / várias imagens" como entrada de geração (ou seja, "criar UI a partir de imagem", "recriar a partir de imagem", "AI reconhece imagem e replica 1:1"), o campo imageToUI deve ser escrito em metadata.json para registrar a origem da imagem, permitindo que o cartão da galeria possa rastrear a imagem de referência original e clicar para visualizá-la. O tratamento depende do tipo de entrada:

• Se a entrada for uma URL de imagem (começando com http://, https:// ou //): escreva o link diretamente em imageToUI, por exemplo, "imageToUI": "https://dribbble.com/shots/15820088-Furniture-Board-Desktop-concept". A galeria renderizará um ícone de imagem, e clicar abrirá a fonte em uma nova guia.

• Se a entrada for uma codificação base64 ou um caminho de imagem local: O AI deve primeiro perguntar ao usuário uma das duas opções, e não pode processar silenciosamente:

  1. Fornecer o link de origem da imagem (recomendado para imagens de referência com fontes públicas, como links do Dribbble / Behance / arquivos de design); ou
  2. Permitir que o AI copie a imagem para o diretório ui/<slug>/assets/ como arquivamento da fonte (altamente recomendado - garante que a fonte seja rastreável, visível offline e publicada com o protótipo). Em seguida, escreva imageToUI como um caminho relativo, como "./assets/source-<slug>.png".

  ⚠️ Proibido escrever strings base64 ou caminhos absolutos locais diretamente em imageToUI: caminhos locais são inacessíveis no servidor da galeria e base64 não pode ser aberto pelo navegador; o ícone do cartão quebrará. Não escreva este campo até que o usuário tenha escolhido.

Regras de valor do campo (a galeria catalog.mjs analisa com base nisso; consulte skills/ui-metadata/SKILL.md para detalhes):

• Começa com http:// / https:// / // → tratado como link externo, redireciona ao clicar.
• Outro (./assets/..., assets/...) → tratado como recurso dentro do diretório do protótipo, resolvido como /prototypes/<slug>/... e abre a imagem em uma nova guia.
• Vazio / não escrito → o cartão não exibe o ícone.

1. Esclarecer a Tarefa de Design

Determine o posicionamento do produto, o cenário do usuário, as tarefas principais, a prioridade da informação e o foco da primeira tela. Prepare texto real e dados razoáveis primeiro; depois, projete a apresentação. Evite espaços reservados vazios.

2. Determinar a Direção Visual

Use uma breve descrição de design para esclarecer o temperamento desta página. Não é necessário preencher um formato fixo ou tabela de parâmetros. Pense pelo menos:

• Qual é a impressão visual geral e a personalidade da marca?
• Como a tipografia, composição e hierarquia da informação expressarão o conteúdo?
• Como as fontes estabelecerão personalidade e qualidade?
• Como as cores criarão atmosfera, identificação e pontos de destaque?
• Como ícones, gráficos, fotografia ou visualização de dados participarão da expressão?
• A animação pode melhorar a experiência e que linguagem de animação deve ser adotada?

3. Estabelecer um Sistema de Design

Com base nas necessidades da página atual, crie variáveis CSS e estilos reutilizáveis. Cores, fontes, tamanhos de fonte, espaçamento, bordas arredondadas, bordas, sombras e animações devem ter uma lógica de design consistente, mas não é obrigatório ter números, valores ou proporções fixas.

Não transforme o sistema de design em uma tabela de parâmetros que limite a criatividade. Ajustes flexíveis são permitidos, mas cada escolha deve servir ao efeito geral.

4. Foco do Design Visual

4.1 Tipografia e Composição

• Faça o usuário saber para onde olhar primeiro e, em seguida, entender naturalmente as outras informações.
• Use tamanho de fonte, peso da fonte, personalidade da fonte, cor, posição, espaço em branco e alinhamento para estabelecer hierarquia, sem depender de cartões e bordas empilhadas.
• Explore composição baseada em grade, assimétrica, deslocada, colunas, layout sobreposto, imersiva, editorial ou outras, de acordo com o conteúdo.
• Permita contrastes ousados de tamanho, quebras de linha especiais e tensão visual, mas o geral deve ser coordenado e legível.
• A página deve ter variação de densidade, peso e ritmo; evite que todas as áreas tenham a mesma intensidade.
• Não adote como padrão centralização, simetria, cartões de largura igual ou arranjos de blocos idênticos.
• O design visual deve ajudar o usuário a entender e concluir tarefas, e não apenas buscar uma boa captura de tela.

4.2 Relação entre Funcionalidade e Simplicidade

Funcionalidade completa e beleza visual devem ser alcançadas juntas. Simplicidade não significa remover funcionalidades.

• Forneça a capacidade completa que os usuários do segmento do produto razoavelmente esperam. Não remova funcionalidades arbitrariamente para tornar a página mais vazia, mais simples ou para uma melhor captura de tela.
• Primeiro, otimize a arquitetura da informação, o agrupamento de funcionalidades, a localização das entradas, o fluxo de interação e a expressão visual.
• Use divulgação progressiva, operações contextuais, atalhos, expressão por ícones, menus e gavetas para reduzir a carga visual.
• Funcionalidades de alta frequência devem ser fáceis de encontrar e operar; funcionalidades de baixa frequência podem ser recolhidas, mas não ocultadas sem motivo a ponto de serem difíceis de encontrar.
• Ícones podem reduzir o uso de texto, mas devem ser fáceis de entender; para operações importantes, mantenha rótulos de texto quando necessário.
• Considere remover funcionalidades apenas se o usuário solicitar explicitamente priorizar o minimalismo, remover funcionalidades redundantes, ou se uma determinada funcionalidade realmente não fizer parte do escopo do produto. Explique o motivo.
• As entradas de funcionalidades, estados e feedback devem ser completos; não crie controles que existam visualmente, mas não tenham resposta real.

4.3 Texto e Expressão da Informação

• A interface não é um manual de instruções. Se puder ser expresso de forma concisa, não escreva longas explicações, mas não perca informações necessárias para usar menos palavras.
• A interface não deve conter nenhum texto ou gráfico relacionado a "demonstração / protótipo / simulação": não escreva "modo de demonstração", "dados de exemplo", "dados Mock", "conta de teste", "isto é um protótipo"; não desenhe balões de anotação, setas de dica, marcadores de numeração, caixas de destaque de ensino; não use "diagrama esquemático", "imagem placeholder", "Lorem ipsum", "a aguardar preenchimento". Cada palavra e ícone na interface deve ser algo que o produto real teria.
• Projete o protótipo como se fosse a interface de um produto em produção: o texto deve se parecer com dados reais de negócios, os gráficos devem ter relações de valores confiáveis, os estados vazios devem escrever o próprio texto de orientação do produto, e as mensagens de erro devem descrever situações que o usuário realmente encontrará. Para partes que não podem ser implementadas (interfaces de servidor), explique na descrição da entrega, não as escreva na interface.
• Para marcas internacionais ou páginas em inglês, use palavras concisas, rótulos curtos, texto em tamanho grande e símbolos visuais.
• Páginas de tendência ou criativas podem usar mais ícones, símbolos, gráficos e números visualizados; ferramentas profissionais devem priorizar a clareza das informações.
• A expressão em chinês deve ser natural e precisa; não force o uso de inglês ou abreviações sem sentido para decoração.
• O texto deve ser específico e informativo, evitando palavras de marketing vazias, títulos repetidos e auto-descrições.
• Para status, tendências, fluxos, classificações e proporções, escolha ícones, gráficos, diagramas estruturais ou texto com base no custo de compreensão; não force um único método de expressão.

4.4 Design Tipográfico (Foco)

Não use a fonte padrão do sistema como solução final. Exceto para texto longo de corpo, informações densas ou cenários com prioridade de leitura, escolha fontes ativamente.

• Quando um toque de sofisticação / design / marca for necessário, procure ativamente fontes display ou combinações de fontes; não use a fonte padrão.
• Títulos, logotipos de texto, números-chave, corpo do texto e informações auxiliares podem ter personalidades diferentes, mas a combinação deve ser harmoniosa; não use muitas fontes diferentes.
• Inglês: Sans-serif geométrico, Sans-serif humanista, Grotesk, Serifa, fontes estreitas/largas, Display, manuscritas, experimentais - escolha com base no temperamento; não use Inter como padrão.
• Chinês: Hei Ti moderno (sans-serif), Song Ti / Serifa, Yuan Ti (arredondado), caligráficas, display com características especiais. Fontes display são apenas para títulos curtos; priorize a legibilidade para texto longo.
• Números: linha de base, altura do glifo, largura e alinhamento devem ser consistentes; não use fontes artísticas com larguras irregulares.
• Peso da fonte, largura da fonte, kerning, maiúsculas/minúsculas, itálico e quebras de linha podem criar design; não dependa apenas de trocar o nome da fonte.
• Tamanho mínimo de fonte padrão: 12px (limite inferior, não uma regra fixa); para logotipos pequenos / texto embutido em gráficos, pode ser ajustado conforme necessário. Para layout, use quebra de linha adaptável à largura; não force quebras de linha.

Para fontes, referências CDN e tratamento de carregamento lento, consulte a Seção 6 "Tipografia [Nota: Esta seção não existe mais; as diretrizes estão aqui no skill]".

4.5 Design de Cores

Não use um conjunto fixo de valores de cor, proporções de cor ou cor de destaque. Primeiro, avalie o temperamento do produto; depois, explore com ousadia as relações de cores adequadas.

Considere tons de cinza sofisticados, cores neutras, cores de baixa saturação, cores naturais, contraste frio/quente, cores de marca, contrastes vibrantes, luxo escuro, sistemas monocromáticos, etc. As cores podem ser contidas ou vibrantes; o importante é a harmonia, hierarquia, reconhecimento e expressão emocional.

Cores frias como verde fosco, verde-água e azul fosco não devem ser priorizadas na exploração de cores - a maioria das interfaces feitas por IA hoje em dia usa esse esquema, é muito fácil parecer igual. Deixe-as como último recurso.

• As cores devem ter funções claras, estabelecendo uma relação clara entre fundo, conteúdo, texto, destaques e estado.
• A cor de destaque não precisa ser fixa; escolha com base na marca e no conteúdo da página.
• Gradientes, transparência, texturas e luz/sombra podem ser usados, mas devem ter um propósito de design. Não trate gradientes, brilho ou efeito glass como sinônimos de sofisticação.
• O contraste de cores deve garantir que o texto e os controles importantes sejam identificáveis; não sacrifique a legibilidade por atmosfera.
• Não deixe a página sem foco, hierarquia e vitalidade em busca de baixa saturação ou cinza sofisticado.

4.6 Ícones, Gráficos e Imagens

• Ícones, símbolos, formas geométricas, ilustrações, fotografia e visualização de dados podem ser a principal linguagem visual; não se limite a texto e cartões.
• Escolha o estilo gráfico com base no temperamento do produto, garantindo que linhas, proporções, texturas e métodos de expressão sejam harmoniosos.
• Ícones funcionais priorizam o reconhecimento; gráficos de marca ou criativos podem ter mais personalidade.
• Não misture bibliotecas de ícones com estilos visivelmente diferentes; não use emojis como ícones funcionais oficiais.
• Os gráficos devem ter um propósito expressivo: ajudar na identificação, explicar relações, transmitir estado, moldar a marca ou aumentar a tensão visual.
• As imagens devem ter composição, cor e lógica de conteúdo claras; evite colagens aleatórias ou materiais irrelevantes para preencher espaços.

4.7 Detalhes e Acabamento

• Preste atenção à renderização de fontes, kerning, alinhamento, bordas, proporção de ícones, hierarquia, estados de interação e detalhes de conteúdo.
• Use bordas, linhas de separação, sombras, bordas arredondadas, texturas e efeitos de transparência conforme necessário; não decore por decorar.
• Mantenha a consistência entre os componentes, mas também permita diferenças visuais razoáveis em áreas-chave.
• A página não pode ter apenas a primeira tela refinada; as áreas de rolagem, pop-ups, menus, estados vazios e de erro também devem ser completamente projetados.
• Não sacrifique a legibilidade, operabilidade e velocidade de resposta em uso real para parecer "uma screenshot de design".

4.8 Bordas Não Podem Ser Cortadas (Leitura Obrigatória para Contêineres de Corte)

Ao colocar um componente com borda em um contêiner pai que corta o conteúdo, o preenchimento interno do contêiner pai deve ser ≥ a largura máxima da borda em todos os estados do componente. Caso contrário, a borda será cortada e a falta de limite será interpretada como "renderização quebrada".

Mecanismo

overflow: hidden corta com base na padding box do contêiner:

• O preenchimento interno do contêiner pode absorver o transbordamento do elemento filho → preenchimento interno suficiente expõe a borda;
• Mas box-shadow para fora e outline são desenhados fora da border box, e o preenchimento interno não pode salvá-los.

Soluções (por Prioridade)

1. box-sizing: border-box global (preferido) — elimina o transbordamento na raiz:

*, *::before, *::after { box-sizing: border-box; }

2. Deixe margem de borda no contêiner pai — padding ≥ largura da borda + 1px. Testado: com borda de 4px, padding ≤ 6px corta a borda direita, ≥ 7px está completo; exatamente igual à largura da borda de 4px ainda será cortado, certifique-se de deixar margem.

3. Use sombra interna (inset) para substituir a borda — não ocupa espaço, nunca é cortada:

.card { border: 0; box-shadow: inset 0 0 0 1px var(--line); }

Proibido

• Usar box-shadow para fora / outline como borda permanente (desenhado fora da border box, cortado instantaneamente);
• Usar margem negativa para mesclar bordas adjacentes (será cortado na presença de corte).

Quando a Borda Aparece Apenas no Hover

Cenário mais comum: estado normal OK, mas ao passar o mouse, a borda aparece cortada. Use borda transparente como espaço reservado, alterne apenas a cor, sem salto ou transbordamento:

.item { border: 1px solid transparent; transition: border-color .18s; }
.item:hover { border-color: var(--line); }

Verifique componente por componente, consulte a Seção 9, Item de Autoverificação 13.

4.9 Uniformizar o Estilo dos Controles Nativos

Os controles nativos do navegador (barras de rolagem, dropdown select, estado de foco de input / textarea, cor de destaque de checkbox / radio / range, seletores de data, etc.) são renderizados pelo sistema e têm aparência diferente da UI personalizada. Esta é a falha mais facilmente ignorada e que mais quebra a coesão visual. Todos os controles nativos que aparecem na página devem ser integrados à linguagem visual do produto, sem manter a aparência padrão do sistema.

• Barras de rolagem: Use a série ::-webkit-scrollbar* para WebKit e scrollbar-width / scrollbar-color para Firefox para uniformizar a cor, borda arredondada e estado de hover da trilha e do polegar. Aplique apenas em áreas de rolagem locais; largura contida (cerca de 8–10px), não engrosse globalmente.
• Campos de entrada: Use appearance: none para input / textarea / select e desenhe bordas, cantos arredondados e estado de foco focus-visible personalizados. Não use a borda padrão do navegador e a sombra interna.
• Dropdown select: O painel option nativo não pode ser profundamente personalizado. Use appearance: none + desenhe a seta de expansão e use variáveis --control-* para manter a consistência com botões e campos de entrada. Se precisar de pesquisa, agrupamento, destaque personalizado, substitua o select nativo por um dropdown personalizado.
• Cor de destaque: Use accent-color: var(--brand) para checkbox / radio / range / progress; não mantenha o azul padrão do sistema.
• Entradas compostas: Painéis de cor, data, hora, etc., não podem ser personalizados. Para produtos importantes, substitua por entrada personalizada ou formato de entrada restrito.

Pontos-chave: Incorpore o preenchimento interno, tamanho da fonte, borda arredondada e estado de foco de todos os controles nativos em variáveis de design (por exemplo, --control-bg / --control-border / --control-radius / --control-focus), mantendo o mesmo conjunto visual de cartões e botões. Elimine a "linguagem dupla".

5. Design e Implementação de Animação

A animação é parte do design da UI, não apenas adicionar um efeito de hover a um botão. Com base no temperamento do produto e nas necessidades do usuário, decida proativamente o papel da animação na interface.

5.1 Primeiro, Avalie a Necessidade de Animação

• Se o usuário explicitamente pedir animação excelente, efeitos de alta qualidade, animação suave, legal, extravagante, imersiva, cinematográfica, visual dinâmico ou requisitos semelhantes, trate a animação como um elemento central do design. Use ativamente bibliotecas de animação profissionais como GSAP para implementar efeitos complexos; não use apenas transições CSS simples.
• Para sites de marca, vitrines criativas, lançamentos de produtos, portfólios, narrativas interativas e outras páginas adequadas para expressão dinâmica, projete ativamente entradas rítmicas, narrativa acionada por rolagem, parallax, animação de texto, transformação de gráficos, revelação de máscara, movimento em camadas e transições contínuas.
• Para ferramentas profissionais, backoffice e interfaces com operações de alta frequência, a animação deve ajudar a entender o estado, estabelecer relações espaciais e fornecer feedback; pode ser refinada e suave, mas não pode prejudicar a eficiência.
• Se o usuário não solicitar animações complexas explicitamente, projete com moderação com base no temperamento do produto; não adicione efeitos sem sentido apenas para mostrar habilidade.
• Não transforme todos os elementos no mesmo fade-in com movimento para cima; também não deixe cada componente agir independentemente.

5.2 Qualidade da Animação

• Evite movimento linear mecânico: Movimento espacial, dimensionamento e transições de interface geralmente usam aceleração, desaceleração, easing assimétrico ou efeitos de mola naturais. Linear é adequado apenas para rotação uniforme, progresso, rolagem contínua ou outros cenários específicos.
• Use easing de qualidade: Escolha curvas como ease-out, ease-in-out, power, expo, back, spring com base na distância do movimento, sensação de massa do elemento e cenário. Seja contido com elasticidade exagerada; evite saltos repetitivos de baixa qualidade.
• Adicione sensação de amortecimento (damping) quando apropriado: Painéis grandes, sobreposições, arrastar, seguir, efeito magnético e transições espaciais podem ter inércia, amortecimento, ressalto (bounce) ou sensação de mola para tornar o movimento mais natural.
• O movimento deve ter causa e efeito: Entrada, saída, expansão, recolhimento, alternância, arrasto e mudanças de estado devem estar de acordo com a intuição do usuário sobre espaço e objetos.
• A coreografia deve ter ritmo: Use escalonamento, sobreposição, conexão sequencial e movimento em camadas, mas deve haver hierarquia; não deixe todos os elementos se moverem caoticamente ao mesmo tempo.
• A animação deve responder ao conteúdo e à operação: Evite loops infinitos sem sentido, flutuação contínua e animações de fundo que roubam a atenção.
• Priorize o desempenho: Use propriedades como transform e opacity que são adequadas para composição (compositing). Use filtros complexos, desfoque e efeitos em tempo real em grande área com cuidado para evitar quedas de quadros.

5.3 Priorize o Uso de gsap-skills e GSAP

Antes de fazer animações GSAP, verifique: Se o sistema/agente atual já tiver o skill gsap-skills instalado, tente usá-lo para obter a API e a sintaxe mais recentes para o design da animação; se não estiver instalado, peça ativamente a confirmação do usuário e recomende a execução de npx skills add https://github.com/greensock/gsap-skills (a decisão de instalar é do usuário). Instale antes de usar para o design da animação. Não confie na memória para escrever usos desatualizados do GSAP.

Animações complexas (narrativa de entrada, acionada por rolagem, coreografia de timeline, interação de arrasto, coordenação de múltiplos elementos) devem priorizar o GSAP:

• Use Timeline para coreografar um grupo de animações (rótulos, sobreposição, aninhamento, callbacks) de forma unificada; não dependa de um monte de delays não relacionados.
• Use ScrollTrigger para animações acionadas por rolagem; importe plug-ins conforme necessário para scroll suave, palavra por palavra, caminho, flip, etc.
• Use transições CSS / keyframes para feedback de estado simples; não importe uma biblioteca apenas para usá-la.
• Importe via CDN (por exemplo, gsap@3), seguindo as convenções técnicas da Seção 8; gerencie as animações de forma modular para facilitar a reprodução/pausa/inversão/redefinição/limpeza.

5.4 Operação Contínua, Interrupção e Retomada

As animações interativas devem considerar a operação contínua do usuário: quando uma nova operação chegar, faça a transição natural do estado visual atual, sem piscar, sem saltar para a posição inicial e sem permitir que o estado da animação se desconecte da UI real.

• Estados reversíveis (expandir/recolher, ligar/desligar): Reutilize o mesmo Timeline; use reverse() / play() para inverter naturalmente, sem recriar.
• Valor alvo de mudança contínua (arrastar, seguir cursor): Use gsap.quickTo() para que o movimento sempre siga a entrada mais recente; não crie uma nova tween a cada vez.
• Conexão de múltiplas sequências: Use Timeline / Timeline aninhado / callbacks / máquina de estados para gerenciar de forma unificada; não crie animações independentes que competem pelas mesmas propriedades.
• Diferencie semanticamente entre "continuar sequência / reproduzir inversamente / redirecionar para novo alvo / animar outras propriedades em paralelo"; não adicione ou termine tudo indiscriminadamente. Substitua apenas as propriedades que estão realmente em conflito (GSAP usa overwrite: "auto"; não use kill() aleatoriamente ou overwrite: true globalmente).

5.5 Acessibilidade e Desempenho

• Respeite prefers-reduced-motion: reduce; forneça uma solução para reduzir os efeitos dinâmicos. Ao reduzir a animação, as informações e funcionalidades ainda devem estar completas.
• Não use animação para ocultar conteúdo importante ou atrasar informações que o usuário deve obter imediatamente.
• Evite cintilação de alta frequência, redimensionamento rápido e grande escala, e parallax que pode causar desconforto.
• As animações de rolagem não podem afetar a rolagem normal, a operação do teclado e a operação por toque.
• Quando a página for deixada ou o componente for destruído, limpe corretamente os listeners de eventos, ScrollTrigger e instâncias de animação que não são mais necessárias.
• O conteúdo importante da primeira tela não pode depender do carregamento da biblioteca de animação para ser exibido.

Referências:

• Documentação do GSAP
• Timeline do GSAP
• GSAP Tween / overwrite
• Apple HIG Motion
• Material Motion

6. Recursos

Use tools/resource-getter/get.py para obter todos os recursos de forma unificada. Não construa URLs de sites manualmente e não espalhe links externos de fontes desconhecidas pela página. Consulte tools/resource-getter/README.md para a matriz completa de fontes, licenças e solução de problemas.

Prioridade de Seleção

1. Ilustrações vetoriais transparentes: unDraw / Storyset / DiceBear / Doodle Ipsum
2. PNG com fundo removido: Pixabay (--transparent) / pngimg
3. Fotografia: Pixabay / Picsum / Unsplash / Pexels
4. SVG desenhado à mão (geométrico, decorativo, gráficos)
5. Imagens geradas por IA (último recurso; regras abaixo)

Use hotlinking por padrão, baixe se for lento. O modo auto do get mede o TTFB: se > 0,9s ou leitura > 2,5s, considere lento e baixe para ui/<page>/assets/; mesmo que seja rápido, não coloque vinte imagens remotas grandes na primeira tela.

... [Nota: O restante do conteúdo do SKILL.md original foi truncado. A tradução continuaria da mesma forma para as seções restantes.]