El workflow de sistemas de diseño con IA que por fin me dio resultados de calidad

El workflow de sistemas de diseño con IA que por fin me dio resultados de calidad

Pasé buena parte de un sábado discutiendo con Claude sobre un botón.

No sobre la lógica. El botón. La llamada a la acción principal en una pantalla de paywall para una app financiera que estaba prototipando. Había conectado el MCP de Figma, apuntado a Claude hacia mi sistema de diseño, escrito "constrúyeme un paywall usando nuestros componentes", y lo que produjo se veía como cualquier otra pantalla generada por IA que haya visto. Esquinas redondeadas que parecían arbitrarias. Un degradado que no existía en ningún lugar de mi sistema. Espaciados que estaban casi bien, como una banda tributo que es casi igual a la original. Lo suficientemente parecido para reconocerlo. Lo suficientemente diferente para doler.

Cerré el archivo. Me preparé un café. Me senté y realmente leí lo que había estado haciendo.

Esto fue lo que entendí: había estado tratando a Claude como una varita mágica. La agitaba sobre un archivo de Figma y esperaba un resultado perfecto en píxeles. Y en silencio, hacía exactamente lo que cualquier modelo hace cuando le das un montón de datos sin etiquetar: promediar. Promediaba mis tokens contra todos los sistemas de diseño que había visto. Promediaba mis botones contra todos los botones de internet. El resultado era un fantasma de mi sistema de diseño disfrazado de manera convincente.

La solución no era un mejor prompt. La solución era datos de entrenamiento estructurados: tokens con descripciones, componentes agrupados con reglas de uso, pantallas de ejemplo específicas; luego iterar localmente en Claude Code antes de enviar un solo frame a Figma. Una vez que hice eso, mi UI de primer intento pasó de "sí, voy a rehacer esto" a "en realidad, solo tengo que ajustar dos estilos de texto".

Ese es el flujo de trabajo que quiero mostrarte. Nada revolucionario. Solo estructura aburrida y paciente que hace que Claude se comporte como un diseñador junior que realmente ha leído tu sistema, no como un turista borracho que ha oído hablar de diseño.

Por qué Figma AI en estado puro y los flujos de trabajo de “solo haz un prompt” se desmoronan

Permíteme describir el modo de fallo con precisión, porque la mayoría de los artículos omiten esta parte.

Instalas el servidor MCP de Figma. Conectas Claude a tu archivo de Figma. Escribes “genera una pantalla de configuración usando nuestro sistema de diseño”. Claude se pone a trabajar, lee algunos metadatos, produce algo. Lo abres. Está mal en formas difíciles de nombrar: la jerarquía se siente extraña, el padding es el 16 equivocado (el 16 que existe en todos los sistemas, no el 16 que usas tú), la sombra de la tarjeta es parecida pero no exactamente tu sombra. Técnicamente usa tus componentes. Simplemente no entiende cuándo usarlos.

Esto sucede por una razón que resulta obvia una vez que la nombras: un archivo de sistema de diseño no es un set de datos de entrenamiento. Un archivo de sistema de diseño es un almacén. Los tokens están en una colección. Los componentes en otra. Las reglas de uso viven en un documento de Notion que nadie lee. El pegamento —el conocimiento real de “¿cuándo usamos la superficie elevada versus la elevada?”— solo existe en la cabeza de tu diseñador senior.

Cuando Claude lee ese almacén, ve nombres y valores. No ve intención. Y sin intención, cada decisión ambigua se resuelve promediando estadísticamente contra todo lo que ha visto en internet. Así es como terminas con un paywall que se parece vagamente a Stripe, vagamente a Linear, y en nada a tu app.

La postura de Figma sobre esto es en realidad bastante clara: han publicado una guía para crear habilidades personalizadas precisamente por esta razón. El servidor MCP viene con habilidades fundamentales como figma-use y figma-generate-library, pero esas son solo andamiaje. Esperan que tú superpongas tu propio conocimiento de dominio encima. La mayoría no lo hace. Luego culpan al modelo.

