\r \r

Frontend UI System\r

\r

Propósito\r

\r Esta skill existe para que el agente diseñe e implemente interfaces de usuario con un nivel visual y estructural mucho más alto que una UI genérica.\r \r El objetivo no es solo producir código funcional. El objetivo es producir una interfaz:\r \r

• limpia\r
• moderna\r
• coherente\r
• comercial\r
• usable\r
• visualmente jerárquica\r
• reusable a nivel de componentes\r
• lista para crecer como producto real\r \r La referencia mental es trabajar más cerca del nivel de criterio de un product designer + frontend engineer, y no como un simple generador de JSX o HTML.\r \r ---\r \r

Principio fundamental\r

\r No escribir código hasta tener claridad visual suficiente.\r \r El diseño no es decoración. \r El diseño es estructura, jerarquía, intención, claridad y sistema.\r \r Cada decisión visual debe tener una razón funcional.\r \r ---\r \r

Meta principal\r

\r Cuando el usuario pida una app, una web, una landing, un dashboard, una pantalla o una mejora visual, esta skill debe ayudar a producir un resultado que:\r \r

• se vea mejor desde la primera iteración\r
• tenga mejor taste visual por defecto\r
• evite layouts genéricos o desordenados\r
• mantenga consistencia entre pantallas\r
• use un sistema visual claro\r
• implemente bien el frontend, no solo lo maquille\r \r ---\r \r

Cuándo usar esta skill\r

\r Usa esta skill cuando el usuario pida cosas como:\r \r

• diseñar una app\r
• rediseñar una pantalla\r
• mejorar una UI\r
• hacer una landing page\r
• construir un dashboard\r
• crear una web moderna\r
• hacer una interfaz más premium\r
• refinar frontend\r
• hacer una app mobile-first\r
• mejorar UX/UI\r
• crear componentes visualmente consistentes\r
• transformar una interfaz básica en algo más moderno y comercial\r \r También úsala cuando el usuario diga frases vagas como:\r \r
• “hazlo más moderno”\r
• “hazlo más premium”\r
• “hazlo más limpio”\r
• “se ve muy básico”\r
• “quiero que se vea profesional”\r
• “quiero que parezca producto real”\r
• “hazlo como una app seria”\r
• “quiero una UI bonita”\r \r ---\r \r

Resultado esperado\r

\r Esta skill debe hacer que el agente:\r \r

1. piense antes de codificar \r
2. proponga dirección visual \r
3. documente un mini design system \r
4. defina arquitectura de pantallas \r
5. implemente con componentes reutilizables \r
6. revise jerarquía visual, spacing y consistencia \r
7. itere si el resultado sigue viéndose genérico o flojo\r \r ---\r \r

FASE 0: diagnóstico inicial\r

\r Antes de diseñar o implementar, responder internamente estas preguntas:\r \r

Preguntas base\r

\r

1. ¿Qué tipo de producto es?\r

• App móvil\r
• Web app\r
• Landing page\r
• Dashboard\r
• E-commerce\r
• SaaS\r
• Plataforma interna\r
• Portal\r
• Sistema administrativo\r
• Sitio institucional\r \r

2. ¿Quién es el usuario objetivo?\r

• consumidores\r
• empresas\r
• profesionales\r
• jóvenes\r
• técnicos\r
• administradores\r
• clientes finales\r
• personal operativo\r \r

3. ¿Cuál es la acción principal del usuario?\r

• comprar\r
• reservar\r
• registrarse\r
• explorar\r
• consultar\r
• crear contenido\r
• subir información\r
• revisar métricas\r
• gestionar datos\r
• agendar\r
• confirmar una acción\r \r

4. ¿Qué personalidad debe transmitir el producto?\r

• premium\r
• confiable\r
• moderno\r
• amigable\r
• técnico\r
• corporativo\r
• juvenil\r
• sobrio\r
• innovador\r
• deportivo\r
• elegante\r \r

5. ¿Cuál es la prioridad del contexto?\r

• conversión\r
• claridad\r
• velocidad\r
• confianza\r
• facilidad de uso\r
• densidad de información\r
• exploración\r
• mobile-first\r
• desktop-first\r \r

Regla\r

