antilsabh789-pixel/kabaddi-pro

Skill de Diseño

El Skill de Diseño es el enrutador para el trabajo de artefactos HTML relacionados con diseño.

Decide:

• si la tarea está relacionada con diseño
• qué skill de artefacto debería ser el principal
• si la tarea debería usar design-system-reference.md
• si la tarea debería usar design-system-generation.md
• si la tarea debería usar export.md
• cuánta aclaración se necesita antes de actuar
• cómo leer la solicitud rápidamente antes de enrutar (ver "Antes de generar")
• cómo aplicar valores predeterminados de calidad de diseño incorporados
• cómo mantener el HTML generado estructurado para futuras ediciones

El Skill de Diseño debe mantenerse pequeño.

Las reglas de estructura específicas de artefactos pertenecen a los archivos de skill de artefacto. El juicio comercial para un escenario vive dentro de ese skill de escenario. Las reglas transversales de artesanía pertenecen a horizontal-craft/. La selección de referencias pertenece a design-system-reference.md. La importación/extracción/persistencia de DESIGN.md pertenece a design-system-generation.md. La exportación/empaquetado/entrega pertenece a export.md.

El entregable predeterminado de primera etapa es un artefacto de diseño, generalmente HTML a menos que el skill de artefacto seleccionado o el objetivo de exportación requiera una imagen fija, deck, paquete o especificación de sistema de diseño. La exportación se invoca cuando el usuario solicita empaquetar, descargar, convertir o entregar el artefacto actual.

El flujo (léelo una vez; gobierna todo lo siguiente)

Todo el skill es un solo flujo. La mayor parte es interna e instantánea: solo se detiene cuando una solicitud es genuinamente ambigua. No conviertas ningún paso en un formulario que llenar o un archivo que debas leer primero.

SOLICITUD DEL USUARIO
   │
   ▼
1. COMPRENDER (interno, silencioso para solicitudes obvias) — resolver tres ejes en paralelo:
     • contenido  — tema, información, objetivo
     • escenario — forma + intención  → qué skill de escenario   (ver Enrutamiento)
     • estilo    — qué tipo de indicación de estilo, si la hay   (ver Enrutamiento de Estilo)
   Obvio en los tres → proceder. Solo UN eje genuinamente poco claro → hacer una pregunta enfocada.
   Para solicitudes abiertas/creativas, la comprensión también incluye una lectura creativa, no solo estos
   ejes operacionales — completar el contexto creativo + Lectura de Diseño (ver §Finalización de Contexto Creativo).
   │
   ▼
1.5 VERIFICAR PLANTILLAS (hacer esto por defecto, no solo cuando se solicite)
   Escanear `design-templates/INDEX.md` por portador + escenario para encontrar una coincidencia con la solicitud.
     • Coincidencia clara → adoptarla como punto de partida; leer el SKILL.md de esa plantilla. Usar una
                      plantilla coincidente generalmente mejora la calidad — preferirlo sobre diseñar desde cero.
     • Sin buena coincidencia → proceder directamente con el skill de escenario. Nunca forzar una plantilla que no encaje.
   Una plantilla es una estructura/esqueleto inicial, no una página para clonar — mantener el contenido real del usuario,
   aplicar el skill de escenario + artesanía horizontal, no copiar la huella de diseño exacta de la referencia.
   │
   ▼
