La IA no conoce tu FDS (todavía)
Si usas Flowtitude Design System (FDS) con WindPress y Tailwind v4, seguramente ya has notado que tu agente de IA inventa clases que no existen en tu proyecto. Le pides una sección y te devuelve bg-primary-500 con un valor de azul genérico que no tiene nada que ver con el OKLCH personalizado de tu marca. O usa p-18 cuando tu escala fluida ni siquiera contempla ese valor. O escribe text-heading cuando en FDS la clase correcta es .heading. El agente sigue escribiendo con total confianza, pero no sabe nada sobre tu sistema. No es culpa suya: en su entrenamiento ha visto miles de proyectos con la configuración por defecto de Tailwind, no el tuyo.
Por qué pasa esto en FDS
FDS está construido sobre Tailwind v4, que abandona el tradicional tailwind.config.js a favor de una configuración basada en CSS con la directiva @theme. Tus tokens viven en theme/flowtitude.css como variables CSS personalizadas: --color-primary-500, --spacing-section, --spacing-block, los rangos fluidos del sistema, los clamp() de tipografía. Pero FDS no son solo tokens: también añade componentes propios (.display, .heading, .subheading, .text-large, .eyebrow, .btn, .card), layouts inteligentes (.section, .content-flex de 9 puntos) y custom variants únicos (parent, parent-hover, parent-focus-within) que no aparecen en la documentación pública de Tailwind. Todo eso es invisible para un agente que no tenga acceso al sistema completo. Cuando le pides "haz una sección hero", el agente recurre a su memoria de la documentación pública de Tailwind y compone clases plausibles que no corresponden a tu sistema. El resultado: revisión manual, correcciones constantes y la sensación de que la IA te ralentiza más que te ayuda.
La solución del momento (y por qué no aplica)
En estos días circula una herramienta llamada tailwind-context-resolver-mcp que se presenta como un servidor MCP capaz de cargar tu tailwind.config y exponer el sistema al agente. Sobre el papel resuelve exactamente este problema. En la práctica solo funciona con Tailwind v3 porque depende de la API tailwindcss/resolveConfig, que ya no existe en v4. Si lo instalas en un proyecto FDS, el servidor detecta v4 y devuelve un error claro. Útil para mucha gente, pero no para nuestra comunidad.
Qué sí funciona con FDS
La solución es más directa de lo que parece: dale al agente acceso al main.css de FDS. Es el entry point del sistema y desde ahí se importa todo: los tokens del tema (theme/flowtitude.css), la capa base (base/base.css, base/typography.css), los layouts (layouts/section.css, layouts/content-flex.css), los componentes (components/typography.css, buttons.css, components.css, cards.css, custom.css), las utilidades (utility/core/utilities.css, utility/animations/durations.css, utility/layout/grid-basic.css) y los custom variants. Cuando el agente lo lee como contexto, deja de adivinar. Sabe que --color-primary-500 existe y qué OKLCH tiene. Sabe que --spacing-section es 3 veces el spacing base. Sabe que en FDS existen clases como .display, .heading, .subheading, .text-large, .eyebrow, .btn y .card que no aparecen en la documentación pública de Tailwind. Y sabe que tienes variantes propias como parent:bg-primary-50 que no entendería un agente sin contexto.
Cómo dárselo en la práctica. Tres caminos según el agente que uses:
Si trabajas con Claude Code o Cursor en el propio repo de flowtitude-design-system (o en el tema hijo que lo incluye), ya tiene acceso a main.css y a todos sus imports por defecto. Solo asegúrate de mencionárselo en el prompt: "usa el sistema definido en main.css y sus archivos importados".
Si trabajas fuera del repo (por ejemplo, generando una landing para un cliente con WindPress instalado), abre directamente la carpeta wp-content/uploads/windpress/data/ de tu WordPress. Dentro tienes main.css y toda la cadena de archivos (theme, base, layouts, components, utility) tal cual los usa tu sitio en producción. Súbelos al chat de Claude.ai o ChatGPT como adjuntos, con un mensaje tipo "este es mi sistema de diseño completo, úsalo para todas las clases que generes".
Si usas el tema hijo Flowtitude, dispones del panel admin en Flowtitude > Design System, integrado en WordPress. Desde ahí gestionas tu configuración actual de tokens y puedes exportarla en cualquier momento para dársela al agente. Con eso recibe exactamente lo que está aplicado en tu sitio en este momento, no la versión teórica del repo.
Bonus: docs interactivos
Si trabajas a menudo con la misma IA en proyectos FDS, en lugar de pegar el CSS en cada conversación, súbele también los docs interactivos del sistema (docs/index.html, docs/tokens.html, docs/typography.html, docs/buttons.html, docs/layouts.html, docs/utilities.html del repo flowtitude-design-system). Le das tokens + ejemplos visuales + nombres de clase reales en HTML. La diferencia entre un agente que adivina y uno que conoce tu sistema es exactamente esto: contexto real en lugar de estadísticas de entrenamiento.
¿Habías intentado ya darle FDS como contexto a tu IA? ¿Qué resultados has tenido? Cuéntanos en los comentarios qué flujo te funciona mejor.