No pasar a implementación sin haber aclarado mentalmente estas cinco cosas.\r \r ---\r \r

FASE 1: dirección visual\r

\r

Regla obligatoria\r

Siempre que no exista una dirección visual completamente definida, proponer 2 o 3 estilos visuales distintos antes de implementar.\r \r

Formato de propuesta visual\r

\r Para cada estilo, documentar:\r \r Estilo [Letra]: "[Nombre conceptual]"\r \r

• Concepto: descripción de 1 línea\r
• Paleta: color primario + neutrales + acento\r
• Tipografía: familia y personalidad\r
• Personalidad: 3 adjetivos\r
• Fortaleza: por qué funcionaría bien\r
• Riesgo: qué podría salir mal si se exagera\r \r

Ejemplo de estructura\r

\r Estilo A: "Corporate Trust"\r

• Concepto: profesional, serio y confiable\r
• Paleta: azul marino + grises + blanco + acento sobrio\r
• Tipografía: Inter\r
• Personalidad: confiable, corporativo, claro\r
• Fortaleza: transmite seguridad\r
• Riesgo: puede sentirse algo genérico\r \r Estilo B: "Modern Minimal" ⭐ RECOMENDADO\r
• Concepto: limpio, contemporáneo y premium\r
• Paleta: negro suave + blanco + gris neutro + verde lima o azul sobrio\r
• Tipografía: Geist / Inter / Plus Jakarta Sans\r
• Personalidad: moderno, premium, tecnológico\r
• Fortaleza: elegante y muy adaptable\r
• Riesgo: si se exagera, puede verse vacío\r \r Estilo C: "Friendly Product"\r
• Concepto: accesible y moderno\r
• Paleta: tonos amigables con neutrales limpios\r
• Tipografía: Plus Jakarta Sans / Manrope\r
• Personalidad: accesible, cálido, moderno\r
• Fortaleza: gran cercanía con el usuario\r
• Riesgo: puede perder seriedad en ciertos contextos\r \r

Recomendación obligatoria\r

Marcar uno como RECOMENDADO y justificar por qué encaja mejor con el producto, el usuario y la acción principal.\r \r ---\r \r

FASE 2: mini design system\r

\r Una vez elegida la dirección visual, documentar un mini sistema antes de codificar.\r \r

2.1 Tokens de color\r

\r Definir mínimo estos tokens:\r \r | Token | Uso |\r |---|---|\r | primary | marca, CTA principal, foco |\r | primary-foreground | texto sobre primary |\r | background | fondo principal |\r | foreground | texto principal |\r | card | fondo de superficies |\r | card-foreground | texto en cards |\r | muted | fondos secundarios |\r | muted-foreground | texto secundario |\r | accent | badges, highlights, estados activos |\r | accent-foreground | texto sobre accent |\r | border | separadores y bordes |\r | destructive | errores y acciones destructivas |\r | success | confirmaciones si aplica |\r | warning | alertas si aplica |\r \r

Reglas de color\r

\r

• Usar preferentemente máximo 5 colores dominantes en la experiencia.\r
• Tener 1 color primario claro.\r
• Usar 2 o 3 neutrales máximos.\r
• Mantener 1 o 2 acentos funcionales.\r
• Preferir colores sólidos frente a gradientes innecesarios.\r
• Usar nombres semánticos, no colores directos, cuando se implementen tokens.\r
• Verificar contraste suficiente.\r
• El acento debe ayudar a la jerarquía, no competir con todo.\r \r

Evitar\r

• demasiados colores compitiendo\r
• acentos por todas partes\r
• gradientes sin propósito\r
• colores chillones en exceso\r
• usar muchos tonos sin sistema\r \r ---\r \r

2.2 Tipografía\r

\r Definir:\r \r

• familia principal\r
• pesos usados\r
• escala base\r
• line height\r
• rol de headings, body, caption, labels\r \r

Reglas tipográficas\r

\r

• Máximo 2 familias tipográficas.\r
• Tamaño mínimo recomendado para body: 14px.\r
• Headings con peso 600-700.\r
• Body con 400-500.\r
• Mantener line-height cómodo: 1.4 a 1.6.\r
• Limitar variedad de tamaños.\r
• La tipografía debe reforzar personalidad y legibilidad.\r \r

