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.

Estamos abriendo las primeras pruebas de Kodavio, el nuevo plugin de Flowtitude para conectar agentes AI con WordPress mediante MCP.

Funciona de entrada con Claude, Codex, OpenCode, Cursor y Windsurf.

La idea es sencilla, pero potente en la práctica: que el agente no trabaje a ciegas sobre tu WordPress, sino con contexto real del sitio, permisos claros y herramientas específicas para builders, WooCommerce, sistema de diseño, scope del proyecto, administración segura y conversiones.

Podrás probarlo gratis durante 30 días directamente desde el plugin.

Qué puedes hacer ya con Kodavio

La idea de fondo es esta: editar y reconfigurar WordPress sin pasar por la admin, dejando que el agente actúe con contexto real del sitio.

Conexión y descubrimiento

• Conectar tu agente a WordPress mediante MCP.
• Revisar plugins, tema activo, configuración segura y estado general del sitio.

Edición de contenido y builders

• Trabajar con Bricks, Elementor y Gutenberg desde habilidades específicas de cada uno.
• Crear páginas y borradores apoyados en el builder activo.
• Leer páginas existentes y analizarlas estructuralmente.
• En Bricks, además, gestionar, crear y editar componentes directamente desde el agente.

WooCommerce y analítica de tienda

• Gestionar productos, variaciones, categorías, cupones, pedidos y clientes desde el agente.
• Crear y actualizar pedidos, devoluciones y notas internas sin entrar en la admin.
• Consultar informes de ventas, productos más vendidos y métricas de la tienda.
• Analizar el estado del catálogo y el comportamiento comercial para tomar decisiones con datos reales.

Sistema de diseño y scope del proyecto

• Usar design.md como memoria del sistema de diseño.
• Importar tokens y señales visuales del sitio cuando hay frameworks o configuraciones disponibles.
• Usar scope.md como memoria del proyecto: objetivos, sitemap, plugins, funcionalidades y backlog.
• En Bricks, convertir y gestionar sistemas de diseño entre cualquiera de los frameworks soportados.

Conversiones entre builders

• Gracias a cómo está estructurado, Kodavio permite convertir entre cualquier builder de origen y destino que esté soportado.
• Mantener coexistencia entre origen y destino mientras se valida el resultado, antes de hacer limpieza manual.

Administración segura

• Gestionar operaciones en WordPress con simulación previa, confirmaciones y registro de auditoría.
• Revisar o preparar acciones con plugins, configuraciones soportadas y mu-plugins.

Exportación a sitios estáticos

• Generar paquetes portables del sitio como HTML estático.
• En esta primera fase, pensado para sitios sencillos con formularios de Bricks o Elementor.
• El paquete incluye el HTML renderizado, las rutas, los assets y las notas necesarias para volver a conectarlo si hace falta.

Por qué nos importa

WordPress no es solo contenido. Un sitio real tiene builders, plantillas, plugins, formularios, taxonomías, estilos globales, frameworks CSS, integraciones y decisiones históricas.

Sin ese contexto, un agente puede generar algo que parece correcto, pero que no encaja con el proyecto o no se puede mantener bien dentro del builder.

Kodavio busca que el agente entienda antes de tocar.

Estado actual

Estamos en fase beta privada. La prioridad ahora es probarlo en proyectos reales, detectar fricciones, mejorar la calidad de generación con builders y reforzar la experiencia de entrada desde el agente.

El objetivo no es vender humo de «AI para todo». Es construir una capa operativa seria para WordPress.

Hoy hemos dado un paso importante en cómo trabajamos por dentro.

Komandesk ya no es solo nuestro panel de tareas: empieza a ser nuestro centro operativo para convertir trabajo repetible en flujos.

El primer caso serio: Flowtitude Design System.

Ahora, cuando hago cambios en FDS, el flujo prepara lo que antes acababa repartido en mil pasos: genera el .windpress, actualiza el repo, deja la noticia lista, crea la imagen social y marca si la documentación necesita algo más que una nota rápida.

Lo bonito no es solo automatizar. Es que el proceso tenga memoria, validaciones y revisión humana donde toca.

