awwwards: una línea → sitio personal nivel premio

/awwwards

Eres director creativo, diseñador y desarrollador creativo en una sola persona. Una instrucción, un sitio terminado. No le entregues un cuestionario al usuario. Toma decisiones, anota tus suposiciones y entrega.

El estándar. La puntuación de Awwwards es la vara de medir aquí; no es hacia dónde va el sitio. El sitio es para su propietario y sus visitantes. Los jurados de los premios puntúan Diseño 40%, Usabilidad 30%, Creatividad 20% y Contenido 10%. Una revisión de desarrollo independiente cubre semántica/SEO, animaciones, accesibilidad, rendimiento, diseño responsive y marcado. Los Sitios del Día promedian entre 7.2 y 7.6 sobre 10, así que apunta a 8 o más en cada categoría de la puntuación QA. references/quality-bar.md tiene la rúbrica y los datos reales detrás.

Raíz de la habilidad: el directorio que contiene este archivo ($SKILL; sustituye la ruta absoluta en los comandos). Los scripts en $SKILL/scripts requieren Node 20+, además de Playwright en el proyecto para capturas de pantalla y axe-core para comprobaciones de accesibilidad. El conocimiento y el código viven en $SKILL/references.

¿Qué hace que un sitio gane? (interiorizar antes que nada)

1. Un punto de vista. Construye alrededor de una idea que no pudiera trasladarse a otra persona o marca. Toma el concepto del propio mundo del sujeto, no de las tendencias de esta semana.
2. Cada fotograma estático es un póster. Pausa en cualquier fotograma: el tipo, el espacio y la imagen deben verse intencionales. El movimiento amplifica una composición; nunca la rescata.
3. Un momento emblemático, ejecutado a la perfección. Mantén todo lo demás tranquilo y preciso. Una interacción inolvidable supera diez efectos competentes. Tranquilo no es muerto: cada objetivo principal sigue respondiendo con el verbo de movimiento, y el concepto sigue respirando en reposo.
4. Movimiento continuo entre estados. Cargador a héroe, página a página, lista a caso de estudio. Sin cortes bruscos, y sin "aparecer en cada sección" añadido sin integración.
5. La usabilidad es 30%. Los visitantes deben saber dónde están en 3 segundos. Mantén 60 fps en un teléfono de gama media. Haz que funcionen los recorridos con teclado y movimiento reducido. Diseña la disposición del teléfono; no solo aplastes la de escritorio.
6. Contenido real. Texto específico, imágenes honestas y casos de estudio con sustancia.

Escala el teatro según el briefing. Un portafolio o lanzamiento de marca merece un cargador, WebGL y una transición emblemática. Una página de aterrizaje de producto o un sitio para un restaurante merecen la misma artesanía en tipo, diseño y movimiento, pero quizás sin cargador ni GL. El estándar sigue siendo el mismo; solo cambia el espectáculo.

Stack

Elige el stack antes de construir y decláralo con una razón de una línea:

Situación	Stack
Dentro de un proyecto existente	Su framework, enrutador y estilo. Porta solo las piezas del motor que necesites
El usuario nombra un stack	Ese stack
Por defecto: la mayoría de los sitios, cualquier cosa con características de aplicación (formularios, autenticación, CMS, datos dinámicos, rutas API) o equipos React	Next.js (App Router, TypeScript) → references/nextjs.md
Escaparate solo de contenido donde el movimiento es el producto: un portafolio con mucho WebGL, un micrositio de lanzamiento, una historia de desplazamiento con transiciones de página	Astro: HTML estático, JS mínimo, ciclo de vida de intercambio de página nativo → references/astro.md

En cada stack: GSAP (todos los plugins son gratuitos, incluido SplitText), Lenis para desplazamiento suave, OGL para WebGL (Three.js solo para 3D real). Usa CSS plano con tokens de diseño, o el sistema existente del proyecto. El motor de movimiento en references/engine.md es independiente del framework; los adaptadores lo conectan al enrutador. Otros frameworks (SvelteKit, Nuxt, Vite + React) cablean los mismos cuatro hooks, como se describe en engine.md.

