anti-ai-design

Habilidad de diseño de UI de auto-orquestación con reglas anti-IA obligatorias. Produce pantallas increíblemente hermosas y visualmente distintas, nunca el resultado genérico de IA.

Cuándo Usar

Activa esta habilidad cada vez que el usuario solicite:

Una página de aterrizaje, sección de héroe o pantalla de marketing
Un panel de control, panel de administración o interfaz rica en datos
Una pantalla de aplicación móvil (iOS, Android) o interfaz web responsiva
Un flujo de incorporación, formulario de registro o recorrido del producto
Cualquier pantalla de biblioteca de componentes o sistema de diseño
"Haz que se vea mejor", "rediseña esto", "crea una interfaz de usuario para…"

Contrato de Interacción No Negociable

Antes de generar cualquier resultado de diseño, DEBES resolver estas tres decisiones en orden:

Alcance de la plataforma — pregúntale al usuario para qué plataformas generar: mobile, tablet, desktop.
- Se permite la selección múltiple.
- Si el usuario elige solo mobile y desktop, NO generes tablet.
- Si la plataforma ya está explícitamente indicada y no es ambigua, confírmala repitiéndola y continúa.
Dirección de color — resuelve la dirección del color de la marca usando este orden:
- Si el usuario proporcionó colores exactos, úsalos.
- Si no, y el usuario proporcionó un estado de ánimo de marca/tema, ofrece 2 o 3 direcciones de paleta adecuadas y pídele que elija.
- Si no, selecciona automáticamente una paleta que se ajuste a la categoría del producto e indica claramente que fue seleccionada automáticamente.
Dirección de estilo — presenta 2 o 3 opciones de estilo y haz que el usuario elija una.

No te saltes estas decisiones a menos que la conversación ya contenga una respuesta inequívoca.

Modo de Ejecución

Interactivo (predeterminado)

Pregúntale al usuario por cada elección faltante en secuencia: plataforma → color → estilo.
Espera su respuesta antes de pasar a la siguiente fase.
Presenta tarjetas de opciones para la dirección de estilo con una etiqueta RECOMENDADO.

No Interactivo

Actívalo cuando el usuario:

invoque la habilidad con mode: non_interactive o una bandera equivalente,
esté ejecutando un comando CLI único, un trabajo Codex en segundo plano o un pipeline scripteado, o
proporcione una solicitud sin contexto conversacional previo (sin turnos de chat antes de la solicitud).

Reglas de selección automática (aplicadas en orden):

Plataforma — si no se indica, por defecto desktop. Si existen señales de "mobile first" (descripción de aplicación móvil, mención de React Native, contexto de "teléfono"), por defecto mobile.
Dirección de color — selecciona la paleta más adecuada para el tipo de proyecto detectado sin ofrecer alternativas.
Dirección de estilo — de los 2 o 3 estilos candidatos para este contexto de proyecto, selecciona el que estaría marcado como RECOMENDADO. No presentes tarjetas de opciones.

Encabezado de salida requerido antes de generar (solo no interactivo):

Auto-seleccionado:
- Plataforma: [plataforma(s) seleccionada(s)]
- Paleta: [nombre de paleta] — primario [valor hexadecimal]
- Estilo: [nombre del estilo] — [vibra de una frase]
Procediendo a la generación del paquete.

No hagas preguntas aclaratorias. No presentes tarjetas de opciones. Procede directamente a la Fase 3 después del encabezado.

Contrato de Salida — Paquete CJX, No un Solo HTML Suelto

La salida predeterminada es un directorio de paquete para el proyecto, no un solo archivo HTML suelto.

<app-slug>-design/
  html/
    landing-page.html
    mobile-<screen>.html
    tablet-<screen>.html
    desktop-<screen>.html
  css/
    foundation.css
    shared.css
    landing-page.css
    mobile-<screen>.css
    tablet-<screen>.css
    desktop-<screen>.css
  js/
    app.js
    landing-page.js
    mobile-<screen>.js
    tablet-<screen>.js
    desktop-<screen>.js

Reglas del Paquete

