name: tw-design-system

description: Adapta cualquier diseño (imagen, Figma, HTML, documento, sistema de diseño) al core propio de Tailwind CSS v4 de ELAN-SK (colores semánticos por rol, tipografía responsive con clamp, containers estilo Bootstrap, utilidades en rem, botones/atómicos con @apply), lo instala correctamente según el framework o CMS del proyecto (WordPress + Vite, React/Vite, Next.js, Tauri, u otro), y genera una plantilla/página de prueba visual real con todos los elementos. Úsala también SIEMPRE que se cree o edite cualquier componente, botón, sección o estilo en un proyecto que ya tenga este core instalado, no solo al importar un diseño completo. Nunca sugerir colores literales, media queries manuales para texto o clases base de Tailwind cuando exista un equivalente semántico del core. Dispara con menciones de "sistema de diseño", "design system", "core TWCSS/Tailwind", "adaptar este diseño/Figma/imagen a mi stack", "página de test de estilos", o al trabajar con el stack de ELAN-SK en general.

Adaptador de Design System → Core TWCSS de ELAN-SK

Qué hace esta skill

Toma un diseño de cualquier origen (imagen, capturas, Figma, HTML/CSS suelto, documento) y lo traduce al core CSS propio del usuario, manteniendo su arquitectura de tokens (assets/core/), lo instala en el proyecto correspondiente y entrega una prueba visual real y funcional. También actúa como guardrail de estilo permanente: cualquier componente que se cree después en un proyecto con este core debe seguir sus reglas.

Antes de escribir código, leer siempre references/philosophy.md (reglas condensadas). Los demás archivos de references/ se consultan según la etapa del flujo.

Flujo de trabajo

1. Identificar el input

Puede ser imagen, Figma (si el usuario tiene el conector, úsalo directo), HTML/CSS o un documento de texto con tokens.

Extraer:

2. Identificar el proyecto destino

Si no es evidente por el contexto de la conversación o archivos ya vistos, preguntar:

¿WordPress, Drupal, Wagtail, React, Next.js, Tauri u otro?

Si ya se detectó antes en la conversación (por ejemplo mediante package.json, Cargo.toml o la estructura de carpetas), no volver a preguntar.

• WordPress: leer references/frameworks/wordpress.md (usa assets/core/ con plugins JS).
• React / Vite SPA / Next.js / Tauri: leer references/frameworks/js-frameworks.md. Modelo unificado: utilizar siempre assets/core/ (con plugins JS) por defecto, igual que WordPress. assets/core-simple/ solo debe usarse como fallback excepcional (ver esa guía).
• Otro CMS: consultar la sección final de references/frameworks/js-frameworks.md.

3. Mapear la paleta a los roles fijos del core

Seguir references/color-mapping.md. Nunca inventar roles nuevos sin preguntar antes; el objetivo es encajar en los 9 colores + 3 fondos + 3 mensajes existentes.

4. Mapear tipografía

Utilizar las tres familias semánticas:

• font-serif → títulos.
• font-sans → texto e interfaz.
• font-mono → código y detalles.

Recalcular la escala (text-h1... text-small) con clamp() si cambian los tamaños objetivo.

Calculadora: https://elan-sk.github.io/calculadora-clamp-css/

Si existen nuevas fuentes de Google Fonts, importarlas según la guía del framework correspondiente.

5. Instalar o actualizar el core en el proyecto

• Si el proyecto no tiene el core, copiar assets/core/ completo a la ruta indicada por la guía del framework.
• Si ya existe, NO sobreescribir toda la carpeta. Editar solo:
  • plugins/variables.js
  • settings/_fonts.css
  • settings/_typography.css (si aplica)
  • settings/_containers.css (si aplica)
• Regenerar la safelist cuando el framework lo requiera.

6. Generar la prueba visual

Seguir references/test-page.md.

Nunca escribir CSS adicional. Generar siempre una plantilla o componente real del proyecto con las cuatro secciones:

1. Colors.
2. Typography.
3. Text Reset.
4. Buttons.

Usar exclusivamente las clases reales del core.

7. Confirmar con el usuario

Mostrar:

• Tabla de color original → rol asignado.
• Fuentes asignadas.
• Ubicación final de los archivos.
• La prueba visual.

Si algún color o rol no encaja correctamente, indicarlo explícitamente en vez de asignarlo de forma silenciosa.

Guardrail permanente (no solo al importar diseños)

Cuando se cree o modifique cualquier botón, card, formulario, sección o componente en un proyecto que ya utilice este core:

• Repasar mentalmente references/philosophy.md.
• Preferir extender los patrones @apply existentes (atoms/ y components/) antes que repetir utilidades.
• Si se crea un componente completamente nuevo (por ejemplo un acordeón), seguir el mismo patrón de atoms/_buttons.css:
  • Reset en @layer base.
  • Variantes en @layer components.
  • Usar únicamente roles de color y escalas existentes.

Referencias

• references/philosophy.md — reglas condensadas.
• references/color-mapping.md — mapeo de colores.
• references/frameworks/wordpress.md — instalación en WordPress.
• references/frameworks/js-frameworks.md — instalación en React, Vite, Next.js y Tauri.
• references/test-page.md — generación de la prueba visual.
• assets/core/ — core unificado con plugins JS.
• assets/core-simple/ — fallback solo CSS.
• assets/core/readme.md — documentación extensa.
• assets/wp-test-template/ — plantilla de prueba para WordPress.
• assets/react-next-test-template/ — plantilla de prueba para React y Next.js.