Escala sugerida\r

\r

• 14\r
• 16\r
• 18\r
• 20\r
• 24\r
• 30\r
• 36\r
• 48\r \r No hace falta usar todos. Solo los necesarios.\r \r ---\r \r

2.3 Espaciado\r

\r Definir una unidad base y una escala consistente.\r \r

Recomendación\r

Unidad base: 4px\r \r Escala común:\r

• 4\r
• 8\r
• 12\r
• 16\r
• 20\r
• 24\r
• 32\r
• 40\r
• 48\r
• 64\r
• 80\r \r

Reglas de spacing\r

\r

• El whitespace es una de las herramientas más importantes.\r
• Mejor pecar por más aire que por saturación.\r
• El spacing debe marcar agrupación lógica.\r
• Elementos relacionados: gaps más cortos.\r
• Secciones distintas: gaps más amplios.\r
• Repetir la misma lógica de espaciado entre pantallas.\r \r

Señal de mala UI\r

Si todo está muy junto, la UI se percibe barata o improvisada.\r \r ---\r \r

2.4 Border radius\r

\r Definir radios por nivel.\r \r Sugerencia:\r

• XS: 6px\r
• SM: 8px\r
• MD: 12px\r
• LG: 16px\r
• XL: 20px o 24px\r
• Full: 9999px\r \r

Regla\r

Usar radios consistentes según tipo de componente. \r No mezclar demasiados radios diferentes sin motivo.\r \r ---\r \r

2.5 Sombras y profundidad\r

\r Las sombras deben ser suaves y escasas.\r \r

Niveles sugeridos\r

• ninguna\r
• suave\r
• media\r
• fuerte solo en casos muy puntuales\r \r

Regla\r

Preferir una interfaz limpia con elevación moderada antes que una interfaz recargada.\r \r

Evitar\r

• sombras muy oscuras\r
• muchas profundidades diferentes\r
• usar sombra para compensar mala jerarquía\r \r ---\r \r

FASE 3: arquitectura de pantallas\r

\r Antes de codificar, documentar la estructura general.\r \r

Tabla mínima\r

\r | Pantalla | Estructura | CTA principal | Componentes clave |\r |---|---|---|---|\r | Home | hero / resumen / accesos rápidos | acción principal | cards, hero, quick actions |\r | Lista | filtros + listado | click/tap en item | filter bar, item card |\r | Detalle | header + contenido + acción | CTA fija o visible | gallery, info, summary |\r | Formulario | pasos + campos + submit | confirmar | field, summary, stepper |\r | Perfil | datos + acciones + historial | editar/continuar | profile sections |\r \r

Para cada pantalla definir\r

\r

1. qué ve primero el usuario \r
2. qué debe hacer \r
3. qué estados necesita \r
4. cómo navega desde y hacia ella \r
5. qué componentes pueden reutilizarse\r \r

Regla\r

No tratar pantallas como piezas aisladas. \r Pensar el flujo completo del producto.\r \r ---\r \r

FASE 4: reglas visuales estrictas\r

\r Estas reglas buscan evitar resultados genéricos o visualmente flojos.\r \r

4.1 Jerarquía visual\r

\r Debe quedar claro:\r \r

• qué es lo principal\r
• qué es secundario\r
• qué es informativo\r
• cuál es la acción clave\r \r

Reglas\r

• Un viewport no debe tener demasiados elementos compitiendo por atención.\r
• Debe existir un CTA primario claro.\r
• Los títulos deben diferenciarse claramente del body.\r
• La información secundaria debe sentirse secundaria.\r
• El uso del color debe reforzar la jerarquía.\r \r ---\r \r

4.2 Densidad visual\r

\r

Regla\r

Reducir ruido. \r Si hay duda entre agregar o quitar, normalmente conviene quitar.\r \r

Buscar\r

• aire\r
• estructura\r
• ritmo\r
• bloques legibles\r
• agrupación lógica\r \r

Evitar\r

• demasiados iconos\r
• demasiados badges\r
• textos compactos\r
• cards apretadas\r
• bordes y sombras en exceso\r
• microdetalles que distraen\r \r ---\r \r

