Diseño de Sitios Web

¿Qué hace Diseño de Sitios Web?

Un pipeline que transforma cualquier agente de IA, incluidos modelos pequeños o débiles, en uno que crea y despliega sitios web de primer nivel, estéticos y llenos de funciones. Cada fase produce un artefacto con nombre que la siguiente fase relee, por lo que ninguna decisión se vuelve a tomar ni se pierde. Actívalo mediante las convenciones del skill; cada descripción es una cadena entre comillas en una sola línea.

Artefactos del pipeline (memoria de trabajo): DESIGN BRIEF (audiencia, estilo, diales) → DIRECTION (estilo, paleta, tipografía, permitido/prohibido) → TOKENS (propiedades CSS personalizadas canónicas, modo oscuro) → SECTION MAP (secciones ordenadas con ranuras de título/cuerpo/activo/CTA) → DEPLOY SPEC (host, tipo, URL, rollback).

Patrón de enrutamiento: Pipeline + Facetas

Pipeline (en orden, nunca saltar una fase):

1. briefing - extrae el DESIGN BRIEF del mensaje del usuario, enlaces, capturas de pantalla, repo.
2. direction - elige estilo, paleta, tipografía ANTES de cualquier HTML o CSS.
3. system - convierte DIRECTION en TOKENS y configura el tema/modo oscuro.
4. structure - convierte TOKENS y DIRECTION en el SECTION MAP.
5. components - construye cada sección a partir de recetas de bloques (hijos: navegación, héroes, secciones de características, prueba social, conversión, formularios).
6. content - llena cada ranura del SECTION MAP con contenido real y activos reales.
7. motion - especificaciones de animación por sección desde el dial MOTION.
8. quality - puertas solo de revisión: anti-slop, accesibilidad, rendimiento, auditoría, producción, preflight (puerta final).
9. deploy - elige host: higgsfield o genérico.

Facetas (puntos de entrada, no fases):

• El sitio ya existe (URL, repo, archivos) → comienza en redesign ANTES del briefing, luego reingresa al pipeline.
• Las hojas quality/* son solo de revisión; cárgalas al verificar, no al construir.
• version-control se ejecuta JUNTO a cada fase: confirma cada artefacto a medida que se produce. Trabajar en un repositorio de sitio gestionado por webdev (WEBSITES/) hace que esto sea obligatorio.

Hijos

• briefing - siempre primero para nuevas construcciones; produce DESIGN BRIEF con diales VARIANCE/MOTION/DENSITY.
• direction - estilo, paleta, tipografía mediante búsqueda verificada ui-ux-pro-max; produce DIRECTION.md.
• system - tokens canónicos, tema, modo oscuro; produce TOKENS.
• structure - secciones ordenadas y recuentos de ranuras; produce SECTION MAP.
• components - recetas de bloques por tipo de sección; carga una hoja por sección.
• content - contenido real, imágenes reales, sin relleno; produce CONTENT.
• motion - especificaciones de animación, esqueletos GSAP, rutas de movimiento reducido.
• preflight - puerta final; consulta a todos los hermanos de calidad, luego pasa a deploy.
• deploy - enrutador de alojamiento: higgsfield (sitio web/app/juego) o host estático genérico; produce DEPLOY SPEC.
• redesign - entrada de auditoría primero cuando ya existe un sitio.
• version-control - disciplina git en todas las fases; nunca dejes trabajo sin confirmar.

Navegación (solo enrutador raíz)

• Salta: ¿conoces la fase? Carga ese hijo directamente; nunca cargues todo el árbol.
• Camina: solo cuando la decisión en sí no esté clara; lee un enrutador a la vez.
• Anuncia la fase bajo la que estás operando; cuando cambie, dilo.
• Reenruta: si la hoja cargada contradice la tarea, regresa aquí y elige de nuevo; nunca improvises una hoja.
• Delega ramas amplias a un subagente con la ruta del hijo y una tarea dividida; solo se carga ese subárbol.
• Techo: una hoja nunca excede las reglas de su ancestro; este archivo gana en conflictos.

Convenciones

Promovido desde _build/plan-expanded.md; vinculante para cada nodo en el subárbol.

• Prueba para modelos débiles: tablas de decisión, números concretos ("padding 96-128px", nunca "generoso"), 3-8 verificaciones de pasa/falla por hoja que sean contables y greppable. Explica en una línea para que los modelos más inteligentes generalicen; la regla mecánica se sostiene por sí sola.
• Base en la materia: cada elección estética se ancla al tema concreto, la audiencia y el trabajo principal (industria, materiales, lenguaje vernáculo). Una juguetería para niñas de 8-11 años y una herramienta para analistas financieros deben divergir. Contenido REAL en todas partes; cuando falte contenido, propón texto concreto a través de briefing y confírmalo.
• Independiente del idioma: los principios viven en HTML semántico + CSS en references/stack-adapters.md. Nunca dependas de React, Tailwind ni ningún framework.
• Tokens canónicos: definidos en system, usados en todas partes: --bg --surface --text --text-muted --accent --accent-contrast --border --destructive, --radius --radius-lg, --font-display --font-body --font-mono, --space-1..--space-10 (4 8 12 16 24 32 48 64 96 128), --container, --shadow-1 --shadow-2.
• Diales de briefing: enteros 1-10, nombres exactos VARIANCE (1 mínimo, 10 asimétrico/artístico), MOTION (1 estático, 10 cinematográfico), DENSITY (1 disperso, 10 denso). Nunca inventes nuevos diales.
• Protocolo ui-ux-pro-max: las elecciones de dirección/sistema se verifican contra los datos de estilo/paleta/tipografía del paquete; si los resultados están vacíos, recurre a tablas integradas y dilo.
• Cinco artefactos viajan como bloques delimitados, se releen por nombre, nunca de memoria.
• Frontmatter: name: coincide con el directorio, description: cadena de activación entre comillas en una sola línea.
• Estilo: sin guión largo (usa guión o punto), sin emojis, las prohibiciones absolutas viven SOLO en anti-slop, enlaces cruzados a hermanos con ruta relativa a la raíz (heroes).

No negociables

• Sin guión largo en ningún nodo; el detector de la hoja anti-slop lo busca.
• Sin logotipos, testimonios, estadísticas ni imágenes de marca fabricados; content propone, el usuario confirma.
• Sin tokens de marcador de posición; cada sección se renderiza a través del conjunto de tokens canónicos.
• Sin mezcla de sistemas de diseño: una familia de estilo, una paleta, una combinación tipográfica por construcción.
• Sin artefactos sin confirmar: version-control confirma la salida de cada fase antes de que comience la siguiente.
• Sin despliegue sin que preflight pase.
• Los gráficos están explícitamente fuera del alcance de este skill. Para visualización de datos (25 tipos de gráficos en ui-ux-pro-max), consulta python ~/.agents/skills/ui-ux-pro-max/scripts/search.py "<forma de los datos>" --domain chart en lugar de improvisar cuadrícula + barras.