Objetivo
Trabajar más allá de Figma, uniendo herramientas.
Demostrar conocimiento de programas de edición de código, conectando Figma con Cursor a través de MCPs.
Por qué
Documentar es una de las partes más tediosas de un design system, pero también una de las más necesarias para que desarrollo lo use. Un DS que no se usa, falla. Notion facilita ese uso: no pide cuenta ni curva de aprendizaje.
La IA permite llevar esa documentación a Notion a través de MCPs (Model Context Protocol), el “cable USB universal” que conecta la IA con otras aplicaciones.
El experimento
Para poder hacer este test, he utilizado un pequeño design system propio llamado Aegis, pensado para evolucionar hacia componentes que la IA pueda usar directamente.
La skill
Una skill es un conjunto de instrucciones que le dice a la IA cómo hacer un trabajo siempre igual, sin explicarlo de cero cada vez. Aquí conecta Figma (donde trabajas) con Notion (donde queda la documentación) a través de Cursor: tú describes en lenguaje natural qué documentar, y el agente lee Figma, organiza la información y la escribe en Notion.
Cómo funciona
-
Abrir Figma
La IA accede al archivo de Figma.
-
Descubrir qué hay
Localiza variables (tokens de color, tipografía, espacio) y componentes.
-
Preguntas mínimas
Idioma, formato de color, si quieres copia local, etc.
-
Montar Notion
Crea la página principal, índices y secciones.
-
Rellenar con datos reales
Completa foundations y componentes con datos del archivo, no inventados.
-
Cerrar y revisar
Resumen de la ejecución y revisión automática lista.
Las foundations salen de la tabla de variables de Figma.
Los componentes se documentan mirando la pieza viva (variantes, estados, variables ligadas) y una vista embebida del Playground o Showcase, cuando existe.
Cómo se construyó
El proceso fue iterativo: pedir de más, obtener algo genérico, y acotar hasta respetar la estructura real del design system.
Empecé solo con foundations, para fijar lo básico: qué preguntar, cómo organizar Notion, cómo sacar tokens sin inventar valores.
De ahí salieron dos ajustes clave: separar foundations y componentes porque no se documentan igual, y reducir el número de preguntas, que generaba fricción. La skill pasó a inferir el alcance del archivo por sí sola.
En archivos grandes, además, dejó de releer Figma en cada paso: ahora descubre una vez, guarda progreso y rellena Notion desde esa copia.
Con las reglas más sólidas, probé la skill en un caso más exigente: un accordion de una librería más consolidada. Ahí aparecieron fallos nuevos: documentación ignorada, colores en bruto en vez de variables… que terminaron de fijar las normas: respetar la estructura, leer el componente vivo y documentar solo los cambios entre variantes.
Lo útil del error no fue arreglar un bug, sino ver dónde la IA aporta velocidad y dónde sigue haciendo falta criterio humano. Esos fallos que todos sabemos que la IA hace, fue lo que provocó la creación del siguiente paso: el hook.
El hook
Un script que Cursor lanza cuando el agente termina un turno, porque que la IA “acabe” no significa que la documentación esté completa. Lee el resumen de la ejecución y escribe un mensaje: qué está bien, qué no se completó y qué queda pendiente. Solo se activa cuando la skill termina.
Lo bueno y lo malo
Lo bueno
Acelera el primer borrador de documentación.
Obliga a escribir reglas que antes solo vivían en la cabeza del equipo.
Encaja con un flujo Cursor > revisión humana > Notion.
El hook cierra el ciclo: documenta y dice qué falta.
Lo malo
Sin un DS bien acotado, alucina estructura y vocabulario.
El embed y la sync con Notion aún exigen cuidado con permisos y URLs públicas.
Resultado
El experimento se documenta en Notion: foundations, el Button y las notas del proceso.
No es solo “exportar Figma a Notion”: es un sistema skill + hook que documenta con datos reales y revisa al final qué se cumplió y qué no.