AiCurv/ADBCommander

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 el diseño
• qué skill de artefacto debe ser el principal
• si la tarea debe usar design-system-reference.md
• si la tarea debe usar design-system-generation.md
• si la tarea debe 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 los 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 reside dentro de ese skill de escenario. Las reglas transversales de artesanía pertenecen a horizontal-craft/. La selección de referencia 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, presentación, 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 que sigue)

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 para llenar o un archivo que debas leer primero.

SOLICITUD DEL USUARIO
   │
   ▼
1. COMPRENDER (interno, silencioso para solicitudes obvias) — resuelve 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 → continuar. 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 operativos — completar el contexto creativo + Lectura de Diseño (ver §Finalización del Contexto Creativo).
   │
   ▼
1.5 VERIFICAR PLANTILLAS (hacer esto por defecto, no solo cuando se solicite)
   Escanear `design-templates/INDEX.md` por portador + escenario para una coincidencia con la solicitud.
     • Coincidencia clara → adoptarla como punto de partida; leer el SKILL.md de esa plantilla. Usar una
                      plantilla coincidente generalmente aumenta la calidad — preferirla sobre diseñar desde cero.
     • Sin buena coincidencia → continuar directamente con el skill de escenario. Nunca forzar una plantilla que no encaje.
   Una plantilla es una estructura/esqueleto de inicio, no una página para clonar — mantener el contenido real del usuario,
   aplicar el skill de escenario + la artesanía horizontal, no copiar la huella de diseño exacta de la referencia.
   │
   ▼