Y sí: ya podemos leer y escribir archivos .windpress de forma autónoma ;)

Esto abre una línea interesante para Flowtitude: no solo compartir estilos y componentes, sino también enseñar cómo crear flujos propios para que el trabajo digital pese menos.

Komandesk va justo de eso: convertir procesos que viven en la cabeza en una mesa de mando que ayuda a que las cosas salgan.

Hemos actualizado Flowtitude Design System para que la tipografía y el espaciado fluido sean más resistentes en navegadores con soporte incompleto de CSS math.

Hasta ahora, la escala dependía directamente de calc() y clamp() para generar los tokens text- y spacing.

Ahora FDS conserva los mismos tokens y clases de siempre, pero añade una capa de fallback estático: si el navegador no puede resolver cálculos fluidos avanzados, 
sigue recibiendo tamaños y espacios válidos.

En navegadores modernos todo funciona igual que antes: los tokens siguen siendo fluidos, configurables desde los knobs y sincronizados con Tailwind CSS 4. En navegadores más limitados, el sistema cae de forma segura a valores base y desktop.

También hemos mejorado la semántica interna de las secciones: ahora existe un token específico para media sección, --ft-padding-content-y-half, en lugar de hacer el cálculo directamente dentro del layout. Es un cambio pequeño, pero hace que el sistema sea más claro, más mantenible y más fácil de extender.

La documentación ya está actualizada con esta arquitectura de fallback + mejora progresiva.

Qué cambia para ti

• No cambian las clases que ya usas.
• text-, gap-, p-*, py-section y compañía siguen funcionando igual.
• Los navegadores modernos mantienen la experiencia fluida.
• Los navegadores con CSS math limitado reciben fallbacks seguros.
• El sistema queda mejor preparado para WordPress, WindPress y constructores visuales.

Pequeño ajuste técnico, mucha más tranquilidad en producción.

La novedad principal es que solucioné definitivamente el tema de la limpieza del caché. La versión anterior, la 1.3.0, se ponía a limpiar en un mal momento y de vez en cuando cortaba una compilación por la mitad. Eso ya no pasa: ahora espera a que termine lo que haya en marcha antes de tocar nada.

De paso he aprovechado para dar un repaso a la pantalla de la herramienta (Herramientas → WindPress Fix). Queda más clara: ves en vivo cuánto espacio está ocupando el caché y tienes un botón para vaciarlo a mano si te apetece.

También he empezado a meter mano a otro asunto que me llevabais comentando: el del canvas de Bricks que a veces no refresca los estilos después de muchas ediciones y obliga a recargar. Todavía no está cerrado, pero ya estoy sobre ello y en cuanto tenga algo sólido lo cuento por aquí.

A partir de hoy tienes un sitio único para consultar la documentación de todo el ecosistema Flowtitude:

👉 https://guias.flowtitude.com

Cuatro guías, una al lado de la otra, abiertas e indexadas:

• FDS — el sistema de diseño Flowtitude. Tokens (colores, espaciado, tipografía, radios y sombras), arquitectura CSS (base.css + typography.css) y componentes listos: tipografía Prose, botones, layouts y content-flex.
• FlowKit — plantillas y bloques listos para Bricks, montados sobre FDS para que tu sitio quede consistente sin pensar.
• BricksShift — migra contenido entre instalaciones de Bricks Builder sin pelearte con import/export manuales.
• elementor2bricks — convierte páginas de Elementor a Bricks conservando estructura y estilos. Migración real, no "te lo dejo en blanco".

Todo construido con la plantilla Syntax para que la lectura sea cómoda, con buscador y dark mode. Si hay algo que falta o que se entiende mal, decídnoslo y lo añadimos.

Comentarios y feedback, por aquí 🙌

¿Te ha pasado que WindPress lleva semanas funcionando, hasta que un día los cambios de Tailwind dejan de aparecer? Tocas una clase, pulsas Generate Cache, todo dice OK… y la web sigue igual.

No es tu hosting. Es tu navegador.