html/ contiene un archivo HTML por cada combinación de pantalla/plataforma generada.
css/foundation.css contiene solo los tokens de diseño congelados.
css/shared.css contiene primitivas compartidas, utilidades, movimiento, recetas de vidrio, estados de enfoque y patrones de diseño comunes.
El CSS específico de la pantalla va en un archivo específico de la pantalla.
js/app.js contiene ayudantes de UI compartidos, alternancias de estado, manejo de datos simulados e interacciones seguras para la accesibilidad.
El JS específico de la pantalla va en un archivo específico de la pantalla solo si es necesario.
Si el usuario solicita una exportación de un solo archivo más adelante, puedes proporcionar adicionalmente una exportación HTML autocontenida, pero el contrato predeterminado es el paquete CJX.

Reglas de Nomenclatura de Archivos por Plataforma

Las páginas de aterrizaje mantienen un nombre semántico: landing-page.html, landing-page.css, landing-page.js
Las pantallas de aplicación usan prefijos de plataforma:
- mobile-<screen>.html
- tablet-<screen>.html
- desktop-<screen>.html
Genera archivos solo para las plataformas seleccionadas.
Si el usuario seleccionó mobile y desktop, el paquete de salida no debe contener ningún archivo tablet-*.

Por qué Archivos Separados en Lugar de un Solo HTML Responsivo

Usa archivos de plataforma separados por defecto porque:

cada plataforma puede tener IA, navegación, densidad y ubicación de CTA materialmente diferentes,
la revisión y entrega son más fáciles cuando cada objetivo está aislado,
la verificación CJX es más clara cuando la intención de la pantalla es explícita,
desktop/tablet/móvil a menudo necesitan jerarquía diferente, no solo puntos de interrupción diferentes.

Un solo HTML responsivo solo es aceptable cuando el usuario solicita explícitamente una entrega de un solo archivo.

Enrutamiento de Sub-Habilidades

Carga SOLO el archivo de referencia necesario para el paso actual. NO cargues todos los archivos a la vez.

Tarea	Cargar	Detalles
Elegir estilo de diseño / dirección artística	`references/design-styles-catalog.md`	36 estilos en 11 categorías
Seleccionar tendencia / paquete artístico	`references/design-trends.md`	6 tendencias, 3 paquetes de dirección artística
Aplicar una receta de diseño	`references/design-recipes-catalog.md`	15 recetas de diseño completas
Aplicar reglas de diseño de plataforma	`references/platform-rules.md`	Reglas de Móvil/iOS 26/Escritorio/Tableta
Congelar e inyectar tokens de base	`references/foundation-tokens.md`	Instrucciones de congelación de tokens y formato
Aplicar gramática de radio + jerarquía de anidamiento	`references/radius-choreography.md`	Roles de radio semánticos, reglas de superficie anidada, gramática de radio de familia de estilo
Aplicar reglas de UX / viaje del cliente	`references/ux-guidelines.md`	Cumplimiento de UX, patrones CJX
Aplicar coreografía de movimiento + intención de interacción	`references/motion-choreography.md`	Propósito del movimiento, política de hover, transiciones de estado, reglas de movimiento de plataforma
Aplicar propiedad de activos del paquete + auditoría de manifiesto	`references/output-bundle-rules.md`	Reglas de activos compartidos vs. pantalla, manifiesto, auto-auditoría
Generar paquete de salida	`references/output-template.md`	Estructura del paquete, plantilla HTML, contrato de archivo

Flujo de Auto-Orquestación

Ejecuta estas fases en secuencia. Cada fase tiene lógica condicional — síguela con precisión.

Fase 1 — DETECCIÓN DE CONTEXTO

Escanea la conversación y cualquier archivo adjunto para buscar: nombre del proyecto, colores de marca existentes, fuentes, pila tecnológica, plataforma de destino y propósito de la pantalla.
Clasifica el tipo de proyecto como uno de: producto SaaS · comercio electrónico · aplicación móvil · portafolio · panel de control · sitio de marketing · otro.
Extrae las pantallas solicitadas y cuenta su número.
Resuelve el alcance de la plataforma como uno o más de: mobile, tablet, desktop.
Si falta el alcance de la plataforma o es ambiguo: haz exactamente una pregunta de selección de plataforma con opciones de selección múltiple:
- Móvil
- Tableta
- Escritorio
Si el usuario ya especificó plataformas, no vuelvas a preguntar — transpórtalas exactamente.
Anota cualquier token de marca existente (colores, fuentes, escala de espaciado) encontrado en el proyecto — los usarás en la congelación de tokens más adelante.
Resuelve la prioridad del esquema de color según el tipo de proyecto:

