Impeccable: 62 reglas deterministas contra el slop de IA

Las páginas que construye un modelo tienen un aire inconfundible. Lo has visto: Inter por todas partes, un degradado de violeta a azul en el hero, tarjetas dentro de tarjetas, texto gris sobre fondo de color y una loseta de icono cuadrada y redondeada flotando sobre cada titular. Paul Bakaus le puso nombre a ese aire y luego escribió un linter para perseguirlo.

Impeccable es una skill de diseño para agentes de programación. Esta semana sumó unas 6.700 estrellas y acumula alrededor de 91.500. El eslogan — «el vocabulario de diseño para tu agente de programación» — se queda corto justo en lo que resulta verdaderamente raro: 62 de sus comprobaciones funcionan como reglas deterministas, sin ningún modelo de por medio.

Qué es, en concreto

Una skill, 24 comandos y un detector. Empezó como una extensión de la skill frontend-design de Anthropic y creció hasta tener criterio propio.

La instalación es un solo comando en la raíz del proyecto:

npx impeccable install
/impeccable init

El segundo paso es el que la gente se salta. init te entrevista sobre el producto —público, propósito, restricciones, tono— y escribe las respuestas en PRODUCT.md. Un comando document aparte genera DESIGN.md a partir del código que ya tienes. La separación importa: los hechos del producto y el sistema visual son artefactos distintos, que cambian a ritmos distintos, y meterlos en un mismo archivo es la forma más rápida de que un documento de diseño caduque.

Luego están los 24 comandos. Son más un vocabulario que un flujo de trabajo:

craft ejecuta la secuencia completa de dar forma y después construir, con iteración visual. critique revisa jerarquía, claridad y registro emocional. audit comprueba accesibilidad, rendimiento y adaptabilidad. polish alinea con el sistema de diseño antes de publicar. bolder y quieter son ajustes direccionales: amplificar o contener. harden se ocupa de estados de error, i18n, desbordamiento de texto y casos límite. typeset y layout arreglan las dos cosas que las interfaces generadas por agentes suelen hacer mal. live abre un navegador y genera variantes de un elemento concreto ahí mismo.

Cualquiera de ellos se puede fijar como atajo independiente:

/impeccable pin audit

Lo que crea /audit como comando de primer nivel. Función pequeña, diferencia grande en si el vocabulario se usa de verdad o no.

El detector es la ingeniería interesante

Aquí es donde Impeccable se separa del montón de repositorios que solo son colecciones de prompts: las 62 reglas no necesitan un modelo, ni una clave de API, ni un agente.

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

Es decir, corre en CI. Una pull request que reintroduce un easing con rebote, o un degradado violeta perdido, o un pie de foto gris de 14px sobre verde azulado, puede fallar la comprobación sin que nadie pague tokens. Hay un flag --github que emite anotaciones de GitHub Actions, que es el único detalle de integración que le importa a la mayoría de los equipos.

El conjunto de reglas tiene opiniones, tantas que va a molestar, y la documentación lo dice sin rodeos. La lista de antipatrones prohíbe Arial, Inter y las fuentes por defecto del sistema; prohíbe el negro puro y el gris puro (siempre con tinte); prohíbe envolver todo en tarjetas y las tarjetas dentro de tarjetas; prohíbe los easings de rebote y elásticos por anticuados; prohíbe el texto gris sobre fondos de color.

Algunos de esos puntos son argumentos de oficio defendibles. Un párrafo con contraste insuficiente sobre un fondo saturado es un fallo de accesibilidad que además queda barato. La prohibición de Inter es moda, y las reglas de moda envejecen mal: el mismo documento que prohíbe Inter parecerá una pieza de época dentro de tres años. Pero un linter sin opiniones es solo un formateador, y la gracia de este es tener postura.

Como es determinista, también es esquivable. Cualquier equipo que quiera publicar su degradado violeta puede añadir una excepción en línea:

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

O gestionar las omisiones de forma global con npx impeccable ignores add-value overused-font Inter --reason "Brand font". El flag --reason hace un trabajo social silencioso: vuelve visible la excepción en un diff.