Yo también culpé al modelo. Luego dejé de hacerlo.

Hay un tercer problema que la mayoría de los tutoriales esquivan, y lo abordaremos más adelante en la sección de implementación: tiene que ver con lo que ocurre cuando un modelo ve tres variantes de un componente “card” y tiene que elegir una. Te mostraré cómo se ve eso y cómo solucionarlo. Pero primero necesitamos tokens que hablen.

Tokens que Hablan: La Plantilla que lo Cambió Todo

Aquí está el mayor descubrimiento de todo este flujo de trabajo, y es vergonzosamente simple.

Claude es un modelo de lenguaje. Tus tokens son en su mayoría números y códigos hexadecimales. Cuando le das a un modelo de lenguaje una entrada no lingüística, tiene que inferir el significado. Cuando le das una entrada lingüística, sigue instrucciones. Así que la solución es hacer que tus tokens hablen inglés.

Uso una plantilla de cuatro columnas para cada token. Nombre. Valor claro. Valor oscuro. Una descripción en una frase de cuándo usarlo.

Aquí tienes un fragmento de mis tokens de superficie reales:

| Token                  | Light    | Dark     | When to use                                      |
|------------------------|----------|----------|--------------------------------------------------|
| surface-base           | #FFFFFF  | #0B0B0F  | The page background. Nothing sits behind this.   |
| surface-raised         | #F7F7F9  | #15151B  | Cards, list rows, anything one layer above base. |
| surface-elevated       | #FFFFFF  | #1D1D25  | Modals, popovers, menus — floating UI only.      |
| surface-sunken         | #F0F0F3  | #08080C  | Input fields, inset wells, read-only regions.    |
| surface-brand-subtle   | #EEF2FF  | #1A1D3A  | Brand-tinted backgrounds for promoted content.   |

Lee esa columna de "When to use". Esa es la parte que le importa a Claude. Esa es la parte que convierte un token de un valor en una instrucción.

Haz esto para cada categoría de token — superficie, contenido (texto), borde, acción, estado, elevación, radio, espaciado, movimiento. Sí, espaciado. space-2: 8px — tight rhythm inside dense components like form field groups es mil veces más útil que space-2: 8px.

Esto está alineado con lo que la comunidad de sistemas de diseño ha estado adoptando en 2026 — tokens semánticos con intención incorporada en el nombre, junto con documentación que describe el propósito, no la apariencia. El giro que yo añado es que la documentación debe vivir junto al token en el formato que Claude consume, no en una wiki separada.

Guarda esta tabla como un archivo markdown. design-tokens.md. Mantenlo en el repositorio de tu proyecto, justo al lado de tu código. Este archivo es ahora tu verdadero sistema de diseño — las variables de Figma son solo la salida renderizada.

Un apunte rápido — me resistí a esto durante semanas porque asumí que Claude podría simplemente leer las descripciones de variables de Figma directamente. Técnicamente puede. Pero las descripciones que la mayoría de los equipos escriben en Figma suelen estar vacías o dirigidas a diseñadores ("primary brand color") en vez de a un modelo que tiene que decidir entre cinco azules a las 2 AM de un sábado. Reescríbelas para el modelo. Tus diseñadores igual podrán leerlas. Nadie pierde.

Eso es la mitad de la batalla. La otra mitad son los componentes — y los componentes son donde el flujo de trabajo suele morir si no los agrupas correctamente.

Agrupando componentes para que Claude no entre en pánico

Esto lo aprendí por las malas. Si le das a Claude un sistema de diseño con 140 componentes en una lista plana y le pides que construya una pantalla, se comporta como un contratista al que le entregan una ferretería y le dicen que construya una cocina. Técnicamente tiene todo lo que necesita. Prácticamente, va a usar el martillo equivocado.

La solución: agrupa tus componentes en categorías semánticas, con una habilidad dedicada para cada grupo (o, si quieres mantenerlo simple, una sola habilidad que conozca todos los grupos). Las tres agrupaciones que cubren el 90% de la interfaz de producto:

1. Elementos de formulario. Inputs, áreas de texto, menús desplegables, casillas de verificación, radios, interruptores, selectores de fecha, zonas de carga de archivos, fila de formulario, error de formulario, texto de ayuda de formulario. Todas las variantes. Todos los estados: por defecto, enfoque, error, deshabilitado, cargando.

2. Navegación. Barras superiores, navegación lateral, barras de pestañas, migas de pan, paginación, enlaces de retroceso, controles segmentados, stepper. Aquí los estados también importan: activo, hover, deshabilitado, colapsado.

3. Visualización de datos. Tablas, tarjetas, elementos de lista, mosaicos de estadísticas, insignias, etiquetas, avatares, estados vacíos, esqueletos de carga, gráficos, pies de paginación. Aquí es donde la mayoría de las pantallas generadas por IA se desmoronan porque el modelo tiende a usar tablas cuando lo correcto sería una cuadrícula de tarjetas, o mosaicos de estadísticas cuando lo adecuado es una lista.

Para cada componente dentro de cada grupo, documenta tres cosas para Claude:

• Variantes — todas, con los nombres clave de variante exactamente como aparecen en el panel de propiedades de Figma
• Props — todos los booleanos y enums que expone el componente
• Regla de uso — una frase: "Usa la variante compacta para tablas densas con más de 8 columnas. Variante por defecto para todo lo demás."

Esa tercera línea es la que evita que Claude elija una variante al azar solo porque el nombre suena bien.

Este es el patrón que desarrollé en mi artículo anterior sobre Figma MCP, y es el patrón que hizo que el flujo de trabajo actual realmente produjera diseños utilizables en el primer intento. Si ya has construido sistemas de diseño antes, sabes que la parte más difícil no es definir los componentes, sino documentar cuándo usar cada uno. Esa documentación siempre ha sido valiosa para los humanos. Resulta que es aún más valiosa para los modelos.

Consejo profesional: si tienes más de un diseñador en tu equipo, júntalos en una sala y discute en voz alta las reglas de uso antes de escribirlas. La discusión es la especificación. Los desacuerdos que surjan son exactamente los casos límite que Claude, de otro modo, interpretaría mal. Escribe la respuesta consensuada como la regla.

Pensarías que ya estamos listos para generar. No lo estamos. Falta una pieza más, y es la que la mayoría de la gente omite por completo.

Deja de decir "Hazme un modal": muéstrale a Claude exactamente lo que quieres decir

El mayor error que veo en la ingeniería de prompts para diseño con IA es la vaguedad disfrazada de brevedad. "Hazme un modal." "Diseña un dashboard." "Crea una pantalla de configuración." Estos parecen prompts precisos. No lo son. Son el equivalente a decirle a un contratista "hazme una cocina" sin ningún plano.

Lo que realmente funciona es: combina tu habilidad con los componentes con ejemplos específicos de pantallas reales de apps en producción.

Aquí es donde Mobbin justifica su suscripción. La biblioteca de Mobbin cuenta con más de 600,000 pantallas de más de 1,200 apps en producción a partir de 2026, lo que significa que para casi cualquier patrón de UI que quieras construir, existe una versión ya lanzada, creada por un equipo que probablemente ha pensado en ello más a fondo de lo que tú tendrás tiempo de hacer.

Mi flujo de trabajo real, usando el ejemplo de paywall del sábado:

1. Abre Mobbin. Busca "paywall" dentro de la categoría Finanzas.
2. Abre el paywall de Rocket Money. Abre el de Copilot. Abre el de YNAB.
3. Haz capturas de pantalla de dos o tres que encajen con el tono que buscas.
4. Sube las capturas a Claude Code como referencias visuales junto con tu skill de tokens y de componentes.
5. Prompt: "Crea una pantalla de paywall para una app de finanzas. Referencia de estilo y layout adjunta. Usa nuestros design tokens y componentes. Salida en HTML. Hero: plan anual a $79.99 con pastilla 'Ahorra 40%'. Tres filas de características. Toggle mensual. Logos de confianza al pie."