Modo oscuro primero (oscuro es el lienzo principal; claro es la anulación opcional):
- Panel de control · panel de administración · SaaS con muchos datos · fintech · herramientas para desarrolladores · analíticas · monitorización · crypto/web3 · medios/streaming · juegos
Modo claro primero (claro es el lienzo principal; oscuro es la anulación opcional):
- Comercio electrónico · sitio de marketing · portafolio · salud · educación · alimentación y bebidas · estilo de vida
Si el tipo de proyecto es ambiguo o no encaja en ninguna lista, por defecto modo claro primero y ofrece el modo oscuro como complemento.

Transporta esta decisión como color_scheme_priority: dark_first | light_first. Las opciones de paleta de la Fase 2 y la congelación de tokens de la Fase 4 deben reflejar esta prioridad.

Fase 2 — DIRECCIÓN DE COLOR + DISEÑO

Resuelve la dirección de color antes de la selección de estilo.
Si el usuario no proporcionó una paleta explícita, ofrece de 2 a 3 direcciones de paleta que se ajusten a la categoría del producto y reflejen la color_scheme_priority de la Fase 1:
- Para proyectos dark_first: lidera con opciones de paleta oscura (ej. oscuro-lujo OLED, pizarra eléctrica, azul marino profundo), incluye una opción clara solo como última opción.
- Para proyectos light_first: lidera con opciones de paleta clara (ej. energía cálida de comercio, neutro fresco de confianza), incluye una opción oscura solo si encaja con la marca.
- Pídele al usuario que elija una.
Si el usuario se niega a elegir, selecciona automáticamente la paleta más adecuada y explica por qué en una oración.
Carga references/design-styles-catalog.md.
Del catálogo, selecciona 2 o 3 estilos que mejor se adapten al tipo de proyecto, la paleta elegida y el contexto.

Para cada estilo seleccionado, genera una tarjeta de opción en este formato:

[N]. **Nombre del Estilo** — RECOMENDADO (si corresponde)
Vibra: [vibra/ambiente de una oración]
Estética clave: [3 características visuales definitorias]

Marca exactamente UNA opción como RECOMENDADO según la mejor adecuación.
Presenta la lista numerada al usuario y pídele que elija. Espera su respuesta antes de continuar.
Si el usuario solicita un estilo diferente que no está en la lista, acéptalo y continúa.

Fase 3 — GENERACIÓN DEL PAQUETE

