Impeccable: 62 regras determinísticas contra o slop de IA

Páginas construídas por um modelo têm um jeito inconfundível. Você já viu: Inter em tudo, um gradiente de roxo para azul no hero, cards dentro de cards, texto cinza sobre fundo colorido e um bloco de ícone quadrado de cantos arredondados flutuando acima de cada título. Paul Bakaus deu nome a esse jeito e depois escreveu um linter para caçá-lo.

Impeccable é uma skill de design para agentes de programação. Ganhou cerca de 6.700 estrelas nesta semana e está na casa das 91.500 no total. O slogan — «o vocabulário de design para o seu agente de programação» — subestima justamente a parte incomum: 62 das suas verificações rodam como regras determinísticas, sem nenhum modelo envolvido.

O que é, na prática

Uma skill, 24 comandos e um detector. Começou como extensão da skill frontend-design da Anthropic e cresceu até ter opiniões próprias.

A instalação é um único comando na raiz do projeto:

npx impeccable install
/impeccable init

O segundo passo é o que as pessoas pulam. O init entrevista você sobre o produto — público, propósito, restrições, tom — e grava as respostas em PRODUCT.md. Um comando document separado gera o DESIGN.md a partir do código que já existe. A separação importa: fatos de produto e sistema visual são artefatos diferentes, que mudam em ritmos diferentes, e juntá-los num arquivo só é o caminho mais curto para um documento de design encalhado.

Depois vêm os 24 comandos. São mais um vocabulário do que um fluxo de trabalho:

craft roda a sequência completa de dar forma e depois construir, com iteração visual. critique revisa hierarquia, clareza e registro emocional. audit verifica acessibilidade, performance e responsividade. polish alinha ao design system antes do lançamento. bolder e quieter são ajustes de direção — amplificar ou conter. harden cuida de estados de erro, i18n, estouro de texto e casos de borda. typeset e layout corrigem as duas coisas que interfaces geradas por agente mais erram. live abre um navegador e gera variantes de um elemento indicado, ali mesmo.

Qualquer um deles pode ser fixado como atalho independente:

/impeccable pin audit

O que cria /audit como comando de primeiro nível. Recurso pequeno, diferença grande em se o vocabulário é realmente usado.

O detector é a engenharia interessante

É aqui que Impeccable se separa da pilha de repositórios que são só coletâneas de prompts: as 62 regras não precisam de modelo, de chave de API nem de agente.

npx impeccable detect src/
npx impeccable detect index.html
npx impeccable detect --json .
npx impeccable detect --list-rules

Ou seja, roda em CI. Um pull request que reintroduz easing com quique, ou um gradiente roxo perdido, ou uma legenda cinza de 14px sobre verde-água pode reprovar na checagem sem que ninguém pague tokens. Há uma flag --github que emite anotações do GitHub Actions, e esse é o único detalhe de integração que importa para a maioria dos times.

O conjunto de regras tem opinião, tanta que vai incomodar, e a documentação assume isso. A lista de antipadrões proíbe Arial, Inter e fontes padrão do sistema; proíbe preto puro e cinza puro (sempre com matiz); proíbe card em volta de tudo e card dentro de card; proíbe easings de quique e elásticos por serem datados; proíbe texto cinza sobre fundos coloridos.

Alguns desses pontos são argumentos de ofício defensáveis. Um parágrafo com contraste insuficiente sobre fundo saturado é uma falha de acessibilidade que, de quebra, parece barato. A proibição do Inter é moda, e regra de moda envelhece mal — o mesmo documento que proíbe Inter vai parecer peça de época em três anos. Mas um linter sem opinião é só um formatador, e o ponto deste aqui é ter posição.

Como é determinístico, também é burlável. Qualquer time que queira entregar o gradiente roxo pode adicionar uma isenção inline:

<!-- impeccable-disable overused-font: exported brand doc -->

