mandasTeam/frontend-autoral

Frontend autoral

Responde en español (es), directo. Entrega la interfaz funcionando y verificada en pantalla, no un borrador.

El problema que resuelve este skill: los sitios generados por IA se parecen entre sí porque nacen de un plan vago, sin contenido real, y nadie revisa el resultado. Aquí cada proyecto obtiene una dirección de arte escrita antes del código, derivada del tema; se mide en un navegador real y solo se entrega después de verlo renderizado y comparado con la lista de clichés.

Se reúnen aquí cuatro fuentes, ya reconciliadas:

• taste-skill (leonxlnx): inventario del tema, argumento, sorteo de composiciones estudiadas en 247 sitios premiados, frase de la idea, cosa viva, imágenes de archivos abiertos, lint e inspector en navegador real, crítica en rondas con techos de nota. Herramientas en vendor/taste-skill/.
• Emil Kowalski (emilkowalski/skills): decisión de animación, curvas, duraciones, física, sensación de app en el móvil, datos de peor caso, revisión en tabla Antes/Después.
• Leyes de UX (lawsofux.com): las 30 leyes como preguntas que se verifican en pantalla.
• logo-design (kaankiziltug): proceso de logo, ícono de app y favicon, con auditoría SVG y exportación del conjunto web. Herramientas en vendor/logo-design/.

Cuando las fuentes discrepan: el pedido actual > "Gusto de Igor" y references/cliches.md > este archivo > references/movimiento.md (manda sobre movimiento) > las referencias en inglés de vendor/. En especial: aquí el movimiento es solo con función, sin cuota de elementos animados y sin entrada en cada sección; las escenas de desplazamiento del sorteo solo entran si el usuario lo pide.

<skill> en los comandos es la carpeta de este skill. Los scripts necesitan Node 22+ (lint: 18+) y un Chrome, Edge o Chromium (el de Playwright sirve; scripts/achar-chrome.mjs lo encuentra solo). Los de ícono necesitan Python 3 (en Windows, python).

Cuándo usar

• Crear sitio, landing page, portafolio, página institucional, pantalla de app, dashboard, formulario.
• Rediseñar o "hacer más bonita" una interfaz existente.
• Revisar UI/UX de una pantalla: jerarquía, accesibilidad, estados, copy, responsividad, animación.
• Crear un componente con identidad (no solo funcional) para un producto.
• Crear logo, símbolo, ícono de app o favicon de un proyecto, o generar las variantes de un logo existente.

No usar para: README y arte de perfil de GitHub (skill readme-designer), gráficos y visualización de datos (skill dataviz), decks y documentos.

Elegir el modo

• Crear página (sitio, landing, portafolio; proyecto nuevo o rediseño completo): flujo completo.
• Pantalla de app (dashboard, admin, configuración, inbox, lista con filtros, editor): lee vendor/taste-skill/references/app-screens.md completo antes de empezar. Tiene su propia secuencia, su propio sorteo (draw.mjs --app --kind <tipo>) y reglas propias (bordes discretos, etiquetas pequeñas y paneles repetidos son normales allí; gradiente, brillo, ícono en cuadrado colorido, gráfico arcoíris y número de vanidad inventado no). Usa el flujo de abajo con --app en el portal; la cosa viva y el piso de imágenes no aplican. Página de producto que muestra la app es página; los fragmentos de la app dentro de ella siguen las reglas de app y llevan data-ui.
• Evolucionar (ya existe sistema visual, DESIGN.md, BRAND.md, tokens, tema Tailwind, biblioteca de componentes): la dirección existente manda. Léela antes, reutiliza tokens y componentes, y solo propón cambio de identidad si el usuario lo pide. Salta el sorteo (o usa --keep palette,type para sacar solo composición), pero pasa el portal y la lista de clichés.
• Revisar (auditoría, "¿qué está mal aquí?", "revisa las animaciones"): solo pasos 1 y 5, en el estado actual. Hallazgos en una tabla Dónde | Antes | Después | Por qué agrupada por gravedad, sin preámbulo (references/revision.md §11).
• Ajuste puntual ("más atrevido", "más tranquilo", "cambia la fuente", "anima esto"): cambia solo lo pedido, dentro de la dirección existente. Ver "Ajustes" en references/oficio.md y, para animación, references/movimiento.md.
• Ícono o logo (logo, marca, ícono de app, favicon): references/iconos.md. En todo proyecto de sitio o app, el modo ligero de allí se ejecuta en el paso 4 para que el proyecto salga con su propio ícono.

Flujo

Cada paso solo termina cuando el criterio de listo se cumple.