Carga references/platform-rules.md para las plataformas seleccionadas.
Carga references/output-template.md para el formato del paquete CJX.
Carga references/output-bundle-rules.md para la propiedad de activos, ubicación de clases compartidas, manifiesto y auto-auditoría del paquete.
Carga references/radius-choreography.md para resolver la gramática de radio, la jerarquía de superficie anidada y la curvatura basada en roles antes de escribir cualquier CSS.
Carga references/ux-guidelines.md al generar la salida final porque la integridad del estado es obligatoria.
Aplica TODAS las Reglas de Diseño Anti-IA a continuación.
Aplica las reglas de plataforma para cada plataforma seleccionada por separado.
Resuelve una gramática de radio para la dirección de estilo elegida antes de escribir CSS de componentes:
- elige de 2 a 4 niveles de radio primarios más el de píldora si es necesario,
- asígnalos a roles semánticos: shell, superficie, inserción, control, ajustado, píldora,
- mantén la gramática consistente en todo el paquete,
- asegúrate de que las superficies anidadas del mismo material reduzcan la curvatura.
Genera un directorio de paquete que contenga:
- html/
- css/
- js/
- manifest.json
Genera un trío HTML/CSS/JS por cada combinación de pantalla/plataforma requerida.
Genera solo las pantallas solicitadas y solo las plataformas seleccionadas.
Las páginas de aterrizaje pueden permanecer semánticas entre plataformas si el mismo archivo funciona bien, pero si el diseño cambia significativamente según la plataforma, genera también variantes de aterrizaje específicas de la plataforma.
Cada archivo HTML debe:
- hacer referencia a ../css/foundation.css
- hacer referencia a ../css/shared.css
- hacer referencia a su archivo CSS de pantalla
- hacer referencia al ../js/app.js compartido
- hacer referencia a su archivo JS de pantalla cuando sea necesario
- usar data-ai-id en todos los elementos estructurales principales
- usar texto contextual y realista — nunca lorem ipsum
Cada pantalla de aplicación generada debe incluir o manejar explícitamente los cuatro estados de UX de ux-guidelines.md:
- carga
- vacío
- error
- éxito
Estos estados pueden ser visibles en el lienzo principal o implementados como estados simulados alternables a través de controles JS, pero deben existir en el paquete enviado.
Resuelve el estado visible predeterminado intencionalmente:
- las pantallas de generador deben tener como predeterminado vacío a menos que el usuario haya solicitado explícitamente un lienzo de éxito precargado/listo para demostración,
- las pantallas de resultado/revisión deben tener como predeterminado éxito a menos que la narrativa requiera explícitamente otro estado primero,
- nunca permitas que una pantalla de generador implique un resultado completado antes de que el usuario haya proporcionado o cargado datos.
Aplica las reglas de realismo de pantalla de utilidad a pantallas de generador, resultado, panel de control y con muchos formularios:
- optimiza para confianza, escaneabilidad y alineación antes que el espectáculo,
- mantén el formulario principal, el lienzo de estado, el tablero de resultados y los grupos de CTA en diseños de flujo normal estables,
- no uses tarjetas de contenido superpuestas o posicionadas de forma absoluta como la estructura principal de una pantalla de utilidad,
- mantén la asimetría decorativa secundaria para que nunca debilite la claridad de la tarea o la capacidad de descubrimiento de la CTA,
- asegúrate de que la tipografía hero en las pantallas de utilidad se lea de manera creíble en el viewport de destino en lugar de depender de un envoltorio teatral.
Antes de declarar la salida completa, ejecuta la auto-auditoría del paquete de references/output-bundle-rules.md:
- mueve todos los selectores reutilizados en 2 o más archivos HTML a shared.css
- asegúrate de que ninguna página dependa del archivo CSS de una página hermana para renderizarse correctamente
- asegúrate de que todos los activos referenciados existan
- asegúrate de que manifest.json coincida exactamente con los archivos generados
- asegúrate de que no existan archivos para plataformas no seleccionadas
- asegúrate de que la jerarquía de radio siga la gramática semántica elegida y que las superficies anidadas no se aplasten en capas de radio igual
- asegúrate de que las pantallas de utilidad pasen la auditoría de realismo de diseño en su viewport de destino

Fase 4 — CONGELACIÓN DE TOKENS DE BASE

Después de generar la primera pantalla aprobada, extrae los valores exactos de los tokens en css/foundation.css.
Congela no solo el color/tipo/movimiento, sino también la gramática de radio semántica para el paquete.
Usa este formato exacto:

/* FROZEN FOUNDATION TOKENS — DO NOT MODIFY */
:root {
  --color-primary: <valor exacto>;
  --color-secondary: <valor exacto>;
  --color-accent: <valor exacto>;
  --color-bg: <valor exacto>;
  --color-surface: <valor exacto>;
  --color-text: <valor exacto>;
  --color-text-muted: <valor exacto>;
  --font-heading: <pila de fuentes exacta>;
  --font-body: <pila de fuentes exacta>;
  --space-base: <valor exacto>;
  --radius-1: <valor exacto>;
  --radius-2: <valor exacto>;
  --radius-3: <valor exacto>;
  --radius-4: <valor exacto>;
  --radius-5: <valor exacto>;
  --radius-pill: <valor exacto>;
  /* Roles semánticos de radio */
  --radius-shell: var(--radius-2);
  --radius-surface: var(--radius-3);
  --radius-inset: var(--radius-1);
  --radius-control: var(--radius-1);
  --radius-tight: var(--radius-0);
  --radius-pill: var(--radius-pill);
  --motion-duration-fast: 150ms;
  --motion-duration-normal: 250ms;
  --motion-duration-slow: 400ms;
  --motion-easing-default: cubic-bezier(0.4, 0, 0.2, 1);
  --motion-easing-enter: cubic-bezier(0, 0, 0.2, 1);
  --motion-easing-exit: cubic-bezier(0.4, 0, 1, 1);
}