Cómo se engancha al agente

La ruta de instalación que elijas determina cuán intrusivo resulta. Para Claude Code, Copilot, Codex, Cursor y Grok Build, install escribe un manifiesto de hooks nativo de cada proveedor. En Claude Code es .claude/settings.local.json, ignorado por git y local a la máquina. En Copilot es .github/hooks/impeccable.json, versionado y compartido con los agentes en la nube. En Cursor es .cursor/hooks.json, que se dispara en postToolUse cuando se escribe un archivo.

El efecto es que el detector corre sobre las propias ediciones del agente y le devuelve los hallazgos a su bucle. Es un mecanismo distinto, y de fondo, al de «ejecutar el comando de auditoría cuando te acuerdes». Atrapa la chapuza en el momento de la generación, no en la revisión.

El costo es el de siempre: los hooks que escriben en la configuración del repositorio son hooks que aparecen en la revisión de código, y quienes usan Codex tienen que aprobar explícitamente los hooks de proyecto con /hooks después de instalar. Si tu equipo tiene opiniones fuertes sobre la configuración de herramientas versionada, la vía del submódulo existe justo por esto: git submodule add más npx impeccable link --source=.impeccable --providers=claude,cursor mantiene la herramienta versionada junto al código que gobierna.

Lo que no va a arreglar

Tres límites que conviene nombrar.

No puede decirte si la página es buena. Las 62 reglas capturan señales de superficie. Una página puede pasarlas todas y no tener ningún punto de vista, que es la versión profunda del problema del slop de IA y la que ningún linter ha resuelto.

El modo live solo funciona sobre un checkout local. No se inyecta en un sitio en producción, ni con HTTPS. Es razonable, pero significa que el bucle de iteración visual es una herramienta de desarrollo, no de revisión.

Y el vocabulario solo sirve si el agente lo lee. El propio planteamiento de Impeccable es honesto al respecto: que todos los modelos produzcan el mismo diseño se debe a que todos se entrenaron con las mismas plantillas SaaS. Un archivo de skill es un empujoncito contra una distribución de entrenamiento, y los empujoncitos pierden frente a las distribuciones más a menudo de lo que a cualquiera le gustaría.

¿Y por qué no una simple lista de comprobación?

Pregunta justa. Una guía de estilo en un archivo markdown no cuesta nada y hace más o menos lo mismo.

La diferencia es la aplicación. Una lista dentro de un prompt es una sugerencia: el modelo la lee, asiente y luego produce un degradado violeta porque ese degradado estaba cuarenta mil veces en sus datos de entrenamiento. Una regla determinista hace fallar una compilación. Es otra categoría de presión, y es la única que sobrevive a una fecha de entrega.

La segunda diferencia es la granularidad. Una lista dice «usa buena tipografía». El comando typeset de Impeccable aborda jerarquía, escala y emparejamiento de fuentes de forma concreta, y el detector tiene reglas individuales para fallos individuales, así que la respuesta puede señalar una línea de CSS en vez de hacer gestos hacia el buen gusto. Ese es todo el argumento a favor de las herramientas frente a la documentación, y aquí vale por la misma razón por la que valió para los linters hace veinte años.

La tercera es que el vocabulario se comparte. bolder, quieter, distill, harden: son palabras sobre las que un diseñador y un agente pueden actuar. «Hazlo más llamativo» no lo es.

Por qué se está viralizando ahora

Porque llegó el problema del volumen. Hace un año, un agente generaba una landing page de vez en cuando. Ahora un equipo genera cuarenta variantes antes de comer, y el cuello de botella se movió de «¿podemos construirlo?» a «¿podemos distinguir cuál de estas es buena, con la suficiente rapidez?».

Un verificador determinista de los fallos baratos es la única parte de ese problema que escala. El gusto no escala. Sesenta y dos reglas con forma de expresión regular sobre fuentes y easings sí, y publicarlas como algo que corre en CI sin llamar a un modelo es la decisión menos glamorosa y más útil del repositorio.