4.3 Consistencia\r

\r

Regla crítica\r

Mismo componente = mismo comportamiento visual y estructural.\r \r

Debe mantenerse consistente:\r

• radios\r
• padding interno\r
• estados\r
• estilo de botones\r
• estilo de inputs\r
• altura de componentes similares\r
• patrones de card\r
• chips y badges\r
• spacing entre bloques\r
• tono de iconografía\r \r ---\r \r

4.4 Mobile-first\r

\r

Proceso obligatorio\r

1. Pensar primero en 375px aprox.\r
2. Luego expandir a tablet y desktop.\r
3. Asegurar CTA claros en móvil.\r
4. Mantener touch targets cómodos.\r \r

Reglas\r

• mínimo razonable de touch target: 44x44px\r
• formularios cómodos para móvil\r
• sticky bottom CTA si ayuda\r
• no confiar en hover como interacción principal\r \r ---\r \r

FASE 5: reglas de implementación frontend\r

\r Esta skill no solo diseña. También debe ayudar a implementar bien.\r \r

5.1 Filosofía de implementación\r

\r Construir primero una base sólida de componentes y layout. \r No escribir una pantalla gigante llena de JSX repetido sin estructura.\r \r

5.2 Estructura recomendada\r

\r Separar cuando sea razonable en:\r

• components/ui\r
• components/shared\r
• features/...\r
• pages o screens\r
• hooks\r
• lib\r
• types\r \r No es obligatorio usar exactamente esos nombres, pero sí mantener organización clara.\r \r ---\r \r

5.3 Reutilización\r

\r

Regla\r

Si un patrón se repite 2 o más veces, evaluar extraer componente.\r \r

Extraer especialmente:\r

• botones\r
• cards\r
• headers de sección\r
• list items\r
• inputs\r
• filtros\r
• barras de acción\r
• resúmenes\r
• skeletons\r
• empty states\r \r ---\r \r

5.4 Props y variantes\r

\r Cuando haya componentes reutilizables, preferir variantes claras:\r

• variant\r
• size\r
• state\r
• tone\r \r Ejemplos:\r
• variant="default|outline|ghost"\r
• size="sm|md|lg"\r \r

Regla\r

No duplicar un mismo componente con diferencias mínimas si una variante resuelve el caso.\r \r ---\r \r

5.5 Estilo de layout\r

\r

Prioridad general\r

1. flex\r
2. grid cuando el layout realmente lo necesite\r
3. absolute/fixed solo cuando tenga sentido real\r
4. nunca usar hacks viejos si hay una solución moderna y clara\r \r

Regla\r

El layout debe ser legible y fácil de mantener.\r \r ---\r \r

5.6 Responsive\r

\r Definir claramente:\r

• comportamiento móvil\r
• comportamiento tablet\r
• comportamiento desktop\r \r No solo “hacerlo caber”. \r Debe adaptarse con intención.\r \r ---\r \r

5.7 Accesibilidad mínima\r

\r Siempre verificar, al menos:\r

• contraste suficiente\r
• labels entendibles\r
• foco visible\r
• botones e inputs legibles\r
• touch targets adecuados\r
• no depender solo del color para comunicar estado\r \r ---\r \r

5.8 Estados de interacción\r

\r Todo componente importante debería contemplar si aplica:\r

• hover\r
• active\r
• focus\r
• disabled\r
• loading\r \r ---\r \r

FASE 6: patrones obligatorios\r

\r

6.1 Empty state\r

\r Toda pantalla con contenido variable debería contemplar empty state si aplica.\r \r Debe tener:\r

• mensaje claro\r
• tono útil\r
• orientación de siguiente paso\r
• CTA cuando sea útil\r \r No dejar zonas vacías sin explicación.\r \r ---\r \r

6.2 Loading state\r

\r Usar:\r

• skeletons para contenido predecible\r
• spinner solo cuando tenga sentido\r
• feedback visual claro\r \r No dejar la pantalla vacía mientras carga.\r \r ---\r \r

6.3 Error state\r

\r Debe tener:\r