Mantén el archivo foundation.css como único origen de verdad. No dupliques tokens en otros lugares.
Cuando el modo oscuro sea la prioridad (dark_first), los valores de foundation.css deben representar el esquema oscuro de forma nativa. Las variables de modo claro deben residir en una consulta de medios prefers-color-scheme: light dentro de foundation.css, anulando los colores base.
Cuando el modo claro sea la prioridad (light_first), los valores de foundation.css deben representar el esquema claro de forma nativa. Las variables de modo oscuro deben residir en una consulta de medios prefers-color-scheme: dark dentro de foundation.css, anulando los colores base.
Una vez congelados, el autor no debe modificar foundation.css a menos que el usuario solicite explícitamente un ajuste de la paleta.

Reglas de Diseño Anti-IA (obligatorio — por qué esta habilidad se llama "anti-ia-diseño")

Estas reglas existen para que cada pantalla se sienta diseñada por un humano con ojo, no por un modelo de lenguaje que regurgita promedios.

1. Prohibición del Diseño Genérico de IA

Sin fondos degradados púrpura-azul. Los degradados deben tener una intención, no ser un marcador de posición genérico. Usa degradados sutiles, tono sobre tono, o monocromáticos. Si usas un degradado dual, una de las paradas debe ser inesperada (ej. cobre a coral, índigo a berenjena, verde azulado a bosque).
Sin esquinas redondeadas de 16 px en cada tarjeta. Demasiado IA. La mayoría de las superficies deben usar radio-4 a radio-8 (ajustado). Radio-12 y superiores deben reservarse para casos con intención explícita como tarjetas de testimonio hero, modales o componentes de alta jerarquía. La gramática del radio debe sentir que se ha elegido, no que se ha aplicado por defecto.
Sin superposición de cuadrícula sutíl + degradado + pantalla de héroe de ilustración 3D. Ese es el trío de inicio de IA. Rompe el patrón.
Sin tipografía hero de 56-64 px con interletraje suelto y peso 700. Varía el tamaño, peso e interletraje para que coincida con la intención del contenido, no con el marcador de posición AI.
Sin los mismos 5 esquemas de color: azul-#2563EB/gris-#64748B/blanco-#FFFFFF. Elige paletas que no aparecerían en la primera página de una búsqueda de "temas de interfaz de usuario".
Sin diseño de tarjeta idéntico para todo el contenido. Varía la proporción, la saturación de la imagen, los tratamientos de fondo y la composición. Las tarjetas de lista pueden compartir un diseño, pero las tarjetas de característica principal, las tarjetas de testimonio y las tarjetas de precios deben diferir estructuralmente.

2. Regla de Composición Inesperada

Rompe al menos un patrón de diseño esperado en la composición: una imagen que sangra más allá de su tarjeta, una cita sin comillas, un pie de página que comienza con una imagen a sangre completa, una navegación que no está ni centrada ni alineada a la izquierda sino que se desplaza hacia la derecha con la marca a la izquierda. Lo inesperado debe sentirse intencional, no roto.

3. Regla de Densidad de Sorpresa Visual

Al menos un elemento por pantalla debe provocar una pausa: textura inusual, tratamiento tipográfico, interacción de capa o gesto de movimiento.
En paneles de control y páginas de utilidad, coloca la sorpresa en la microinteracción o en el manejo del estado vacío — no en la legibilidad del diseño principal.

4. Regla de Contraste de Material

Evita que todas las superficies usen el mismo material. Combina vidrio con superficies mate, tarjetas elevadas con secciones planas, bordes afilados con curvas suaves. La tensión entre materiales crea jerarquía visual.

5. Regla de Anatomía de Gesto de Componente

No diseñes componentes como estáticos. Cada componente debe tener un gesto explícito (ej. tarjeta que se eleva en hover, botón con relleno de tinta, entrada con etiqueta flotante, interruptor con seguimiento de trayectoria). El gesto debe coincidir con la intención del componente — no apliques el mismo rebote elástico a todo.