1. Entender el tema. Lee el pedido y el código existente. Responde para ti, en una línea cada uno: qué es el producto, para quién es, cuál es la tarea principal, si es página o pantalla de app, qué contenido real existe (textos, imágenes, datos, logo, marca) y qué imagen existe de verdad. Cierra el inventario de 8 a 12 cosas que solo este cliente tiene (references/direccion.md §1). Si falta lo esencial (qué es el producto o para quién), haz una ronda de hasta 4 preguntas en lote. Si solo falta gusto, decide y di lo que decidiste.

   • Listo cuando producto, público, tarea, tipo, inventario e inventario de imágenes estén claros, y las lagunas tengan respuesta o decisión registrada.

2. Escribir la dirección de arte antes de cualquier CSS, en DESIGN.md en la raíz del proyecto (modelo en assets/DESIGN.template.md; en un solo archivo, al inicio de la respuesta). Método en references/direccion.md:

   • el argumento: la página como afirmaciones con prueba, una por sección; sección sin afirmación se elimina;
   • el sorteo de composición (vendor/taste-skill/scripts/draw.mjs ... --options 3), recomendado para páginas: elige la opción que carga algo del inventario, no la más familiar, y filtra la paleta y el tipo por el tema y los clichés;
   • concepto en una frase de escena, listas "parece / no parece";
   • la frase de la idea ("En esta página, [algo del inventario] se convierte en [el recurso]"), la prueba del competidor y la cosa viva (una interacción hecha de la idea, con contenido real);
   • firma; paleta de 4 a 6 colores nombrados con rol y contraste; 1 o 2 familias con escala de hasta 5 tamaños; cuadrícula con márgenes iguales, ritmo y regla de forma; regla de movimiento; fuente de las imágenes; de dónde sale el ícono;
   • wireframe en ASCII de cada sección, vecinas con formas diferentes.

   Luego ejecuta la prueba de intercambio: "si cambiara el nombre del producto, ¿esta dirección serviría para un competidor cualquiera?" Si es así, revisa y di qué cambió. Verifica contra references/cliches.md, incluido el §11 (sacar un cliché no puede dejar solo vacío).

   • Listo cuando cada elección tenga un motivo ligado al producto, al público o al contenido, la frase de la idea pase la prueba del competidor y ningún elemento caiga en un cliché sin justificación.

3. Escribir el contenido como guion de texto puro antes del markup, con references/copy.md: títulos que caben en dos líneas en todo ancho (haz la cuenta), la frase de apoyo justo debajo, una acción principal con verbo y objeto, cada sección con el contenido completo. Donde falte prueba (número, testimonio, cliente, evaluación), usa un marcador visible como [testimonio real aquí] en lugar de inventar; donde falte solo detalle de contenido (nombre de plato, de habitación), usa una muestra plausible y enumérala para confirmar.

   • Listo cuando ningún texto podría estar en el sitio de otra empresa, ninguna prueba sea inventada y las muestras estén listadas.

4. Construir, parado. Con el movimiento desactivado mentalmente: una página que necesita animación para parecer lista no está lista. Orden: tokens (color, tipo, espacio, forma, curvas), el hero exactamente como se dibujó en escritorio y móvil, cada sección según su wireframe llevando la idea hasta precio, FAQ y pie de página, imágenes (references/imagenes.md: propias, generadas, archivos abiertos con assets.mjs, dibujadas del tema), la cosa viva, el marco (márgenes iguales, título en cada sección, ningún tramo vacío), estados y semántica, favicon e íconos (references/iconos.md, modo ligero). Sigue references/oficio.md, references/ux.md y references/leyes-ux.md. vendor/taste-skill/assets/base.css es una base neutral opcional.

   • Usa el stack que el proyecto ya tiene. Sin dependencia visual nueva sin motivo funcional.
   • Listo cuando la página se ejecute sin error de consola, sin desplazamiento horizontal en móvil, con todos los estados relevantes (hover, focus-visible, active, disabled, loading, error, vacío), datos de peor caso probados (references/ux.md §9) e ícono propio en su lugar.

5. Medir, mirar, corregir. Ejecuta el portal: node <skill>/scripts/inspeccionar.mjs <url-o-index.html> --src <carpeta-del-código> (con --app en pantalla de app). Ejecuta el lint y el inspector en 1440, 768 y 390 px y guarda capturas de pantalla en .taste-skill/inspect/. Corrige todo FAIL. Luego abre todas las capturas y critica con references/revision.md: prueba de IA, 15 pasadas, rúbrica con techos, crítica escrita en el formato de la ronda. Corrige los 3 problemas más graves, mide y mira de nuevo; máximo 3 rondas.

   • Listo cuando haya 0 FAIL, nota media ≥ 8, ningún criterio < 7 y la lista de problemas esté vacía. Si no se puede llegar, di qué quedó pendiente y la nota real.

6. Mover, solo con función. Ahora el movimiento, decidido por references/movimiento.md: frecuencia (acción de teclado y cosa vista todo el día no se anima), propósito, curva (ease-out fuerte, nunca ease-in), duración (< 300 ms en interfaz), presión (scale(0.97)), origen en el disparador, hover solo con ratón, prefers-reduced-motion. Máximo un momento orquestado por página, en general la cosa viva o la firma. Ejecuta el portal de nuevo y verifica en las capturas que nada haya desaparecido.

   • Listo cuando toda animación responda "¿para qué?" y el portal continúe con 0 FAIL.