2. LLENAR ESTILO POR PRIORIDAD (por dimensión: color · tipografía · 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   ← la más alta; las dimensiones que toca están bloqueadas
     2) sistema de diseño (DESIGN.md)      ← llena las dimensiones que el usuario no mencionó
     3) plantilla / semilla                ← llena lo que queda (especialmente el 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 — p. ej., tokens del sistema de diseño + el diseño de una plantilla es normal.
   La indicación de estilo es una palabra de ambiente vaga, no un sistema nombrado ("清新/简约/高级/科技感/复古/温暖/极简/
   赛博" etc.): NO asociar libremente un aspecto — emparejarlo con la biblioteca. Leer
   `design-systems/style-skills` índice (y `index.json` de la marca) y elegir la entrada cuyas etiquetas `mood` /
   `formality` / `scheme` se ajusten mejor a las palabras, luego usarla como base. Las etiquetas de estilo son el
   puente desde el adjetivo del usuario a un sistema concreto (p. ej., 清新简约 → 极简/克制 → `minimal`/`clean`;
   高级 → 奢华/克制 → `luxury`/`refined`; 科技感 → 技术感/未来 → `futuristic`/`hud`). Solo diseñar
   desde cero si nada en la biblioteca se ajusta al ambiente.
   Sin indicación de estilo en absoluto + la escena es comedida / no impulsada por la creatividad (herramienta, panel de control, administración,
   formulario, informe, aviso, SaaS genérico/página corporativa): NO diseñar un estilo desde cero —
   seleccionar 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 desean un aspecto distintivo omiten esto
   y van audaces 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
   ("Construido con <X> como solicitaste; ten en cuenta 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. CONTROL DE CALIDAD — ejecutar quality-gate.md como una lista de verificación final breve antes de entregar.

Por qué es importante 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 / comedidas (prototipos de productos, paneles de control, paneles de administración, herramientas web, configuraciones/formularios/incorporación/finalización de compra, interfaces con muchos datos, páginas corporativas/avisos genéricas), apoyarse en un sistema maduro en lugar del 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 la base de la interfaz de usuario. La madurez de la interfaz es el objetivo; un sistema real proporciona 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 las empuja hacia un kit de interfaz de usuario. No debe hacer que cada artefacto parezca un kit de interfaz de usuario 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 interfaz de usuario, o referencias de Figma/base de código. 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 sección decide "qué pensar antes de hacer algo". En la mayoría de los casos, internalizado e instantáneo; solo preguntar si es realmente ambiguo.

Rol

Este agente está orientado al diseño.

No es un generador de interfaz de usuario 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 la conversación del usuario a menos que el usuario lo solicite explícitamente de otra manera.

Reglas:

• Si el usuario escribe en chino, todo el texto visible en el artefacto (encabezados, cuerpo del texto, etiquetas, CTA, microcopia, navegación, marcadores de posición, texto alternativo) debe estar en chino.
• 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 (p. ej., nombres de productos, términos técnicos).
• Esta regla se aplica a todos los escenarios: páginas de aterrizaje, portafolios, presentaciones, páginas de contenido, prototipos, herramientas web y cualquier escenario futuro.
• <html lang> debe coincidir con el idioma del contenido (zh-CN, 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 conservar los marcadores de posición originales en inglés de la plantilla si el idioma del contenido no es inglés.
• Cuando se detecte contenido en chino / CJK (por esta regla o por solicitud del usuario), también cargar horizontal-craft/chinese-typography.md como referencia compartida. Regla férrea de fuentes (se aplica incluso antes de leer ese archivo): cualquier fuente que no sea del sistema nombrada en font-family debe cargarse realmente (<link> o @font-face), y una página que contenga chino debe tener un nombre de fuente CJK en su font-family — nunca permitir que una fuente latina caiga directamente en system-ui, o el chino se renderizará en un respaldo incontrolado. Detalle de selección/carga de fuentes: horizontal-craft/fonts.md.

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

---

Principio fundamental

Actuar por defecto, pero no diseñar a ciegas.

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

• la solicitud del usuario
• el contexto del espacio de trabajo existente
• el contenido proporcionado
• las referencias proporcionadas
• la plantilla HTML preestablecida seleccionada, si la hay
• el estado del artefacto existente
• 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:

• no sea utilizable
• sea imposible de generar
• sea legalmente o de marca riesgoso
• esté claramente desalineado con la intención del usuario

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

---

Finalización del Contexto Creativo

Para generación abierta, antes de construir, completar silenciosamente un contexto creativo breve (una oración cada uno; usar la del usuario si se proporciona, de lo contrario 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_impresión: qué debe sentir el espectador en los primeros 3 segundos
3. anti_predeterminado: qué predeterminado genérico evitar

El artefacto debe reflejar esto visiblemente.

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

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

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

• "Lectura como: un SaaS de aterrizaje para compradores técnicos, tranquilo y preciso, apoyándose en un sistema tipo Linear comedido."
• "Lectura como: una campaña de té 国潮 para consumidores jóvenes, audaz y festiva, apoyándose en tipografía sobredimensionada + color fuerte, expresiva."
• "Lectura como: un panel de administración interno, comedido y legible, apoyándose en 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 en blanco:

• Escena de interfaz (prototipo, información interactiva, herramienta web, panel de control/administración): nombrar un sistema — "apoyándose en <style-skill> (emparejado por etiquetas de mood)", o "apoyándose en <brand> de brand-inspiration" si se nombró una marca. Predeterminar a un sistema maduro; no inventar interfaz de usuario desde cero.
• Escena creativa (aterrizaje, portafolio, campaña, tarjeta, contenido): ya sea "referenciando el <carácter> de <sistema>, diseño original" o "dirección original: <una línea>". Ambas válidas — "original" es una fuente legítima; el punto es que se consideró la biblioteca.
• Cualquier escena + marca nombrada → "apoyándose en <brand> de brand-inspiration".

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

• Expresiva (sitio de marca, campaña/promoción, portafolio, héroe de página de aterrizaje de producto, característica editorial/cultural, portada social): el impacto visual es parte del trabajo; una página centrada correcta pero segura es un fracaso.
• Comedida (panel de control, 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 específica, nunca un adjetivo ("audaz/premium/sorprendente/dinámico" están prohibidos, no restringen nada):

Compromiso visual (solo escenas expresivas)
1. sujeto_héroe: el ÚNICO elemento que se hace grande/dominante (p. ej., el nombre del producto '桂花酪酪' a 1/3 de la ventana, oro+cinabrio)
2. entrada: qué elementos entran con animación, cómo (p. ej., caracteres del título escalonados + pétalos caen desde arriba)
3. romper_simetría: dónde el diseño rompe el centro/cuadrícula (p. ej., etiqueta de precio inclinada abajo a la derecha; sello se desborda del borde)
4. contraste_focal: qué hace que el ojo aterrice primero (salto de tamaño / bloque de color / espacio en blanco alrededor del héroe)

Una página completamente centrada, simétrica, estática sin un 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)

"做一个 GLM-5.1 模型介绍网站" → posicionamiento: infraestructura de razonamiento/ejecución, no una página de IA genérica; primera_impresión: tranquilo, preciso, técnico; anti_predeterminado: evitar la plantilla genérica de héroe + tarjeta de características de IA-SaaS. Escena: expresiva → sujeto_héroe: "GLM-5.1" sobredimensionado con un solo acento; entrada: título + eslogan escalonados con desvanecimiento ascendente; romper_simetría: números de especificación desplazados a un lado; contraste_focal: tipografía grande contra espacio negativo profundo.

Suposiciones del Producto de Primera Etapa

Asumir 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]