6. Regla de No Hay Dos Pantallas Iguales

Al generar múltiples pantallas de aplicación para el mismo producto, varía la estructura de diseño. No copies y pegues el mismo diseño de cuadrícula. La página de inicio puede tener una barra lateral; la página de configuración puede tener un diseño de pestañas de ancho completo; la página de detalle puede centrar el contenido con márgenes generosos.

7. Regla de Jerarquía Tipográfica por Propósito

El tamaño, peso, interletraje y altura de línea del texto deben reflejar la función del texto, no un ordenamiento plano de h1 → h6. Un titular principal puede tener 40 px con interletraje -0.02em. Un subtítulo puede tener 14 px con interletraje 0.08em y mayúsculas. El cuerpo debe priorizar la legibilidad.

8. Regla de estilo de vida de datos simulados

Los datos falsos deben verse reales. Nombres de personas, encabezados de tabla, descripciones de productos y valores de gráfico deben sentirse plausibles y contextuales — no "Nombre de usuario 1", "Elemento de lista 2".

9. Regla de 15 segundos de originalidad

Antes de declarar la salida lista, aparta la vista durante 15 segundos, luego vuelve a mirar la pantalla. Si te recuerda a una plantilla de Tailwind UI, Shadcn, Radix, Vercel, Dribbble o a cualquier inicio de IA, rehazla hasta que desaparezca la familiaridad.

Manejo de Errores y Trabajo Sucio

Cuando surjan circunstancias inesperadas:

Capacidad de la herramienta no disponible — Si una referencia de diseño o token requerida no se puede cargar, notifica al usuario qué elemento no está disponible y ofrece una alternativa razonable de tu conocimiento.

Contexto insuficiente — Si el usuario no ha especificado el nombre, el tipo o las pantallas del proyecto, solicita la información mínima necesaria para comenzar. No generes un diseño basado en suposiciones vacías.

Inconsistencia — Si la conversación contiene información contradictoria (ej. el usuario solicita "móvil" pero luego adjunta un diseño de escritorio), detente, indica la contradicción y solicita una aclaración antes de continuar.

Cambio de requisitos a mitad de flujo — Si el usuario solicita un cambio fundamental de dirección (nueva plataforma, nueva paleta, nuevo estilo) después de que el diseño esté en progreso, NOTA los tokens actuales existentes, reinicia la gramática desde el nuevo punto de partida y regenera. No parchees superposiciones de estilo sobre la base anterior.

Solicitud de pantalla no compatible — Si el usuario solicita un tipo de pantalla que esta habilidad no puede generar de manera competente (por ejemplo, maquetas 3D, animación de fotograma clave), sé sincero sobre la limitación y ofrece alternativas dentro de las capacidades del diseño de interfaz de usuario.

Generación incompleta — Si la auto-auditoría del paquete falla (falta de archivos, activos huérfanos, violación de gramática de radio), detente y vuelve a ejecutar la Fase 3 desde el paso 13. No entregues un paquete que falle la auditoría.

Limitaciones y Transparencia

Esta habilidad:

Genera interfaces de usuario de alta fidelidad, estáticas, basadas en HTML/CSS/JS. No produce aplicaciones backend completamente funcionales, bases de datos ni lógica del lado del servidor.
Soporta generación multiplataforma (móvil, tableta, escritorio) pero el alcance debe resolverse antes de la generación.
Ofrece 36 estilos de diseño en 11 categorías. Las solicitudes de estilos fuera de este catálogo requerirán una adaptación manual o una personalización explícita del usuario.
Se basa en tokens de congelación y gramática de radio para garantizar la coherencia visual en todo el paquete. Una vez congelados, estos elementos de base no deben modificarse a menos que el usuario lo solicite explícitamente.
Esta habilidad entrega un directorio de paquete. No produce maquetas de Figma, archivos PSD ni exportaciones de Sketch.
Los datos simulados son contextuales pero no son datos reales del usuario. Cualquier parecido con datos reales es coincidencia.

anti-ai-design — puerta UI 36 estilos (sin chrome IA)

¿Qué es anti-ai-design — puerta UI 36 estilos (sin chrome IA)?

Preguntar en tu IA favorita

Documentación