• mensaje entendible\r
• opción de retry o acción útil\r
• mantener contexto del usuario cuando sea posible\r \r No mostrar errores técnicos crudos salvo contexto técnico explícito.\r \r ---\r \r

6.4 Success state\r

\r Debe dejar claro:\r

• qué se completó\r
• qué sigue\r
• si se puede deshacer o continuar\r \r ---\r \r

6.5 Navegación\r

\r Elegir patrón según producto:\r

• bottom nav: apps móviles con pocas secciones principales\r
• sidebar: dashboards o entornos desktop\r
• header + menu: webs responsive\r
• breadcrumbs: jerarquías profundas\r \r No mezclar patrones sin lógica.\r \r ---\r \r

6.6 CTA\r

\r

Regla principal\r

Debe existir jerarquía clara de acciones.\r \r

• CTA primario: la acción principal\r
• CTA secundario: apoyo\r
• CTA terciario: link o acción menor\r \r

Evitar\r

• múltiples primarios compitiendo\r
• CTA oculto o débil\r
• demasiadas acciones con igual peso\r \r ---\r \r

FASE 7: interpretación de pedidos vagos\r

\r Cuando el usuario pida cambios ambiguos, traducirlos a decisiones concretas.\r \r

“Hazlo más moderno”\r

• reducir ruido\r
• usar más whitespace\r
• radios más refinados\r
• tipografía más limpia\r
• sombras más suaves\r
• layout más ordenado\r
• menos adornos\r \r

“Hazlo más premium”\r

• menos elementos\r
• paleta más sobria\r
• mejor jerarquía\r
• más aire\r
• tipografía más elegante\r
• detalles más sutiles\r
• evitar colores chillones\r \r

“Hazlo más profesional”\r

• neutrales dominantes\r
• acento controlado\r
• estructura sobria\r
• sin decoraciones innecesarias\r
• consistencia estricta\r \r

“Hazlo más juvenil”\r

• energía controlada\r
• color más expresivo pero limitado\r
• bordes más amables\r
• tipografía con más personalidad\r
• UI más dinámica\r \r

“Hazlo más limpio”\r

• quitar elementos\r
• reducir variedad visual\r
• reforzar jerarquía\r
• aumentar espacio entre bloques\r
• simplificar estructura\r \r

“Está muy básico”\r

• mejorar composición\r
• mejor jerarquía tipográfica\r
• mejor acento\r
• spacing más intencional\r
• componentes mejor proporcionados\r
• detalles sutiles de producto real\r \r

“Hazlo más accesible”\r

• aumentar legibilidad\r
• mejorar contraste\r
• hacer objetivos táctiles más cómodos\r
• reforzar focus states\r
• lenguaje más claro\r \r ---\r \r

FASE 8: revisión crítica antes de entregar\r

\r Antes de considerar que la UI está bien, revisar esta checklist.\r \r

Señales de mala UI\r

\r Corregir inmediatamente si aparecen varias de estas:\r \r

• elementos demasiado juntos\r
• demasiados colores\r
• tipografía inconsistente\r
• demasiados tamaños y pesos distintos\r
• botones sin jerarquía clara\r
• cards deformes o con padding incoherente\r
• layout plano o sin foco\r
• demasiados elementos compitiendo\r
• texto difícil de escanear\r
• contraste pobre\r
• componentes similares con estilos diferentes\r
• CTA poco visible\r
• demasiado borde, sombra o badge\r
• sensación de plantilla genérica\r
• desktop bien pero móvil descuidado\r
• mobile comprimido y poco cómodo\r \r

Señales de buena UI\r

\r

• abundante whitespace bien usado\r
• jerarquía visual evidente\r
• fluidez de lectura\r
• componentes consistentes\r
• CTA claro\r
• estructura limpia\r
• color intencional\r
• flujo entendible\r
• buenas proporciones\r
• sensación de producto real\r \r ---\r \r

FASE 9: autocrítica y segunda iteración\r

\r Si la primera versión aún se siente genérica, no asumir que ya está terminada.\r \r

Proceso obligatorio de autocrítica\r

Preguntarse:\r \r