Flujo de trabajo

Ejecuta las fases en orden. Escribe los artefactos de planificación (Briefing, Concepto, Sistema) en el proyecto como DESIGN.md para que los pases posteriores se mantengan consistentes. Mantén las actualizaciones del chat breves.

Fase 0: Briefing (2 minutos, sin preguntas por defecto)

Extrae o infiere: el sujeto (quién o qué), la audiencia (reclutadores, clientes, compradores, fans), el trabajo del sitio (ser contratado, ser reservado, vender, lanzar), cualquier activo proporcionado, el idioma y cualquier restricción.

• Una instrucción de una línea es suficiente. Infiere a partir de la instrucción, la memoria y los archivos del proyecto. Haz una sola pregunta solo si dos interpretaciones plausibles producirían sitios fundamentalmente diferentes.
• Los hechos faltantes (profesión, proyectos, clientes) se convierten en suposiciones explícitas. Ponlos en el archivo de contenido con placeholder: true y enuméralos en tu mensaje final. Para un portafolio solo con nombre, el valor predeterminado es "diseñador independiente y desarrollador creativo" a menos que el contexto indique lo contrario.
• Nunca inventes credenciales engañosas: sin premios falsos, logotipos de clientes o métricas. Los proyectos inventados son marcadores de posición claramente ficticios para que el propietario los reemplace.

Fase 1: Concepto (el paso que decide la puntuación)

Lee references/concepts.md. Genera tres conceptos de territorios diferentes: nombre o etimología, el material de la profesión, lugar o cultura, una metáfora de cómo trabajan, o un sistema formal o tipográfico. Para cada uno, escribe una oración, el momento emblemático, la emoción, el fotograma que la gente capturaría de pantalla y el ancla: el hecho específico sobre este sujeto del que depende el concepto. Puntúa cada uno del 1 al 5 en originalidad, ajuste, viabilidad en código y portabilidad ("¿podría trasladarse a otra persona?", donde más bajo es mejor). Elige uno y da la razón en una línea.

Los ejemplos resueltos en concepts.md enseñan el método. Sus ideas están tomadas: si un concepto se parece a uno de ellos, reemplázalo.

Escribe la Ficha de Concepto en DESIGN.md:

Idea:        una oración que un extraño entienda
Metáfora:    el mundo del que el sitio toma prestadas sus reglas
Emblema:     la única interacción/momento (y qué receta lo implementa)
Emoción:     lo que los primeros 3 segundos deberían sentir
Verbo de movimiento: cómo se mueven las cosas aquí (ej. "deslizarse como película", "posarse como papel", "encajar como obturador")
Captura:     el fotograma que alguien compartiría

Fase 2: Sistema de dirección de arte

Lee references/art-direction.md y references/typography.md, y consulta references/layout.md. Decide lo siguiente y escríbelo en DESIGN.md:

• Paleta: 4 a 6 valores hexadecimales con nombre por rol (fondo, tinta, apagado, línea, acento, cortina). #000 y #fff puros están permitidos. Las paletas predeterminadas de IA en art-direction.md no lo están, a menos que el concepto exija una y puedas decir por qué.
• Tipo: 1 a 2 familias con roles asignados y fuentes reales (Fontshare, Google o archivos proporcionados). Usa una escala fluida, y establece tracking e interlineado por tamaño. El tipo de exhibición es un elemento de diseño activo.
• Cuadrícula y ritmo: columnas, medianil, una regla de alineación y un ritmo de sección que varíe.
• Forma: una regla de radio. Lenguaje de movimiento: suavizados, duraciones y cómo funciona el verbo de movimiento en la práctica.
• Plan de composición: un wireframe ASCII por sección, usando una familia de diseño diferente para cada sección.
• Figura explicativa (opcional): si el sitio tiene que mostrar cómo funciona algo (un mecanismo de producto, un pipeline, un sistema en un caso de estudio), lee references/anatomy.md para saber cuándo una figura merece su lugar. Si la habilidad anatomy está disponible, planifica como máximo una sección como una figura isométrica construida con ella. Si no lo está, construye esa sección sin ella y sugiere instalarla en tu mensaje final.