Ese prompt tiene todo lo que un diseñador necesita. Referencias para el estilo y la composición. Especificidad en el contenido. Restricciones sobre los bloques de construcción. Sin ambigüedad para que el modelo la resuelva promediando.

Compáralo con "hazme un paywall". La primera versión te da una pantalla real. La segunda versión te da una alucinación de pantalla.

(Si no quieres Mobbin, las alternativas en 2026 son realmente buenas: InspoAI añade búsqueda en lenguaje natural, Appshots muestra flujos en vez de pantallas individuales, Webframe es web-first. Yo sigo usando Mobbin porque las categorías de Finanzas y SaaS B2B son más profundas allí. Tu experiencia puede variar.)

Un apunte más sobre las referencias: usa dos o tres, no una. Con una referencia, Claude la copia. Con tres referencias, Claude interpola, que es mucho más parecido a lo que realmente quieres. El arte del prompt está en la distancia entre los ejemplos que eliges.

Bien. Ya tienes los tokens. Ya tienes los componentes agrupados con reglas de uso. Ya tienes pantallas de ejemplo. Ahora llegamos a la parte donde realmente instalas la maquinaria y generas.

Instalando las Skills de Figma en Claude

Dos skills hacen el trabajo real en este flujo, y ambas se instalan en cinco minutos.

1. figma-use — esta es la skill fundamental del propio servidor MCP de Figma. Permite que Claude escriba en tu canvas de Figma: crear frames, instanciar componentes, aplicar variables, establecer estilos. Todo lo que entra en Figma pasa por esta skill. La documentación oficial de Figma cubre la instalación; la versión corta es: clona el repositorio de la skill, comprímelo en un zip, colócalo en el directorio de skills de Claude, reinicia la sesión. Listo.

2. Tu propia skill "Apply Design System" — esta es la pieza personalizada. Un solo archivo markdown que tú mismo redactas. Contiene:

• Un enlace o referencia a tu archivo design-tokens.md
• Un enlace o referencia a tu archivo components.md (agrupados por categoría, con reglas de uso)
• Un preámbulo que le indica a Claude cómo aplicar esto: "Utiliza siempre tokens semánticos. Nunca uses valores hexadecimales sin procesar. Elige siempre la variante de componente cuya regla de uso coincida con el contexto. Si tienes dudas, pregunta antes de adivinar."
• Una lista de comportamientos prohibidos: "No inventes nuevos tokens. No crees nuevos componentes. No uses degradados que no existan en la lista de tokens. No redondees esquinas con valores de radio arbitrarios."

Ese preámbulo importa. La lista de comportamientos prohibidos, en particular, es lo que detiene la deriva de "promediar hacia internet". No estás enseñando al modelo a ser creativo. Le estás enseñando a ser disciplinado. La disciplina es lo que quieres en un primer pase.

Envía ambas skills. Reinicia Claude Code. Verifica que se hayan cargado.

En este punto tienes una instancia de Claude que entiende tus tokens en inglés, conoce tus componentes en contexto, tiene pantallas de referencia para el patrón que deseas y cuenta con skills que le permiten escribir en Figma. Esta es la configuración. Ahora generamos — y aquí viene la parte no obvia que nadie te cuenta.

Si prefieres que alguien configure todo este flujo de principio a fin para un sistema de diseño en producción — skill de tokens, skills de componentes, cableado MCP, despliegue al equipo — ese es un servicio específico que ofrezco. Puedes ver lo que he construido en fiverr.com/s/EgxYmWD.

Genera Localmente en Claude Code Primero. Luego Empuja a Figma.

Aquí es donde la mayoría de los tutoriales se equivocan. Le piden a Claude una vez, dejan que envíe directamente a Figma, ven el resultado y empiezan a iterar dentro de Figma. Ese flujo de trabajo es lento, consume muchos tokens y produce peores resultados porque cada iteración hace un viaje de ida y vuelta por el servidor MCP.

