Cetc2211/AcTR-app

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 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 del artefacto 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 oficio 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/paquete/entrega pertenece a export.md.

El entregable de primera etapa predeterminado 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; rige 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 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 indicio de estilo, si lo hay           (ver Enrutamiento de Estilo)
   Obvio en los tres ejes → 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 operativos — completar el contexto creativo + Lectura de Diseño (ver §Finalización del Contexto Creativo).
   │
   ▼
1.5 VERIFICAR PLANTILLAS (hacerlo 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 aumenta la calidad — preferirla 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 de inicio, no una página para clonar — mantener el contenido real del usuario,
   aplicar el skill de escenario + oficio 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 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.
   El indicio de estilo es una palabra de estado de ánimo vaga, no un sistema nombrado ("清新/简约/高级/科技感/复古/温暖/极简/
   赛博" etc.): NO asocies libremente un aspecto — coincidir 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 (p. ej., 清新简约 → 极简/克制 → `minimal`/`clean`;
   高级 → 奢华/克制 → `luxury`/`refined`; 科技感 → 技术感/未来 → `futuristic`/`hud`). Solo diseñar
   desde cero si nada en la biblioteca se ajusta al estado de ánimo.
   Sin indicio de estilo + escena es contenida / no impulsada por creatividad (herramienta, panel, 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 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
   ("Construido <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 rellenado.
   │
   ▼
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 proporcionó iconos, la restricción de color solo si nada proporcionó 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 productos, paneles, paneles de administración, herramientas web, configuraciones/formularios/incorporación/pago, interfaces con muchos datos, páginas corporativas/notificaciones 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) en una entrada de design-systems/style-skills a través de sus etiquetas mood y adoptarla como base de UI. 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 estas, diseñar desde el propio juicio visual del skill de artefacto + oficio horizontal + Contexto Creativo. Pueden referenciar el carácter de un sistema (y una marca nombrada siempre carga brand-inspiration), pero no se les empuja hacia 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/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 parte decide "qué pensar antes de hacer qué". En la mayoría de los casos, se internaliza y completa al instante; solo se 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 primero el usuario
• 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 chino, todo el texto visible en el artefacto (encabezados, cuerpo del texto, etiquetas, CTA, microcopy, 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 (por ejemplo, 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), cargar también horizontal-craft/chinese-typography.md como referencia compartida. Regla de hierro 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 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

Predeterminar a la acción, 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
• los patrones comunes para el escenario objetivo

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

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

Cuando existe suficiente información, generar una primera versión razonable y dejar 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 da, si no 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é debería sentir el espectador en los primeros 3 segundos
3. anti_default:             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: "Lo leo como: <tipo de página> para , <carácter/ambiente>, inclinándose hacia <dirección de diseño / sistema / referencia>."

• "Lo leo como: una página de aterrizaje SaaS para compradores técnicos, calmada y precisa, inclinándose hacia un sistema tipo Linear contenido."
• "Lo leo como: una campaña de marca de té estilo 国潮 para consumidores jóvenes, audaz y festiva, inclinándose hacia tipografía sobredimensionada + color fuerte, expresiva."
• "Lo leo como: un panel de administración interno, contenido y legible, inclinándose hacia 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, info-interactivo, herramienta web, panel/administración): nombrar un sistema — "inclinándose hacia <style-skill> (coincidido por etiquetas de mood)", o "inclinándose hacia <brand> de brand-inspiration" si se nombró una marca. Predeterminar a un sistema maduro; no inventar UI 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 consideraste la biblioteca.
• Cualquier escena + marca nombrada → "inclinándose hacia <brand> 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 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.
• Contenida (panel, 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 es una acción específica + elemento, nunca un adjetivo ("audaz/premium/sorprendente/dinámico" están prohibidos, no restringen nada):

Compromiso visual (solo escenas expresivas)
1. tema_heroe:   el ÚNICO elemento hecho grande/dominante  (p. ej., nombre del producto '桂花酪酪' a 1/3 de la ventana gráfica, dorado+cinabrio)
2. entrada:       qué elementos animan al entrar, cómo       (p. ej., caracteres del título escalonados + pétalos cayendo desde arriba)
3. romper_simetria: dónde el diseño rompe el centro/cuadrícula      (p. ej., etiqueta de precio inclinada abajo a la derecha; sello sangra por el 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 no se honró el compromiso. Ejecutar cada elemento comprometido. Detalles de movimiento → horizontal-craft/animation-discipline.md.

Ejemplo (en línea)

"Hacer un sitio web 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: calmado, preciso, técnico; anti_default: evitar la plantilla genérica de héroe SaaS + tarjeta de características. Escena: expresiva → tema_heroe: "GLM-5.1" sobredimensionado con un solo acento; entrada: título + eslogan escalonados de aparición gradual; romper_simetria: números de especificación desplazados a un lado; contraste_focal: tipo grande contra espacio negativo profundo.

Suposiciones del Producto de Primera Etapa

Asumir que la mayoría de los usuarios no proporcionan un 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]