UI Base

Quando Usar

Use esta habilidade quando precisar agilizar o código de UI corrigindo espaçamento, hierarquia, tipografia e pequenos problemas de layout. Use quando a interface precisar de uma limpeza rápida ou um polimento.

Aplica uma base opinativa para um polimento focado. O design do produto existente, os requisitos de acessibilidade, as escolhas de framework e as preferências explícitas do usuário têm precedência; não migre a pilha ou adicione dependências apenas para satisfazer esta lista.

Como Usar

• /baseline-ui Aplique estas restrições a qualquer trabalho de UI nesta conversa.

• /baseline-ui <file> Revise o arquivo contra todas as restrições abaixo e gere:

  • violações (cite a linha/trecho exato)
  • por que importa (1 frase curta)
  • uma correção concreta (sugestão em nível de código)

Pilha

• DEVE usar os padrões do Tailwind CSS, a menos que valores personalizados já existam ou sejam explicitamente solicitados
• DEVE usar motion/react (anteriormente framer-motion) quando animação JavaScript for necessária
• DEVE usar tw-animate-css para animações de entrada e micro-animações no Tailwind CSS
• DEVE usar a utilidade cn (clsx + tailwind-merge) para lógica de classes

Componentes

• DEVE usar primitivas de componentes acessíveis para qualquer coisa com comportamento de teclado ou foco (Base UI, React Aria, Radix)
• DEVE usar as primitivas de componentes existentes do projeto primeiro
• NUNCA misture sistemas primitivos dentro da mesma superfície de interação
• DEVE preferir Base UI para novas primitivas, se compatível com a pilha
• DEVE adicionar um aria-label a botões apenas com ícone
• NUNCA reconstrua o comportamento de teclado ou foco manualmente, a menos que explicitamente solicitado

Interação

• DEVE usar um AlertDialog para ações destrutivas ou irreversíveis
• DEVE usar esqueletos estruturais para estados de carregamento
• NUNCA use h-screen, use h-dvh
• DEVE respeitar safe-area-inset para elementos fixos
• DEVE mostrar erros próximos a onde a ação acontece
• NUNCA bloqueie a colagem em elementos input ou textarea

Animação

• NUNCA adicione animação, a menos que seja explicitamente solicitada
• DEVE animar apenas props do compositor (transform, opacity)
• NUNCA anime propriedades de layout (width, height, top, left, margin, padding)
• DEVE evitar animar propriedades de pintura (background, color), exceto para UI pequena e local (texto, ícones)
• DEVE usar ease-out na entrada
• NUNCA exceda 200ms para feedback de interação
• DEVE pausar animações em loop quando fora de tela
• DEVE respeitar prefers-reduced-motion
• NUNCA introduza curvas de easing personalizadas, a menos que explicitamente solicitadas
• DEVE evitar animar imagens grandes ou superfícies de tela cheia

Tipografia

• DEVE usar text-balance para títulos e text-pretty para corpo/parágrafos
• DEVE usar tabular-nums para dados
• DEVE usar truncate ou line-clamp para UI densa
• NUNCA modifique letter-spacing (tracking-*), a menos que explicitamente solicitado

Layout

• DEVE usar uma escala de z-index fixa (sem z-* arbitrários)
• DEVE usar size-* para elementos quadrados em vez de w-* + h-*

Performance

• NUNCA anime superfícies grandes de blur() ou backdrop-filter
• NUNCA aplique will-change fora de uma animação ativa
• NUNCA use useEffect para qualquer coisa que possa ser expressa como lógica de renderização

Design

• NUNCA use gradientes, a menos que explicitamente solicitados
• NUNCA use gradientes roxos ou multicoloridos
• NUNCA use efeitos de brilho como affordances primárias
• DEVE usar a escala de sombra padrão do Tailwind CSS, a menos que explicitamente solicitada
• DEVE dar aos estados vazios uma única ação clara
• DEVE limitar o uso de cores de destaque a uma por visualização
• DEVE usar o tema existente ou tokens de cores do Tailwind CSS antes de introduzir novos

Exemplo

Solicitação do usuário:

Revise esta interface com @baseline-ui, identifique os problemas de design de maior impacto e proponha uma melhoria pronta para implementação.

Limitações

• Use esta habilidade apenas quando a tarefa corresponder claramente à sua fonte upstream e ao contexto do projeto local.
• Verifique comandos, código gerado, dependências, credenciais e comportamento de serviços externos antes de aplicar alterações.
• Não trate exemplos como substitutos para testes específicos do ambiente, revisão de segurança ou aprovação do usuário para ações destrutivas ou custosas.