Auditoria de UI de template (stock UI audit)
Interfaces geradas ou de starter-kit compartilham uma aparência reconhecível: um acento índigo ou violeta, um gradiente hero roxo-para-azul, Inter em todo lugar, cartões foscos, emoji no navegador. Nada disso é errado por si só. O problema é uma escolha que veio com o template, não do produto. Esta skill encontra essas escolhas com um scanner estático e, em seguida, as classifica por julgamento. O scanner produz candidatos; apenas a triagem produz achados.
Esta skill remove padrões não escolhidos. Ela não inventa uma marca. Se o produto ainda não tem direção visual, diga isso e peça uma, em vez de substituir um padrão por outro.
Antes de escanear
- Leia o briefing, os tokens de design e a configuração do tema ou da biblioteca de componentes. Anote cada cor, fonte e componente que o produto pediu. Eles permanecem, mesmo quando o scanner os sinaliza.
- Defina o modo a partir da solicitação:
- Revisão: relate apenas achados. Não edite nada.
- Limpeza: corrija achados confirmados, e apenas dentro da área que o usuário nomeou (uma página, uma pasta de componentes, todo o aplicativo). Relate qualquer coisa que notar fora dela, em vez de corrigir.
- Escolha o escopo da varredura: as pastas de origem que renderizam a UI, não todo o repositório.
Execute o scanner
bun <caminho do diretório desta skill>/scripts/scan.mjs [--json] [--fail-on high|medium|low] <caminhos>...
Node 22 ou superior também funciona. Ele percorre diretórios, pula dependências, saída de build e cobertura, além de arquivos minificados, e lê .html .css .scss .js .ts .jsx .tsx .vue .svelte .astro. Ele imprime o número de arquivos escaneados. Código de saída 0 significa que nada atingiu a severidade de falha (alta por padrão), 1 significa que algo atingiu, 2 significa uso incorreto ou zero arquivos escaneados. Um código 2 nunca é um resultado limpo. Passe --fail-on medium quando acentos violeta, uma única fonte padrão ou ícones emoji devam causar falha na execução. Não adicione o scanner como uma porta de CI a menos que solicitado.
| Regra | Severidade | Captura |
|---|---|---|
purple-blue-gradient | alta | gradientes cujos pontos de parada são todos matizes frios com pelo menos um violeta, em CSS ou classes Tailwind from-/to- |
violet-accent | média | qualquer token hex, rgb, hsl, oklch ou HSL puro cujo matiz calculado esteja na faixa índigo a violeta, mais classes Tailwind indigo/violeta/roxo |
gradient-text | média | background-clip: text e bg-clip-text |
single-stock-font | média | uma fonte sem serifa padrão (Inter, Roboto, Poppins e similares) como o único tipo nomeado em duas ou mais declarações no conjunto escaneado |
emoji-icon | média | emoji dentro de títulos, botões, links, itens de navegação ou campos icon/label/title |
neon-glow | média | sombras com deslocamento zero, desfoque amplo em uma cor saturada, e sombras coloridas do Tailwind |
frosted-glass | baixa | backdrop-filter: blur() e backdrop-blur |
library-default-token | baixa | primários padrão não modificados do Bootstrap, Material, MUI, Ant Design, Chakra, shadcn/ui e do starter Vite |
tracked-caps | baixa | texto maiúsculo com espaçamento entre letras amplo |
A regra de fonte verifica todos os arquivos em uma única execução, portanto escaneie todo o escopo da UI junto; escanear um arquivo por vez a oculta.
Faça a triagem de cada correspondência
Abra cada linha sinalizada e leia o suficiente ao redor para entender para que serve o elemento. Atribua a cada correspondência exatamente um veredito:
- Padrão não escolhido: nada no briefing, tokens ou histórico pede por isso, e parece um starter template. Isso é um achado.
- Escolha deliberada: o briefing, um arquivo de token, um guia de marca ou uma mensagem de commit mostra que alguém escolheu. Mantenha e nomeie a evidência.
- Falso positivo: a correspondência não está fazendo o que a regra assume, como um matiz violeta em um tema de syntax highlighting, um desfoque em um fundo modal sobre conteúdo denso, ou um emoji dentro de dados de amostra gerados pelo usuário. Deixe como está e diga o porquê.
- Não resolvido: você não consegue dizer se alguém escolheu. Não é um achado e você não muda nada. Relate o que está faltando e a pergunta que resolveria.
Corrigindo o que é real
- Corrija a causa, não a linha. Cinco hex violeta geralmente significam um token de acento ausente; defina a paleta do produto e o tipo uma vez e aponte os componentes para ela.
- Escolha substituições que sirvam ao conteúdo: contraste que se sustente, um acento que marque a única ação que importa, um tipo adequado à carga de leitura.
- Nunca ajuste um valor apenas para sair do alcance do scanner, como deslocar um matiz alguns graus ou trocar um hex por um
oklch()equivalente. Se a cor está errada, mude-a; se está certa, mantenha-a e registre o motivo. - Nunca mude uma cor de marca, uma cor de status (sucesso, aviso, erro) ou um indicador de foco para fazer a varredura passar. Elas carregam significado; registre-as como deliberadas.
- Substitua ícones emoji pelo conjunto de ícones existente no projeto. Adicione uma nova dependência de ícones apenas se o usuário concordar.
O que o scanner não pode ver
Verifique estes lendo a página renderizada, já que nenhuma correspondência de padrão os encontra:
- toda seção construída com o mesmo título centralizado, subtítulo e dois botões
- uma grade de três cards com um ícone, título e linha de texto em cada card
- um pequeno badge ou pill acima do título principal
- cards marcados por uma borda esquerda grossa colorida
- um banner de estatísticas com números grandes ("10k+ usuários", "99,9% de disponibilidade")
- seções numeradas "1, 2, 3"
- um tema escuro forçado sem opção clara solicitada no briefing
- o mesmo raio de borda grande e sombra suave em todas as superfícies
- espaçamento e tamanhos de tipo que ignoram a escala do projeto
- texto que poderia descrever qualquer produto
Verifique
- Reexecute o scanner no mesmo escopo e confirme que cada correspondência restante tem um veredito registrado.
- Olhe a UI renderizada nos tamanhos relevantes (uma largura estreita de telefone e uma largura de desktop, no mínimo), em cada tema que o produto oferece.
- Uma varredura limpa não diz nada sobre acessibilidade, layout ou qualidade geral. Verifique contraste e estados de foco em tudo que você alterou.
Se você não conseguiu renderizar a UI, diga que a revisão foi apenas estática.
Relatório
Escreva o relatório nesta ordem:
- Escopo escaneado, arquivos escaneados, modo e o código de saída do scanner.
- Achados corrigidos (ou, no modo revisão, propostos), cada um com
arquivo:linha, a regra e o que o substituiu. - Correspondências mantidas como deliberadas, cada uma com sua evidência.
- Correspondências não resolvidas, cada uma com o que está faltando e a pergunta que a resolve.
- Falsos positivos, cada um com uma linha sobre o motivo.
- Problemas que o scanner não pode ver, se você encontrou algum.
- Como você verificou: resultado da reexecução, tamanhos e temas visualizados, ou "apenas estático".