Ou gerenciar as exceções globalmente com npx impeccable ignores add-value overused-font Inter --reason "Brand font". A flag --reason faz um trabalho social silencioso: torna a exceção visível no diff.

Como ele se acopla ao agente

O caminho de instalação escolhido determina o quanto isso fica invasivo. Para Claude Code, Copilot, Codex, Cursor e Grok Build, o install grava um manifesto de hooks nativo de cada provedor. No Claude Code é .claude/settings.local.json, ignorado pelo git e local à máquina. No Copilot é .github/hooks/impeccable.json, versionado e compartilhado com os agentes na nuvem. No Cursor é .cursor/hooks.json, disparado no postToolUse quando um arquivo é gravado.

O efeito é que o detector roda sobre as próprias edições do agente e devolve os achados para o loop dele. É um mecanismo bastante diferente de «rodar o comando de auditoria quando você lembrar». Ele pega a preguiça no momento da geração, não na revisão.

O custo é o de sempre: hooks que escrevem na configuração do repositório são hooks que aparecem na revisão de código, e quem usa Codex precisa aprovar explicitamente os hooks do projeto via /hooks depois de instalar. Se o seu time tem opiniões fortes sobre configuração de ferramenta versionada, o caminho do submódulo existe exatamente por isso — git submodule add mais npx impeccable link --source=.impeccable --providers=claude,cursor mantém a ferramenta versionada ao lado do código que ela governa.

O que ele não conserta

Três limites que vale nomear.

Ele não consegue dizer se a página é boa. As 62 regras capturam sinais de superfície. Uma página pode passar em todas e continuar sem ponto de vista, que é a versão profunda do problema do slop de IA e a que nenhum linter resolveu.

O modo live só funciona em um checkout local. Não injeta em site de produção, nem com HTTPS. É razoável, mas significa que o loop de iteração visual é ferramenta de desenvolvimento, não de revisão.

E o vocabulário só serve se o agente ler. A formulação do próprio Impeccable é honesta quanto a isso: todos os modelos produzem o mesmo design porque todos foram treinados nos mesmos templates SaaS. Um arquivo de skill é um empurrãozinho contra uma distribuição de treino, e empurrões perdem para distribuições com mais frequência do que qualquer um gostaria.

Por que não escrever só um checklist?

Pergunta justa. Um guia de estilo em markdown não custa nada e faz mais ou menos o mesmo serviço.

A diferença é a aplicação. Um checklist dentro do prompt é uma sugestão: o modelo lê, concorda e então produz um gradiente roxo porque aquele gradiente estava quarenta mil vezes nos dados de treino. Uma regra determinística quebra o build. É outra categoria de pressão, e é a única que sobrevive a um prazo.

A segunda diferença é a granularidade. Um checklist diz «use boa tipografia». O comando typeset do Impeccable trata hierarquia, escala e pareamento de forma específica, e o detector tem regras individuais para falhas individuais — o feedback consegue apontar uma linha de CSS em vez de gesticular na direção do bom gosto. É todo o argumento a favor de ferramentas em vez de documentação, e vale aqui pelo mesmo motivo que valeu para linters vinte anos atrás.

A terceira é que o vocabulário é compartilhado. bolder, quieter, distill, harden — são palavras sobre as quais um designer e um agente conseguem agir. «Deixa mais chamativo» não é.

Por que está bombando agora

Porque o problema de volume chegou. Um ano atrás, um agente gerava uma landing page de vez em quando. Agora um time produz quarenta variantes antes do almoço, e o gargalo saiu de «dá para construir» para «dá para dizer quais são boas, rápido o bastante».

Um verificador determinístico das falhas baratas é a única parte desse problema que escala. Gosto não escala. Sessenta e duas regras em formato de expressão regular sobre fontes e easings escalam, e entregá-las como algo que roda em CI sem chamada de modelo é a decisão menos glamourosa e mais útil do repositório.