Auditoría de UI de stock
Las interfaces generadas y las de kits de inicio comparten un aspecto reconocible: un acento índigo o violeta, un degradado hero de púrpura a azul, Inter en todas partes, tarjetas esmeriladas, emojis en la navegación. Ninguno de estos está mal por sí solo. El problema es que son elecciones que vinieron con la plantilla y no del producto. Esta skill encuentra esas elecciones con un escáner estático y luego las clasifica mediante juicio humano. El escáner produce candidatos; solo el triaje produce hallazgos.
Esta skill elimina valores predeterminados no elegidos. No inventa una marca. Si el producto aún no tiene una dirección visual, dilo y pide una en lugar de reemplazar un valor predeterminado por otro.
Antes de escanear
- Lee el briefing, los tokens de diseño y la configuración del tema o la biblioteca de componentes. Anota cada color, fuente y componente que el producto haya solicitado. Esos se conservan, incluso si el escáner los marca.
- Determina el modo a partir de la solicitud:
- Revisión: solo reporta hallazgos. No edites nada.
- Limpieza: corrige los hallazgos confirmados y solo dentro del área que el usuario indicó (una página, una carpeta de componentes, toda la aplicación). Reporta cualquier cosa que notes fuera de esa área en lugar de corregirla.
- Elige el alcance del escaneo: las carpetas de origen que renderizan la UI, no todo el repositorio.
Ejecutar el escáner
bun <ruta de esta skill>/scripts/scan.mjs [--json] [--fail-on high|medium|low] <rutas>...
Node 22 o posterior también funciona. Recorre directorios, omite dependencias, salidas de compilación y cobertura, y archivos minificados, y lee .html .css .scss .js .ts .jsx .tsx .vue .svelte .astro. Imprime el número de archivos escaneados. Salida 0 significa que nada alcanzó la gravedad de fallo (alta por defecto), 1 significa que algo lo hizo, 2 significa mal uso o cero archivos escaneados. Un 2 nunca es un resultado limpio. Pasa --fail-on medium cuando los acentos violeta, una sola fuente de stock o los iconos emoji deban hacer fallar la ejecución. No agregues el escáner como una compuerta de CI a menos que te lo pidan.
| Regla | Gravedad | Captura |
|---|---|---|
purple-blue-gradient | alta | degradados cuyas paradas son todas tonos fríos con al menos un violeta, en CSS o en clases from-/to- de Tailwind |
violet-accent | media | cualquier token hex, rgb, hsl, oklch o HSL simple cuyo tono calculado caiga en la banda índigo a púrpura, más las clases indigo/violet/purple de Tailwind |
gradient-text | media | background-clip: text y bg-clip-text |
single-stock-font | media | una sola fuente sans de stock (Inter, Roboto, Poppins y similares) como la única cara nombrada en dos o más declaraciones en el conjunto escaneado |
emoji-icon | media | emoji dentro de encabezados, botones, enlaces, elementos de navegación o campos icon/label/title |
neon-glow | media | sombras de desplazamiento cero y desenfoque amplio en un color saturado, y sombras coloreadas de Tailwind |
frosted-glass | baja | backdrop-filter: blur() y backdrop-blur |
library-default-token | baja | valores predeterminados sin modificar de Bootstrap, Material, MUI, Ant Design, Chakra, shadcn/ui y el starter de Vite |
tracked-caps | baja | texto en mayúsculas con espaciado amplio entre letras |
La regla de fuente examina todos los archivos en una sola ejecución, así que escanea todo el alcance de la UI junto; escanear un archivo a la vez la oculta.
Triaje de cada coincidencia
Abre cada línea marcada y lee suficiente contexto para ver para qué sirve el elemento. Asigna a cada coincidencia exactamente un veredicto:
- Valor predeterminado no elegido: nada en el briefing, los tokens o el historial lo solicita, y se lee como una plantilla de inicio. Esto es un hallazgo.
- Elección deliberada: el briefing, un archivo de tokens, una guía de marca o un mensaje de commit muestra que alguien lo eligió. Consérvalo y menciona la evidencia.
- Falso positivo: la coincidencia no hace lo que la regla supone, como un tono violeta en un tema de resaltado de sintaxis, un desenfoque en un fondo modal sobre contenido denso, o un emoji dentro de datos de muestra generados por el usuario. Déjalo y explica por qué.
- No resuelto: no puedes determinar si alguien lo eligió. No es un hallazgo y no cambias nada. Reporta qué falta y la pregunta que lo resolvería.
Corregir lo real
- Corrige la causa, no la línea. Cinco violetas hex suelen significar que falta un token de acento; define la paleta y la tipografía del producto una vez y apunta los componentes hacia ella.
- Elige reemplazos que sirvan al contenido: contraste que se mantenga, un acento que marque la única acción importante, una tipografía que se adapte a la carga de lectura.
- Nunca ajustes un valor solo para salir del rango del escáner, como desplazar un tono unos grados o cambiar un hex por un
oklch()equivalente. Si el color está mal, cámbialo; si está bien, consérvalo y registra por qué. - Nunca cambies un color de marca, un color de estado (éxito, advertencia, error) o un indicador de foco para que el escaneo pase. Esos tienen significado; regístralos como deliberados.
- Reemplaza los iconos emoji con el conjunto de iconos existente del proyecto. Agrega una nueva dependencia de iconos solo si el usuario está de acuerdo.
Lo que el escáner no puede ver
Verifica estos leyendo la página renderizada, ya que ninguna coincidencia de patrón los encuentra:
- cada sección construida con el mismo encabezado centrado, subtítulo y dos botones
- una cuadrícula de tres tarjetas con un icono, título y una línea de texto en cada tarjeta
- una pequeña insignia o etiqueta sobre el encabezado principal
- tarjetas marcadas con un borde izquierdo grueso de color
- un banner de estadísticas con números grandes ("10k+ usuarios", "99.9% de disponibilidad")
- secciones numeradas "1, 2, 3"
- un tema oscuro forzado sin opción clara que el briefing solicitó
- el mismo radio de esquina grande y sombra suave en todas las superficies
- espaciado y tamaños de tipo que ignoran la escala del proyecto
- copia que podría describir cualquier producto
Verificar
- Vuelve a ejecutar el escáner en el mismo alcance y confirma que cada coincidencia restante tenga un veredicto registrado.
- Observa la UI renderizada en los tamaños importantes (un ancho de teléfono estrecho y un ancho de escritorio como mínimo), en cada tema que el producto incluya.
- Un escaneo limpio no dice nada sobre accesibilidad, diseño o calidad general. Verifica el contraste y los estados de foco en todo lo que cambiaste.
Si no pudiste renderizar la UI, di que la revisión fue solo estática.
Reporte
Escribe el reporte en este orden:
- Alcance escaneado, archivos escaneados, modo y código de salida del escáner.
- Hallazgos corregidos (o propuestos, en modo revisión), cada uno con
archivo:línea, la regla y qué lo reemplazó. - Coincidencias conservadas como deliberadas, cada una con su evidencia.
- Coincidencias no resueltas, cada una con lo que falta y la pregunta que lo resolvería.
- Falsos positivos, cada uno con una línea sobre por qué.
- Problemas que el escáner no puede ver, si encontraste alguno.
- Cómo verificaste: resultado de la nueva ejecución, tamaños y temas vistos, o "solo estática".