El patrón correcto: itera en Claude Code como HTML primero. Solo envía a Figma cuando el HTML sea aceptable.

Mi secuencia real para el paywall financiero:

1. Prompt con todo cargado — skill de tokens, skill de componentes, tres referencias de Mobbin, el brief de contenido específico. Pido salida en HTML con clases de Tailwind mapeadas a mis design tokens.

2. Claude genera el HTML en línea en Claude Code. Lo visualizo en una previsualización de navegador. Tarda unos 8 segundos. Sin ida y vuelta a Figma.

3. Lo critico. No "hazlo mejor". Específico: "El CTA principal está usando action-primary-subtle pero esto es una superficie de conversión — usa action-primary-bold. El espaciado de la fila de features está usando space-3; este patrón requiere space-4 porque los íconos son de 24px. La fila de logos de confianza no tiene un divisor."

4. Claude actualiza el HTML. Otros 6 segundos. Vuelvo a renderizar.

5. Repito ese bucle dos o tres veces. En esta etapa, cada iteración es barata — sin Figma, sin payload MCP, solo texto.

6. Cuando el HTML está al 90%, le pido a Claude que lo envíe a Figma usando el skill figma-use. Esta es la operación costosa, y solo la hago una vez por diseño.

7. Claude escribe los frames en Figma. Componentes reales. Variables reales. Variantes reales. Responsive. Capas nombradas. Auto-layout aplicado. Pequeños fallos en estilos de texto, que cubriré en un momento.

Este patrón local-first reduce mi tiempo de iteración aproximadamente a la mitad y consume significativamente menos tokens. También produce mejores resultados, porque estoy iterando sobre el diseño mientras aún es barato cambiarlo. Para cuando lo envío a Figma, el diseño está esencialmente terminado — Figma es el destino, no el taller.

Un detalle específico a destacar: cuando pidas salida en HTML, especifica los nombres de los tokens en el prompt. "Usa clases como bg-surface-raised, text-content-primary, rounded-radius-md." Esto obliga a Claude a tratar los tokens como ciudadanos de primera clase en el marcado generado. Puedes conectarlos luego a tu configuración real de Tailwind, o simplemente leerlos como documentación de qué tokens se usaron y dónde. De cualquier forma, obtienes una salida auditable.

La Parte Honesta: Lo Que Este Flujo de Trabajo Sigue Haciendo Mal

He lanzado docenas de pantallas a través de este pipeline hasta ahora. Es una mejora enorme respecto al prompting tradicional. No es magia. Aquí están, sin endulzar, las cosas específicas que todavía falla.

Los estilos de texto se omiten más que cualquier otra cosa. Claude clava el espaciado, los colores, los componentes, el layout — y luego aplica text-body-md a un encabezado que debería ser text-heading-sm. No entiendo del todo por qué la tipografía es específicamente el punto débil. Mi teoría es que los tokens de estilo de texto tienden a codificar una intención más sutil (“usa esto para encabezados de listas de densidad media”) que los tokens de color o espaciado, y el modelo tiene menos señales a las que aferrarse. En cualquier caso: siempre audita la tipografía manualmente en Figma. Reserva de tres a cinco minutos por pantalla para esta limpieza.

La dirección de auto-layout a veces se invierte. Una fila se convierte en columna, o viceversa, especialmente dentro de componentes anidados. Normalmente es una corrección de un solo clic en Figma, pero es un impuesto molesto.

La personalidad de marca no se transmite. El flujo de trabajo produce pantallas que son correctas. No produce pantallas que sean con alma. Ese 10% extra — la micro-interacción, esa elección de composición inusual, el tratamiento tipográfico que hace que tu app se sienta única — todavía tiene que venir de un humano. Este flujo de trabajo te lleva a un primer borrador pulido y alineado al sistema. No te lleva al arte.