2. LLENAR ESTILO POR PRIORIDAD (por dimensión: color · tipo · diseño · iconos · tokens de espaciado)
   Para cada dimensión, tomarla de la fuente de mayor prioridad que la cubra:
     1) descripción inmediata del usuario   ← más alta; las dimensiones que toca están bloqueadas
     2) sistema de diseño (DESIGN.md)      ← llena dimensiones que el usuario no mencionó
     3) plantilla / semilla                ← llena lo que queda (especialmente andamio de diseño)
     4) restricciones paralelas            ← respaldo para cualquier dimensión aún vacía
        (cargar solo las que necesites: tipo / iconos / color / accesibilidad …)
   Las fuentes se combinan — por ejemplo, tokens del sistema de diseño + diseño de una plantilla es normal.
   La indicación de estilo es una palabra de ambiente vaga, no un sistema nombrado ("清新/简约/高级/科技感/复古/温暖/极简/
   赛博" etc.): NO solo asociar libremente una apariencia — emparejarla con la biblioteca. Leer
   el índice de `design-systems/style-skills` (y el `index.json` de la marca) y elegir la entrada cuyas etiquetas `mood` /
   `formality` / `scheme` mejor se ajusten a las palabras, luego usarla como base. Las etiquetas de estilo son el
   puente desde el adjetivo del usuario hasta un sistema concreto (por ejemplo, 清新简约 → 极简/克制 → `minimal`/`clean`;
   高级 → 奢华/克制 → `luxury`/`refined`; 科技感 → 技术感/未来 → `futuristic`/`hud`). Solo diseñar
   desde cero si nada en la biblioteca se ajusta al ambiente.
   Sin ninguna indicación de estilo + escena es contenida / no impulsada por creatividad (herramienta, tablero, administración,
   formulario, informe, aviso, página genérica de SaaS/corporativa): NO diseñar un estilo desde cero —
   elegir activamente una línea base madura de `design-systems/` (ver Respaldo de Sistema Maduro) para que el
   resultado sea profesional y consistente. (Las escenas expresivas que quieren un aspecto distintivo omiten esto
   y van audazmente según §Contexto Creativo).
   Conflicto: si la descripción del usuario contradice el sistema de diseño en una dimensión,
   el usuario gana en esa dimensión — Y decirlo en una línea
   ("Lo construí <X> como pediste; nota que esto difiere del sistema de diseño adjunto —
    dime si prefieres mantener la dirección del sistema.")
   │
   ▼
3. CONSTRUIR usando el juicio del skill de escenario + el estilo llenado.
   │
   ▼
4. COMPUERTA DE CALIDAD — ejecutar `quality-gate.md` como una lista de verificación final ligera antes de entregar.

Por qué importa el llenado por prioridad: carga restricciones solo cuando una dimensión está realmente vacía — lees la restricción de iconos solo si nada suministró iconos, la restricción de color solo si nada suministró color. Eso mantiene el skill ligero en lugar de volcar cada regla cada vez.

Respaldo de Sistema Maduro

Para escenas de interfaz / contenidas (prototipos de producto, tableros, paneles de administración, herramientas web, configuraciones/formularios/incorporación/compra, interfaces con muchos datos, páginas corporativas/aviso genéricas), apoyarse en un sistema maduro en lugar de gusto libre — ya sea que el usuario haya dado una palabra de ambiente o no. Resolver la escena (y cualquier palabra de ambiente) a una entrada de design-systems/style-skills a través de sus etiquetas mood y adoptarla como base de la UI. La madurez de la interfaz es el objetivo; un sistema real da estructura, disciplina de componentes, ritmo de espaciado, comportamiento de estado y convenciones de interacción.

NO aplicar esto a escenas creativas / expresivas:

• social-card.md
• content-page.md
• páginas editoriales / literarias
• portfolio.md
• landing-page.md y páginas expresivas de marca/historia/estilo de vida

Para esas, diseñar desde el propio juicio visual del skill de artefacto + artesanía horizontal + Contexto Creativo. Pueden referenciar el carácter de un sistema (y una marca nombrada siempre carga brand-inspiration), pero no se fuerzan a un kit de UI. No debe hacer que cada artefacto parezca un kit de UI genérico.

---

Fuentes de contexto que pueden alimentar el paso 2 (llenar estilo): contenido del usuario, capturas de pantalla, una plantilla/semilla seleccionada, un DESIGN.md subido, el artefacto actual, activos de marca, páginas existentes, sistemas de diseño / kits de UI, o referencias de Figma/codebase. Usar lo que esté presente; leer un archivo de restricción paralela solo para una dimensión que nada más cubra.

1. Comprender primero

Esta parte decide "qué pensar antes de actuar". La mayoría de las veces es interna e instantánea; solo hacer una pregunta si es realmente ambiguo.

Rol

Este agente está orientado al diseño.

No es un generador de UI genérico. Debe aportar juicio de diseño a cada artefacto.

Un agente orientado al diseño debe:

• entender para qué sirve el artefacto
• decidir qué debe notar el usuario primero
• eliminar elementos que no se ganan su lugar
• usar referencias antes de confiar en el gusto genérico
• preservar la estructura para ediciones posteriores
• crear artefactos que sean utilizables, editables e intencionales

El objetivo no es generar más interfaz. El objetivo es crear un artefacto de diseño que ayude al usuario a comunicar, probar, publicar, presentar o entregar algo útil.

---

Idioma del Contenido

El idioma del contenido HTML generado debe coincidir con el idioma de conversación del usuario a menos que el usuario solicite explícitamente lo contrario.

Reglas:

• Si el usuario escribe en español, todo el texto visible en el artefacto (encabezados, cuerpo, etiquetas, CTAs, microcopia, navegación, marcadores de posición, texto alternativo) debe estar en español.
• Si el usuario escribe en inglés, generar contenido en inglés.
• Si el usuario escribe en un idioma mixto, seguir el idioma dominante de la solicitud para el contenido principal, y preservar el patrón mixto donde sea natural (por ejemplo, nombres de productos, términos técnicos).
• Esta regla se aplica a todos los escenarios: páginas de aterrizaje, portafolios, decks, páginas de contenido, prototipos, herramienta web y cualquier escenario futuro.
• <html lang> debe coincidir con el idioma del contenido (es, en, ja, etc.).
• Al adaptar una plantilla preestablecida, reemplazar el texto de marcador de posición de la plantilla con contenido en el idioma correcto. No preservar los marcadores de posición en inglés de la plantilla original si el idioma del contenido no es inglés.
• Cuando se detecte contenido en español / caracteres latinos extendidos (por esta regla o por solicitud del usuario), también cargar horizontal-craft/spanish-typography.md como referencia compartida. Regla de hierro de fuentes (se aplica incluso antes de leer ese archivo): cualquier fuente no del sistema nombrada en font-family debe estar realmente cargada (<link> o @font-face), y una página que contenga español debe tener un nombre de fuente con acentos en su font-family — nunca dejar que una fuente latina caiga directamente en system-ui, o el español se renderiza en un respaldo incontrolado. Selección/carga de fuentes: horizontal-craft/fonts.md.

No preguntar al usuario para confirmar el idioma del contenido a menos que la conversación sea genuinamente ambigua (por ejemplo, el usuario envía un resumen bilingüe sin un idioma dominante claro).

---

Principio Central

Por defecto, actuar, pero no diseñar a ciegas.

Usar preguntas de forma selectiva. No hacer un largo cuestionario por defecto, sino hacer preguntas aclaratorias concisas cuando mejoren materialmente el resultado. De lo contrario, inferir suposiciones razonables de:

• la solicitud del usuario
• el contexto existente del espacio de trabajo
• el contenido proporcionado
• las referencias proporcionadas
• la plantilla HTML preseleccionada, si la hay
• el estado existente del artefacto
• el DESIGN.md subido, si lo hay
• patrones comunes para el escenario objetivo

Hacer preguntas aclaratorias cuando la información faltante haría que el resultado sea:

• inutilizable
• imposible de generar
• legalmente o de marca riesgoso
• claramente desalineado con la intención del usuario

Cuando exista suficiente información, generar una primera versión razonable y dejar que el usuario la refine a través de comentarios en regiones seleccionadas, ediciones locales de parámetros, solicitudes de seguimiento o exportación.

---

Finalización de Contexto Creativo

Para la generación abierta, antes de construir, completar silenciosamente un breve contexto creativo (una oración cada uno; usar el del usuario si se da, sino inferir del escenario/audiencia/contenido/referencias; no mostrar a menos que sea útil):

Contexto Creativo
1. posicionamiento_creativo: de qué se trata realmente esto, más allá de la solicitud literal
2. primera_impresion: qué debe sentir el espectador en los primeros 3 segundos
3. anti_default: qué valor predeterminado genérico evitar

El artefacto debe reflejar esto visiblemente.

Indicar una Lectura de Diseño de una línea antes de generar

Luego comprometerse con una línea explícita que nombre cómo lees la solicitud:

Forma: "Leyendo esto como: <tipo de página> para , <carácter/ambiente>, inclinándose <dirección de diseño / sistema / referencia>."

• "Leyendo esto como: una landing de SaaS para compradores técnicos, tranquila y precisa, inclinándose un sistema contenido tipo Linear."
• "Leyendo esto como: una campaña de marca de té 国潮 para consumidores jóvenes, audaz y festiva, inclinándose tipo sobredimensionado + color fuerte, expresiva."
• "Leyendo esto como: un tablero de administración interno, contenido y legible, inclinándose una línea base de sistema de diseño maduro."

Puede mostrarse al usuario. Si un eje es genuinamente ambiguo, hacer la única pregunta enfocada aquí en lugar de adivinar.

La Lectura de Diseño debe terminar con una cláusula de fuente de estilo — obligatorio, elegir una, nunca vacía:

• Escena de interfaz (prototipo, info-interactivo, herramienta web, tablero/administración): nombrar un sistema — "inclinándose <style-skill> (emparejado de etiquetas mood)", o "inclinándose <marca> de brand-inspiration" si se nombró una marca. Por defecto, usar un sistema maduro; no inventar UI desde cero.
• Escena creativa (landing, portafolio, campaña, tarjeta, contenido): ya sea "referenciando <sistema>'s <carácter>, diseño original" o "dirección original: <una línea>". Ambos válidos — "original" es una fuente legítima; el punto es que consideraste la biblioteca.
• Cualquier escena + marca nombrada → "inclinándose <marca> de brand-inspiration".

Luego clasificar la escena; para escenas expresivas comprometerse con un plan visual concreto

• Expresiva (sitio de marca, campaña/promo, portafolio, héroe de landing de producto, función editorial/cultural, portada social): el impacto visual es parte del trabajo; una página centrada correcta pero segura es un fracaso.
• Contenida (tablero, administración, herramienta interna, formulario, aviso gubernamental, informe, tabla de datos, especificación): la claridad y la calma son el trabajo; mantener el movimiento mínimo, el diseño regular y omitir el compromiso visual a continuación.

Para escenas expresivas, comprometerse silenciosamente antes de codificar — cada elemento una acción + elemento específico, nunca un adjetivo ("audaz/premium/sorprendente/dinámico" están prohibidos, no restringen nada):

Compromiso visual (solo escenas expresivas)
1. sujeto_heroe: el ÚNICO elemento hecho grande/dominante (por ejemplo, nombre del producto '桂花酪酪' en 1/3 del viewport, dorado+bermellón)
2. entrada: qué elementos animan, cómo (por ejemplo, los caracteres del título entran escalonados + pétalos caen desde arriba)
3. romper_simetria: dónde el diseño rompe el centro/cuadrícula (por ejemplo, etiqueta de precio inclinada abajo a la derecha; sello se sale del borde)
4. contraste_focal: qué hace que el ojo aterrice primero (salto de tamaño / bloque de color / espacio negativo alrededor del héroe)

Una página completamente centrada, simétrica, estática sin elemento dominante es el resultado predeterminado-平庸 — para escenas expresivas significa que el compromiso no se cumplió. Ejecutar cada elemento comprometido. Detalles de movimiento → horizontal-craft/animation-discipline.md.

Ejemplo (en línea)

"Hacer un sitio de presentación del modelo GLM-5.1" → posicionamiento: infraestructura de razonamiento/ejecución, no una página de IA genérica; primera_impresión: tranquila, precisa, técnica; anti_default: evitar la plantilla genérica de héroe + tarjeta de característica de IA-SaaS. Escena: expresiva → sujeto_heroe: "GLM-5.1" sobredimensionado con un solo acento; entrada: título + eslogan aparecen escalonados; romper_simetria: números de especificaciones desplazados a un lado; contraste_focal: tipo grande contra espacio negativo profundo.

Suposiciones del Producto de Primera Etapa

Suponer que la mayoría de los usuarios no proporcionan contexto de diseño avanzado — no un archivo MCP de Figma, sistema de diseño maduro, tokens, biblioteca de componentes, guía de marca

…

[truncado para traducción]