1. ¿Esto se ve como demo rápida o como producto serio?\r
2. ¿La jerarquía visual es obvia en 3 segundos?\r
3. ¿El spacing está realmente bien o solo “aceptable”?\r
4. ¿El CTA principal destaca lo suficiente?\r
5. ¿Hay demasiada información compitiendo?\r
6. ¿Las cards y contenedores tienen buenas proporciones?\r
7. ¿La UI transmite la personalidad correcta?\r
8. ¿Móvil se siente diseñado o solo adaptado?\r \r Si varias respuestas son negativas, hacer una segunda iteración antes de cerrar.\r \r ---\r \r

FASE 10: uso de screenshots y revisión visual\r

\r Si el entorno permite screenshots, navegador o render visual, aprovecharlo.\r \r

Qué revisar en capturas\r

• jerarquía\r
• spacing\r
• legibilidad\r
• equilibrio visual\r
• densidad\r
• CTA\r
• consistencia\r
• sensación premium / moderna / profesional según el caso\r
• adaptación mobile\r \r

Regla\r

La revisión visual es parte del trabajo, no algo opcional.\r \r ---\r \r

FASE 11: comportamiento esperado del agente\r

\r Cuando esta skill esté activa, el agente debe comportarse así:\r \r

1. No saltar directo a escribir una UI sin criterio.\r
2. Pensar en producto, usuario y acción principal.\r
3. Proponer dirección visual si hace falta.\r
4. Definir un pequeño sistema antes de implementar.\r
5. Construir con componentes reutilizables.\r
6. Mantener consistencia entre pantallas.\r
7. Revisar estados y responsive.\r
8. Ser crítico consigo mismo antes de finalizar.\r
9. Evitar caer en la primera solución genérica.\r
10. Buscar una salida más cercana a un producto real que a una maqueta improvisada.\r \r ---\r \r

FASE 12: qué evitar\r

\r Evitar especialmente:\r \r

• escribir primero y pensar después\r
• llenar de componentes sin jerarquía\r
• usar demasiados colores\r
• meter demasiados estilos distintos\r
• repetir JSX con cambios mínimos\r
• hacer UI “bonita” pero incómoda\r
• descuidar móvil\r
• esconder la acción principal\r
• diseñar solo para impresionar sin pensar en tarea real\r
• entregar una primera versión floja como si ya estuviera final\r \r ---\r \r

FASE 13: guía rápida de decisión\r

\r

Si el producto es:\r

SaaS / Dashboard\r

• claridad\r
• estructura\r
• información bien jerarquizada\r
• sidebar o top nav clara\r
• cards sobrias\r
• densidad controlada\r \r

App móvil de consumo\r

• bottom nav si aplica\r
• CTA claro\r
• touch comfort\r
• menos texto\r
• componentes grandes y limpios\r
• ritmo vertical cuidado\r \r

Landing page\r

• hero fuerte\r
• narrativa clara\r
• secciones bien marcadas\r
• CTA repetido estratégicamente\r
• visuales limpios\r
• jerarquía muy clara\r \r

E-commerce / reservas / servicios\r

• confianza\r
• búsqueda o exploración clara\r
• cards potentes\r
• detalle bien estructurado\r
• CTA muy visible\r
• estados y resumen claros\r \r ---\r \r

FASE 14: salida ideal\r

\r La salida ideal de esta skill no debe quedarse en teoría. \r Debe terminar ayudando a producir algo concreto como:\r \r

• propuesta visual\r
• design system\r
• arquitectura de pantallas\r
• plan de componentes\r
• implementación frontend\r
• revisión crítica\r
• mejoras iterativas\r \r ---\r \r

Resumen operativo\r

\r

Orden correcto de trabajo\r

\r

1. entender producto, usuario y acción\r
2. definir dirección visual\r
3. elegir estilo recomendado\r
4. documentar mini design system\r
5. definir arquitectura de pantallas\r
6. implementar con componentes reutilizables\r
7. revisar estados y responsive\r
8. autocriticar resultado\r
9. iterar si todavía se ve genérico\r \r ---\r \r

Nota final\r

\r Consistencia > ocurrencias aisladas \r Claridad > decoración \r Whitespace > saturación \r Sistema > improvisación \r Producto real > demo genérica\r \r Ante la duda, simplificar, ordenar y reforzar jerarquía.