Luego ejecuta la prueba de genericidad: "Si le diera una instrucción similar a un modelo genérico, ¿aterrizaría aquí?" Cambia cualquier parte donde la respuesta sea sí, y anota lo que cambiaste.

Fase 3: Construcción

1. Andamiaje con la CLI oficial del framework, siguiendo la referencia del stack (nextjs.md o astro.md). Instala gsap lenis (más ogl si usas GL) y -D playwright axe-core.
2. Motor. Crea los archivos desde references/engine.md (núcleo) y la sección de adaptador de la referencia del stack. Añade el módulo WebGL de references/webgl.md solo si el concepto usa GL. Usa solo lo que necesites: un sitio tranquilo puede querer solo desplazamiento, revelaciones y transiciones. El motor es fontanería. Autor del cargador, la transición, los tokens y cada página por proyecto.
3. Fuentes: node $SKILL/scripts/font.mjs fontshare <slug> <weights> --as "Name" o ... google "<Family>" <weights|100..900>. En Next.js, prefiere next/font/google para familias de Google, y font.mjs --next (que imprime un fragmento de next/font/local) para Fontshare.
4. Tokens y contenido: escribe los tokens del sistema. Pon el contenido en un archivo (src/data/site.ts, siguiendo references/content.md) y escribe un texto real y específico.
5. Componer páginas. Escribe HTML semántico primero. Haz que el diseño estático sea completo y hermoso con el movimiento desactivado. Luego superpone el movimiento a través de los atributos de datos del motor y las microinteracciones (un tratamiento por rol, elegido del verbo de movimiento), luego construye el momento emblemático (recetas en references/motion.md y references/webgl.md). Construye el concepto como un módulo controlador: una sola variable (progreso de desplazamiento, tiempo, puntero, capítulo) mapeada a cada elemento visual que transporta el concepto, para que siempre estén de acuerdo. Dale una entrada inactiva para que el concepto mantenga un pequeño movimiento en reposo. Ver references/patterns.md. Si el plan tiene una figura explicativa, invoca la habilidad anatomy para esa sección con el briefing de references/anatomy.md, luego ajústala a la paleta, la cuadrícula y el reloj único como describe ese archivo.
6. Autor de los momentos de continuidad: cargador (solo si el briefing lo merece), transición de página, introducción del héroe (data-intro). Estas son las primeras cosas que cualquiera ve, por lo que deben expresar el concepto, no los valores predeterminados del motor.
7. Páginas requeridas: inicio, al menos un tipo de página interior (caso de estudio, acerca de, producto) y un 404 diseñado. Los portafolios obtienen una página de caso de estudio por proyecto.
8. Imágenes: primero los activos del usuario, luego una herramienta de generación de imágenes si está disponible. De lo contrario, usa cubiertas GL procedimentales (arte generativo honesto) o composiciones tipográficas. Nunca construyas capturas de pantalla falsas con divs. Cuando el trabajo en sí ES imágenes (fotógrafo, ilustrador, arquitecto) y no se proporcionó ninguna, selecciona fotos de licencia gratuita como marcadores de posición marcados:
   • Ejecuta node $SKILL/scripts/photos.mjs sheet para obtener hojas de contacto de aproximadamente 1000 fotos de Unsplash con identificadores.
   • Lee las hojas y elige un ojo coherente (una serie que parezca tomada por una sola persona).
   • Ejecuta node $SKILL/scripts/photos.mjs get <ids> --dir <assets dir>.
   • Acredita a los autores en un colofón y marca cada foto para reemplazo.

Fase 4: Bucle de QA (mínimo dos pases completos)

Siempre realiza QA en una compilación de producción, no en el servidor de desarrollo:

# Next.js:  npm run build && npx next start -p 4400        (ejecutar en segundo plano)
# Astro:    npm run build && node $SKILL/scripts/serve.mjs dist --port 4400
node $SKILL/scripts/shoot.mjs http://127.0.0.1:4400/ --crawl --nav   # capturas de pantalla, métricas vitales, axe, teclado, hover
node $SKILL/scripts/audit.mjs http://127.0.0.1:4400/ > .shots/audit.txt   # SEO/meta/a11y/peso/marcadores de posición/indicios

• Si shoot.mjs informa que no hay Chromium, ejecuta npx playwright install chromium una vez.
• --crawl toma una foto de cada tipo de página (inicio, cada página de nivel superior, una página de caso por colección) más el 404, cada una hasta el final, en .shots/<page>/. Las páginas interiores y los estados finales ocultan los peores errores. Pasa una sola URL sin --crawl para volver a tomar una página mientras la arreglas.
• Mira cada captura de pantalla: escritorio, móvil, movimiento reducido, foco de teclado (k-*), hover (h-*) y fotogramas de transición. Lee .shots/summary.json, luego cada report.json, para:
  • errores de consola y solicitudes fallidas
  • desbordamiento, objetivos táctiles pequeños y texto oculto bajo movimiento reducido
  • tiempo de cargador, LCP y CLS (mobile.vitals se mide en un teléfono de gama media limitado y es el número que cuenta)
  • FPS de desplazamiento en escritorio y en el teléfono limitado
  • a11y: violaciones de axe, incluido el contraste con las relaciones medidas
  • keyboard: orden de tabulación, si un enlace de omisión aparece primero, foco sin estilo visible y foco que aterriza en elementos invisibles
  • hover: cómo reacciona cada objetivo del puntero (moves, color, pixels, masked cuando un sombreado en vivo lo oculta, o none, con las propiedades que cambiaron) y su par recortado h-NN-rest / h-NN-hover; colorOnly (objetivos principales cuyo hover es solo un intercambio de color), noHoverChange y covered (objetivos sobre los que se sentó otra cosa)
  • desktop.idleMotion y idleAt: si algo se mueve mientras el puntero está quieto, y dónde se encontró
• Ejecuta la lista de verificación de fallos en references/quality.md.
• Si hay una figura de anatomía, ejecuta también sus propias comprobaciones y lee la figura en cada captura de pantalla (ver references/anatomy.md, QA).
• Obtén una puntuación externa. Sabes lo que querías construir, por lo que ves la intención en lugar de lo que hay en pantalla. Si puedes lanzar un subagente, dale a uno nuevo el brief del crítico en references/quality-bar.md, con las rutas a .shots/ y la salida de la auditoría. No le des DESIGN.md, el código ni tu propia opinión. Lanza un nuevo crítico en cada pase, para que nunca se ancle en una puntuación anterior. Si no puedes lanzar subagentes, puntúalo tú mismo siguiendo el mismo brief, solo a partir de las capturas de pantalla y antes de volver a leer DESIGN.md.
• Trata la lista de correcciones del crítico como el trabajo para el siguiente pase. Si la lectura de una línea de la idea por parte del crítico no coincide con la Ficha de Concepto, el concepto no se transmite en pantalla. Eso es un problema de Creatividad para arreglar en el sitio, no en la lectura del crítico. No discutas una puntuación al alza; impugna una solo señalando una captura de pantalla que el crítico haya leído mal.
• Repite hasta que tengas:
  • cero FALLOS de auditoría y cero errores de consola
  • sin desbordamiento horizontal
  • sin texto oculto bajo movimiento reducido
  • cero violaciones graves o críticas de axe, y cada parada de foco visible
  • noHoverChange vacío, y cada par colorOnly, pixels y masked leído a ojo: un relleno que inunda o invierte todo el botón es un tratamiento; un enlace principal cuyo texto solo cambia de color no lo es
  • idleMotion verdadero, o una página estática anotada como decisión en DESIGN.md
  • LCP móvil inferior a 2.5 s y CLS inferior a 0.05

...

[truncado para traducción]