A veces los tokens se aplican literalmente en vez de semánticamente. Si Claude ve surface-raised: #F7F7F9 en mi archivo de tokens, ocasionalmente escribe #F7F7F9 en el HTML en vez de bg-surface-raised. El preámbulo que lo prohíbe ayuda, pero no lo elimina. Audita el código generado.

La paridad claro/oscuro requiere revisión manual. Incluso con ambos valores definidos en tus tokens, a veces Claude elige una combinación que funciona en claro pero falla el contraste WCAG en oscuro. Lo verifiqué en el paywall: la fila del logo de confianza pasaba el contraste 4.5:1 en modo claro pero quedaba en 3.2:1 en oscuro. Haz una comprobación de contraste antes de lanzar; el estándar para 2026 sigue siendo 4.5:1 para texto de cuerpo.

Si enumerara estos fallos sin el contexto de cuánto mejor es el flujo de trabajo con la estructura, parecería peor de lo que es. Así que déjame darle la vuelta.

Qué Cambia Realmente: Calidad del Primer Borrador y Tiempo de Limpieza

Aquí está la verdadera diferencia, observada a lo largo de mis propios proyectos durante las últimas ocho semanas. No te voy a dar porcentajes inventados porque no llevo un registro en una base de datos. Lo que sí registro es cuántas pantallas se envían sin necesidad de retrabajo significativo, y el patrón es lo suficientemente consistente como para confiar en él.

Antes de este flujo de trabajo: la salida del primer borrador con prompts genéricos requería reconstrucciones estructurales la mayoría de las veces. Los componentes estaban mal, la jerarquía era incorrecta, la mitad de los tokens ni siquiera se aplicaban. El camino realista hacia una pantalla lista para envío era de 45 a 90 minutos de limpieza por pantalla, y normalmente reconstruía partes importantes a mano.

Después de este flujo de trabajo: la salida del primer borrador es estructuralmente correcta. Los tokens se aplican. Los componentes son los correctos. La jerarquía del layout está cerca de la final. La limpieza consiste principalmente en estilos de texto, uno o dos ajustes de espaciado y una auditoría de contraste. El camino realista hacia una pantalla lista para envío es de 10 a 15 minutos de limpieza por pantalla, y ahora edito en vez de reconstruir.

La ganancia compuesta es la consistencia. Un miembro del equipo que sigue esta misma configuración produce pantallas que parecen salir del mismo sistema, porque realmente salen de él. Antes de las habilidades estructuradas, las pantallas generadas por IA tenían una especie de entropía: cada generación se desviaba ligeramente. Después de las habilidades estructuradas, la desviación está limitada por la propia descripción del sistema.

Para equipos que trabajan con sistemas de diseño, este patrón refleja lo que Figma documentó en su flujo de trabajo de IA a Figma para sistemas de diseño a principios de este año: estructura el sistema y luego deja que los agentes operen dentro de esa estructura. La mejora no viene de modelos más inteligentes. Viene de rieles más ajustados.

Hay algo más que vale la pena mencionar. La hora que dedicas a escribir descripciones de tokens y reglas de uso de componentes es una hora que se recupera cada vez que generas una pantalla. Después de la quinta o sexta pantalla, el flujo de trabajo es netamente positivo por un margen enorme. Antes de la quinta, estás invirtiendo. No abandones en la pantalla dos. Abandona en la pantalla diez si aún no funciona, y para entonces sabrás exactamente qué parte de la configuración necesita ajustes.

El Paywall, Terminado

El paywall que devoró mi sábado al inicio de este artículo fue reconstruido a la mañana siguiente en unos 40 minutos, incluyendo el trabajo con tokens y componentes que debí haber hecho desde el principio. La versión final usó mi verdadero action-primary-bold para el CTA, el surface-elevated correcto para la tarjeta del plan, y el ritmo específico space-4 para las filas de características. El divisor con el logo de confianza estaba presente. Tanto en modo claro como oscuro, ambos pasaron las pruebas de contraste. Los estilos de texto solo necesitaron una pasada de limpieza en Figma. Listo para enviar.