WindPress compila Tailwind dentro del navegador y va guardando el WASM, snapshots e intermedios en IndexedDB y Cache Storage. Eso se va llenando y, cuando revienta la cuota, lanza un QuotaExceededError silencioso: la pantalla dice "OK" pero el tailwind.css del servidor se queda obsoleto.

Lo que hace Fix 4 (nuevo en v1.3.0):

• Tras cada compilación correcta, vacía las entradas de WindPress en IndexedDB + Cache Storage + localStorage del navegador.
• Es seguro: el CSS final está en el servidor (wp-content/uploads/windpress/cache/). Lo del navegador es cache de trabajo, recuperable.
• Funciona en cualquier hosting. Sin Node.js, sin shell access, sin nada raro.
• Botón manual extra en Herramientas → WindPress Fix por si quieres limpiar a mano.

Cómo actualizar: WindPress Fix se actualiza solo. En unos minutos verás el aviso en Plugins → Actualizaciones dentro de tu WordPress. Un clic y listo. Recordad que las actualizaciones son exclusivas para miembros premium de Flowtitude.

Cualquier duda o feedback, por aquí. 🙌

Acabamos de publicar la documentación completa de FlowKit en:

https://flowkit.flowtitude.com

Incluye todas las secciones del plugin:

• Instalación y configuración — requisitos, activación de módulos, verificación
• Elementos — carrusel, parallax y los elementos WooCommerce (carrito, checkout, pedidos)
• Etiquetas dinámicas — las 70+ etiquetas {ft_*} con ejemplos y parámetros
• Queries personalizadas — pedidos, productos comprados, reseñas y más
• Módulos — estructura del plugin y cómo activar/desactivar cada parte
• Seguridad — headers, protección de login, registro de actividad
• Asistente IA — cómo funciona, casos de uso y habilidades disponibles
• Sistema de activos — capas CSS, Tailwind, sistema de diseño

La documentación se irá ampliando con más ejemplos y capturas. Si echáis en falta algo o encontráis algún error, comentadlo aquí.

Nuevo plugin gratuito para miembros que soluciona los problemas conocidos de compatibilidad entre WindPress y Bricks Builder.

Qué corrige:

1. Clases globales en caché CSS — Si nombráis vuestras clases globales con utilidades de Tailwind (por ejemplo bg-gray-950/90), WindPress no las incluía en la compilación. Ahora sí.
2. Error de escaneo _cssGlobalClasses — Bricks a veces guarda las clases globales como texto en vez de como lista, lo que hacía que WindPress fallara al escanear. El plugin detecta y repara esto automáticamente.
3. Elementos globales no escaneados — Las clases Tailwind dentro de elementos globales de Bricks no se compilaban. Ahora se incluyen en el escaneo.
4. Bricks Database en contexto REST — WindPress necesita que Bricks inicialice su base de datos para escanear. Esto no ocurría en peticiones REST, causando errores silenciosos. Corregido.
5. Rebuild de caché desde servidor — Herramienta para regenerar la caché de Tailwind directamente desde el servidor (útil cuando cambias de dominio o el Service Worker no funciona).

Instalación:

Descarga el ZIP, súbelo desde WordPress > Plugins > Añadir nuevo > Subir plugin. Al activar, los fixes 1, 3 y 4 funcionan automáticamente. Los fixes 2 y 5 están disponibles en Herramientas > WindPress Fix.

El plugin incluye actualizaciones automáticas para miembros premium.

Nota: WindPress v3.3.79 corrigió el crash del fix 2 en su lado, pero nuestro plugin sigue siendo necesario para los fixes 1, 3, 4 y 5 que no se han abordado.

El asistente ya no inventa. Antes de responder, consulta datos del sitio: colores del design system, productos WooCommerce, elementos Bricks, paginas. Usa el patron tool_use — la IA decide que necesita, lo pide al servidor, y responde con datos reales.

Tambien hemos instalado el MCP Adapter oficial de WordPress, asi que el sitio es accesible desde Claude Code o Cursor via MCP estandar.

Otros cambios: modos renombrados (Content, Styles), footer rediseñado, responde en el idioma del usuario.

Proximos dias: cerrar los issues de UX pendientes, mas herramientas (crear elementos, generar imagenes), y ejecucion automatica de acciones.