7. Verificar e informar. Checklist final e informe de references/revision.md §9 y §10.

¿Sin forma de renderizar (ningún navegador y ninguna forma de instalar uno)? Ejecuta solo el lint, dilo en el informe y haz la revisión leyendo el código contra el checklist. No digas que lo verificaste en pantalla.

Diseño en una pantalla

El detalle está en references/oficio.md, references/cliches.md y references/leyes-ux.md.

• Toda decisión visual tiene motivo ligado al producto, la marca, el contenido o el uso. Antes de añadir cualquier elemento, pregúntate si mejora comprensión, función, estética o experiencia. Si no mejora, no entra.
• La identidad viene del tema, nunca de la tendencia. Futurista, tech o minimalista no son estándar; solo entran si el tema lo pide. Minimalismo no es ausencia de personalidad.
• Visual autoral, mecánica convencional (Ley de Jakob). La audacia reside en la tipografía, el color, la imagen y la composición; menú, enlace, botón y formulario funcionan como en cualquier sitio.
• Audacia en un solo lugar, en la idea-firma. El resto se mantiene disciplinado. Antes de entregar, quita un accesorio. Pero quitar adorno no es dejar vacío: el espacio va para escala, contenido completo, imagen del tema o campo de color.
• La composición sigue el contenido. Cada sección elige su forma según lo que muestra: lista, secuencia, comparación, imagen grande, cita, tabla. Vecinas no repiten forma. No todo es card, ni todo está centrado, ni todo es cuadrícula de 3 columnas.
• Jerarquía antes que simetría. Un elemento principal por pantalla; 2 o 3 tamaños hacen el trabajo, hasta 5 en total; títulos de hasta dos líneas. Asimetría dentro de la cuadrícula, márgenes externos siempre iguales.
• Color con rol. Un fondo, una tinta, 1 o 2 neutros teñidos, un acento en 1 a 3 lugares (Von Restorff). Superficies por escalón de tono, sin gradiente, glow, blur, glass o sombra en reposo.
• Tipografía como voz. 1 o 2 familias elegidas según el carácter del producto, cuerpo legible (≥ 16 px, 45 a 75 caracteres por línea) en tinta completa.
• Imagen que muestra. Real del proyecto, generada, de archivo abierto con crédito, o dibujada del propio tema; una dominante vence a seis pequeñas; nunca caja gris ni banco genérico.
• Movimiento solo con función, rápido, interrumpible, con ease-out y origen correcto. Siempre prefers-reduced-motion.
• Accesibilidad no negociable: contraste AA, foco visible, navegación por teclado, semántica correcta, alt en imagen con contenido, objetivos ≥ 44 px, zoom liberado.

Gusto de Igor

Punto de partida, no receta. El pedido actual siempre gana.

• El tema cambia en cada proyecto. Nunca reutilices paleta, fuente, motivo o copy de trabajo anterior sin que él lo pida. (El sorteo de taste-skill ayuda: recuerda los anteriores.)
• Le gusta el tema asumido y bien ejecutado, presente en el conjunto completo, no el adorno tímido.
• Coherencia ante todo: una sección "cruda" en medio de las estilizadas incomoda. Si una destona, rehazla en el mismo patrón.
• Movimiento sutil. Objeto atravesando la pantalla está prohibido.
• Copy natural, sin frase de efecto forzada, sin disclaimer o pie de página que nadie pidió.
• "Mejorar" una sección es rehacer el visual manteniendo el contenido, no eliminar.
• Cuando él veta un elemento, quita solo ese elemento. No reinterpretes el resto.

Trampas

• El primer impulso es el cliché. Hero centrado con título, subtítulo, dos botones y gradiente; tres cards con ícono en un cuadrado colorido; sección de números; testimonios. Si la primera idea llegó demasiado rápido, es probable que sea el patrón. Vuelve al inventario.
• Evitar un cliché cayendo en otro. Huir del morado yendo a fondo crema + serifa + terracota, o a negro + verde ácido, es cambiar un patrón de IA por otro. Ver los "cinco visuales estándar" en references/cliches.md.
• Página limpia y vacía. Sin adornos y sin nada en su lugar pierde contra la página llena de clichés. Contenido completo, tipo grande, imágenes reales.
• Idea de categoría. "Pan" sirve para cualquier panadería. Si la frase de la idea funciona con el competidor, vuelve al inventario.
• Contenido inventado para llenar. Número sin fuente, logo de cliente ficticio, testimonio, avatar aleatorio, mockup de dashboard genérico. Usa marcador o corta la sección.
• Título de tres líneas.

...

[truncado para traducción]