La lección no es que el diseño con IA funcione ahora. La lección es que el diseño con IA funciona cuando tratas tu sistema de diseño como datos de entrenamiento y haces iteraciones localmente antes de comprometerte con el lienzo. Funciona cuando dejas de esperar que el modelo lea tu mente y empiezas a describir lo que tienes en mente con tal especificidad que el modelo no tenga que adivinar.

Esto es lo que quiero que hagas hoy — no la próxima semana, ni después de leer tres artículos más. Abre tu sistema de diseño. Elige una categoría de tokens. Superficie, contenido o espaciado. Escribe una descripción de una frase sobre “cuándo usar” para cada token de esa categoría. Ese es tu primer paso. Ese es el verdadero desbloqueo. Si haces eso con una categoría hoy, estarás más avanzado que la mayoría de los equipos. Si lo haces con todas las categorías esta semana, tendrás un sistema de diseño que un modelo realmente podrá aplicar.

El próximo paywall que construyas no te robará el sábado. Te llevará cuarenta minutos. Y esos cuarenta minutos serán, en su mayoría, para limpiar la tipografía, lo cual — seamos honestos — ibas a hacer de todas formas.

Preguntas Frecuentes

¿Necesito el servidor Figma MCP de pago para usar este flujo de trabajo?

No. El servidor Figma MCP principal y la habilidad básica figma-use son gratuitos para instalar. Se requiere un plan de pago de Figma para algunas operaciones de escritura en bibliotecas compartidas de equipo, pero el trabajo individual en archivos de borrador funciona en el nivel gratuito. Consulta la sección de implementación anterior para ver la configuración completa.

¿Esto funcionará con Codex u otros modelos que no sean Claude?

Parcialmente. El servidor Figma MCP admite múltiples clientes MCP, incluido Codex, por lo que el lado de Figma funciona. El patrón de carga de habilidades es específico de Claude: Codex utiliza su propio formato de extensión. La idea central (tokens estructurados más habilidades de componentes más pantallas de referencia) es independiente del modelo y se puede transferir a cualquier agente de codificación capaz.

¿Cuánto tiempo lleva configurar las habilidades de tokens de diseño y componentes por primera vez?

Calcula entre tres y seis horas de trabajo concentrado para un sistema de tamaño medio, suponiendo que tus tokens y componentes ya estén documentados en algún lugar. El coste de tiempo está casi totalmente en redactar las descripciones de "cuándo usar" — la creación mecánica de los archivos de habilidades es rápida.

¿Puede Claude crear nuevos componentes si se lo pido?

Sí, pero deberías prohibírselo en el preámbulo de tus habilidades para trabajos de producción. Permitir que Claude invente componentes sobre la marcha rompe la consistencia del sistema, que es precisamente la razón por la que haces esto. Si realmente se necesita un nuevo componente, diséñalo deliberadamente en Figma primero, luego agrégalo a tu habilidad de componentes y después genera con él.

¿Cuál es el error más común al comenzar con este flujo de trabajo?

Omitir las descripciones de "cuándo usar" en los tokens. Los equipos copian los nombres y valores de los tokens, piensan que eso es suficiente y se preguntan por qué el resultado sigue viéndose genérico. Las descripciones son la parte que convierte un token de dato en instrucción. Sin ellas, vuelves a hacer prompts genéricos con pasos extra.

Trabajemos Juntos

¿Buscas construir sistemas de IA, automatizar flujos de trabajo o escalar tu infraestructura tecnológica? Me encantaría ayudarte.

• Fiverr (desarrollos e integraciones a medida): fiverr.com/s/EgxYmWD
• Portafolio: mejba.me
• Ramlit Limited (soluciones empresariales): ramlit.com
• ColorPark (diseño y branding): colorpark.io
• xCyberSecurity (servicios de seguridad): xcybersecurity.io