1LunarVeil/frontend-aesthetics

Estética del frontend

frontend-design establece la postura: comprometerse con una dirección y evitar valores predeterminados que nadie eligió. Este skill proporciona las reglas de decisión, los números, los datos de precedentes y las comprobaciones que hacen verificables esas elecciones. Abre la referencia según el nombre del paso cuando lo necesites; no los leas todos de antemano.

1. Lee primero las reglas del proyecto

• Busca un brief o un contrato antes de diseñar: DESIGN.md, PRODUCT.md, un archivo de tokens (tokens.css, theme.*, tailwind.config.*) o un documento de contrato como FRONTEND_CONTRACT.md. Estos tienen prioridad sobre los valores predeterminados de este skill.
• Si el proyecto enruta los valores visuales a través de tokens, un nuevo valor raw en hex, px o rgba en un componente es un hallazgo, no una elección de estilo.
• Conserva lo que ya funciona: cambio de tema, claves de i18n, comportamiento de accesibilidad, componentes existentes. Rediseña el alcance que se pidió, no toda la aplicación.

2. Brief

Escribe el brief descrito en references/principles.md: tema, audiencia y contexto, el trabajo de la pantalla principal, densidad, idiomas y las cinco dimensiones (tipografía, color, diseño, movimiento, detalles). Añade tres rechazos: valores predeterminados a los que este diseño no debe parecerse. Si el usuario no ha descrito un gusto, propón una dirección y explica por qué. No interrogues al usuario.

3. Precedentes

Ejecuta esto desde el directorio base del skill:

python scripts/design_lookup.py "saas dashboard dark" --ux --motion

Usa palabras clave en inglés. La salida proporciona el tipo de producto coincidente, sus estilos, una paleta con pares de texto y UI verificados por contraste, emparejamientos tipográficos y reglas de razonamiento. Trátalo como evidencia, no como una respuesta. Su primer estilo suele ser una elección de tendencia (glassmorphism, neón, bento) que es incorrecta para herramientas densas. Los pares de texto fallan solo en una de las 192 filas de la paleta, pero la mayoría de las paletas tienen un borde por debajo de 3:1 contra el fondo, por lo que cada paleta necesita que sus pares de UI se verifiquen antes de usarse.

4. Dirección

Elige una dirección de references/directions.md, o define la tuya propia, y explica por qué encaja con este brief y por qué la alternativa más cercana no lo hace. Gasta audacia en un solo lugar: un elemento distintivo. Todo lo demás a su alrededor es disciplinado.

5. Tokens antes que componentes

Define los roles de color, la escala tipográfica, el espaciado, los radios, la elevación y las duraciones de movimiento como variables primero (references/color-and-type.md, references/layout-and-motion.md). Verifica cada par de texto que envíes:

python scripts/wcag.py "#1f2937" "#ffffff" "#556070" "#f6f7f9"

6. Construcción

Cubre todos los estados, no solo el camino feliz (references/components-and-states.md). Mantén el texto en los idiomas del producto y prueba la traducción más larga.

7. Verifica antes de informar

• Renderízalo y míralo. python scripts/visual_capture.py <url> --out shots --matrix proporciona vistas por defecto, al 150%, estrecha y de teléfono, espera a que el frame se estabilice e informa errores de consola. Lee references/visual-review.md; una revisión sin captura no es una revisión visual.
• Después de un cambio, captura de nuevo y ejecuta scripts/image_diff.py before.png after.png. Si la región modificada no coincide con lo que afirmas haber cambiado, la afirmación es incorrecta.
• python scripts/slop_scan.py <rutas modificadas>. El código de salida 1 significa hallazgos bloqueantes.
• Contraste para cada par de texto y UI que realmente enviaste (wcag.py).
• Una prueba solo con teclado, una prueba de movimiento reducido y la prueba de ruptura con los peores datos.
• Los errores de consola son fallos. También lo es una captura reportada como blank; trata una reportada como unsettled como sospechosa.

Cuando no se pueda alcanzar un navegador, escribe "no verificado visualmente", nombra los estados que omitiste y no afirmes nada sobre cómo se ve la UI renderizada.

8. Informe

Nombra la dirección y la razón de la misma, proporciona el bloque de tokens y lista cada verificación con su comando y resultado. Lista lo que no se verificó.

Pisos (nunca los intercambies por apariencia)

• Contraste de texto de al menos 4,5:1. El texto grande (24 px, o 18,66 px negrita) y los límites de UI o indicadores de enfoque necesitan al menos 3:1.
• Cada elemento interactivo tiene un indicador de enfoque de teclado visible que difiere de su estado de hover.
• El color nunca transmite significado por sí solo.
• El movimiento respeta prefers-reduced-motion. Nada parpadea más de tres veces por segundo.
• El texto del cuerpo tiene al menos 16 px en la web y 14 px en interfaces de escritorio densas. Ningún texto por debajo de 12 px.
• Cada estado existe: carga, vacío, error, deshabilitado y datos parciales.
• No se envía texto de marcador de posición. Los errores dicen qué sucedió y qué hacer a continuación.
• El texto sobrevive a la cadena realista más larga: traducciones, CJK, rutas largas y nombres de modelos.

Reglas de buen gusto

• Un neutro dominante hace la mayor parte del trabajo. Un acento cubre como máximo alrededor del 10% de la pantalla. Los colores de éxito, advertencia y peligro se mantienen fijos en todos los temas.
• Como máximo dos familias tipográficas, más una mono si es necesario. Una relación de escala. La jerarquía proviene del tamaño, peso, color y espacio antes que de las cajas.
• Menos bordes y menos tarjetas anidadas. Radio de una escala pequeña. Sombras teñidas a la paleta, con como máximo tres niveles de elevación.
• Movimiento: un momento intencional por pantalla, solo transformación y opacidad, y sin animación en acciones repetidas muchas veces en una sesión.
• Texto: oración con minúscula inicial, verbos simples y el mismo nombre para una acción en el botón, el mensaje de resultado y el menú.

La prueba de elección

Cada valor predeterminado (fuente, paleta, radio, sombra, diseño, conjunto de iconos) debe ser elegido para este brief. Si no puedes nombrar la razón, cámbialo. Un valor predeterminado que elegiste no es una señal. references/anti-slop.md enumera las señales comunes y la regla del escáner que marca cada una.

Archivos

• references/principles.md: orden de decisión, plantilla de brief, rechazos.
• references/directions.md: nueve direcciones con tokens de inicio verificados.
• references/color-and-type.md: paletas, modo oscuro, contraste, escala tipográfica, carga de fuentes, CJK.
• references/layout-and-motion.md: cuadrícula, densidad, espaciado, radios, elevación, movimiento.
• references/components-and-states.md: componentes, matriz de estados, texto, prueba de ruptura.
• references/desktop-app.md: reglas para WebView y aplicaciones de escritorio.
• references/anti-slop.md: señales, por qué parecen valores predeterminados, preguntas que hacer, ID de reglas del escáner.
• references/critique.md: procedimiento de revisión, nueve pilares, gravedad, formato de salida.
• references/visual-review.md: cómo renderizar, capturar, leer y volver a diferenciar la UI.
• references/sources.md: de dónde vino cada regla y qué se omitió deliberadamente.
• scripts/wcag.py, scripts/design_lookup.py, scripts/slop_scan.py, scripts/visual_capture.py, scripts/image_diff.py: solo lectura, sin paquetes de terceros, sin red. Usa py -3 si python no está en PATH.
• data/: datos CSV con licencia MIT obtenidos de ui-ux-pro-max (ver data/PROVENANCE.md).