Cómo migrar un flujo de trabajo de Figma a un plugin de Open Design

Un flujo de trabajo de Figma suele empezar como memoria muscular: exporta estos frames, sincroniza esos tokens, reconstruye esa plantilla de presentación, entrega la especificación a ingeniería. Es el tipo de trabajo que vive en la cabeza de alguien y que hay que volver a explicar cada vez que arranca un proyecto nuevo.

El hilo de 0.8.0-preview plantea una petición más afilada: porta esa memoria muscular a un plugin. No un panel atornillado a un lienzo. No un script privado que solo un equipo puede ejecutar. Un flujo de trabajo de Open Design reutilizable que un agente pueda tomar, ejecutar, revisar y entregar a través del mismo bucle local-first que cualquier otra tarea de diseño.

Esta es la versión práctica de la convocatoria de plugins de 0.8.0-preview. Si tu equipo tiene hoy un flujo de trabajo de diseño repetible, esta publicación muestra cómo se ve convertirlo en una contribución con forma de plugin: qué archivos necesita, cómo lo toma el agente y dónde termina una vez publicado.

El flujo de trabajo que vale la pena portar es más pequeño de lo que crees

No empieces por «reemplazar Figma». Empieza por un trabajo molesto y repetible.

Buenos candidatos para un primer plugin:

Flujo de trabajo actual	Versión con forma de plugin
Exportar una página de marketing de Figma y reconstruirla en código	plugin `figma-migration` que extrae el layout, mapea tokens y genera un artefacto web
Convertir cada mes un kit de marca en diapositivas de lanzamiento	plugin de presentación con un `SKILL.md`, recursos de ejemplo y un sistema de diseño bloqueado
Crear el mismo mockup de onboarding móvil para cada cliente	plugin de pantalla móvil con campos de entrada para audiencia, tono, lista de funciones y plataforma
Convertir una especificación de componente en UI lista para Storybook	plugin de migración de código que lee el repositorio, mapea componentes y escribe un diff revisable

La unidad no es todo el departamento de diseño. La unidad es un flujo de trabajo que alguien ya repite dos veces por semana. Si no puedes describirlo en una sola frase —«convierte X en Y, con estas restricciones»— probablemente sean dos plugins, no uno, y deberías dividirlo antes de escribir una línea de Markdown.

Por eso la capa de skills de Open Design importa aquí. Un plugin no es una extensión de runtime opaca. Es una carpeta de archivos: un contrato SKILL.md, sistemas de diseño opcionales, ejemplos opcionales y un sidecar open-design.json que le dice a Open Design cómo mostrar y aplicar el flujo de trabajo. No hay formato binario entre tú y las reglas, lo que significa que cualquiera puede leer el plugin, bifurcarlo o arreglarlo después.

Un frame de diseño extraído de un lienzo y soltado en una caja de módulo portátil, seleccionado en un marco verde sobre un fondo editorial casi blanco — Portar un flujo de trabajo significa levantar la parte repetible del lienzo y llevarla a un plugin portátil.

El enfoque de Open Design es la portabilidad

La especificación del plugin enuncia el contrato sin rodeos: SKILL.md sigue siendo el contrato ejecutable del agente, mientras que open-design.json añade metadatos de marketplace, campos de entrada, valores por defecto, vistas previas y cableado de contexto.

Eso le da dos vidas a un mismo flujo de trabajo. En Open Design aparece como un plugin con vista previa, entradas, procedencia y una ruta de «usar» de un clic. En Claude Code, Cursor, Codex, Gemini CLI, OpenClaw u otro catálogo de skills, la misma carpeta sigue funcionando como una skill de agente plana porque el comportamiento central vive en Markdown. No estás escribiendo para un runtime que quedará obsoleto el año que viene; estás escribiendo un archivo que un agente leerá igual dentro de dos años.

El recorrido por la biblioteca ya explica las primitivas base: skills, sistemas, adaptadores y el daemon. Los plugins añaden distribución y repetibilidad alrededor de esas primitivas: son la unidad que un equipo publica, revisa y reutiliza, en lugar de la skill en bruto que un agente descubre por casualidad en disco.

Para un flujo de trabajo de Figma a código, las superficies suelen verse así:

Superficie	Archivo concreto
Comportamiento del agente	`SKILL.md`
Metadatos de Open Design	`open-design.json`
Contrato de marca o visual	`design-systems/{brand}/DESIGN.md`
Salida de ejemplo	`example.html` o `examples/{plugin-id}/example.html` dentro de la carpeta del plugin
Medios de vista previa	`preview/poster.png` o `preview/index.html` dentro de la carpeta del plugin

El resultado no es un generador de capturas de pantalla. Es un flujo de trabajo de agente reutilizable con un contrato visible: cada regla que sigue el agente está en la carpeta donde una persona puede leerla y editarla.

Una ruta de portado concreta

Esta es la ruta mínima para un plugin que porta un flujo de trabajo de página de aterrizaje de Figma. Son seis pasos en total, y la mayoría son Markdown.

1. Nombra el trabajo repetible

Escribe la única frase que describe el trabajo: «Convierte un frame de marketing de Figma en una página Astro responsive, en el sistema de marca de la casa, lista para revisión». Si no cabe en una frase, acótalo hasta que quepa. El nombre se convierte en el id de tu plugin (figma-workflow) y en el título que se muestra en el marketplace.

2. Escribe el contrato de la skill

SKILL.md es el contrato ejecutable que lee el agente. El front matter nombra la skill y su disparador; el cuerpo es el brief: forma de la entrada, ruta de salida, restricciones y una lista de revisión que el agente debe aplicarse a sí mismo antes de entregar.

---
name: figma-workflow
description: Turn one Figma marketing frame into a responsive Astro page in the house brand system.
trigger: When the user provides a Figma frame URL, screenshot, or exported assets for a marketing page.
---

## Input
- A Figma frame URL, a screenshot, or a folder of exported assets.
- The target brand system (defaults to `house`).

## Output
- An Astro page at `src/pages/<slug>.astro`, plus extracted tokens.

## Constraints
- Map Figma styles to the brand system's tokens. Do not invent colors or type.
- Preserve section order and copy. Flag any text that does not fit the grid.
- Mobile-first: every section must reflow at 360px before desktop.

## Review checklist
- [ ] Section IDs match the source frame.
- [ ] No raw hex values — tokens only.
- [ ] Responsive behavior verified at 360 / 768 / 1280.

3. Añade el sidecar de Open Design

open-design.json es lo que convierte una skill desnuda en un plugin de marketplace: título, descripción, entradas declaradas, vista previa y repositorio de origen. Estos son los metadatos que impulsan el panel de «usar» y la línea de procedencia.

{
  "id": "figma-workflow",
  "title": "Figma workflow",
  "description": "Port one Figma marketing frame into a responsive Astro page.",
  "inputs": [
    { "key": "figmaSource", "label": "Figma URL or screenshot", "type": "string", "required": true },
    { "key": "brand", "label": "Brand system", "type": "string", "default": "house" }
  ],
  "preview": "preview/poster.png",
  "source": "https://github.com/your-org/your-plugins"
}

4. Adjunta el sistema de diseño

Si el flujo de trabajo depende de reglas de marca, añade un archivo DESIGN.md bajo design-systems/ en lugar de enterrar el color y la tipografía en prosa. El agente ingiere el sistema como un contrato —paleta OKLch, escala tipográfica, postura de layout— de modo que diez pantallas generadas siguen pareciendo un solo producto. Mezclar sistemas a mitad de proyecto también funciona, porque no son más que texto.

5. Incluye un ejemplo real

Guarda un artefacto generado bajo examples/ para que quienes revisan puedan juzgar la salida, no solo la promesa. Un example.html conocido y bueno vale más que un párrafo de descripción; le da al agente algo con qué hacer coincidencia de patrones y le da a un mantenedor algo que aprobar.

Reunido todo, el plugin es una sola carpeta legible:

plugins/community/figma-workflow/
  SKILL.md              # the agent contract: trigger, output, constraints, review
  open-design.json      # marketplace metadata: title, inputs, preview, source
  design-systems/
    house/
      DESIGN.md         # the brand contract the agent must respect
  examples/
    figma-workflow/
      example.html      # one known-good artifact reviewers can judge
  preview/
    poster.png          # marketplace preview media

6. Valida y empaqueta

Ejecuta los comandos del plugin antes de abrir un PR. La ruta actual del CLI usa un id de plugin en minúsculas. Evita nombres de registro separados por barras al hacer scaffold; od plugin scaffold crea <out>/<id>/..., así que los comandos siguientes apuntan a esa carpeta generada:

od plugin scaffold --id figma-workflow --title "Figma workflow" --out ./plugins/community
od plugin validate ./plugins/community/figma-workflow --no-daemon
od plugin pack ./plugins/community/figma-workflow

Cuando el plugin esté listo para la revisión del registro, autentícate a través de GitHub con od plugin login y od plugin whoami --json, y luego sigue la documentación de publicación para la ruta de revisión actual. Open Design no almacena tus credenciales de GitHub.

Cómo se ve esto en un equipo de diseño real

Imagina un equipo de producto pequeño con un frame de Figma para una página de lanzamiento, un sistema de marca de la casa y un ritmo de release mensual.

Antes del plugin, el flujo de trabajo es una cadena de entregas: el diseñador exporta frames, el ingeniero reconstruye el layout, el PM reescribe el texto, alguien revisa la deriva de tokens, otra persona reporta bugs. El trabajo es familiar, pero la memoria vive en las personas, y se fuga cada vez que alguien falta, cambia de equipo u olvida la única restricción que importaba.

Después del plugin, el flujo de trabajo se convierte en un artefacto ejecutable:

Paso	Quién lo dirige
Elegir el plugin	Diseñador o PM
Adjuntar URL de Figma / captura / recursos locales	Diseñador
Elegir el sistema de marca	Diseñador o ingeniero de diseño
Generar el artefacto web	Claude Code, Cursor, Codex, Gemini CLI u otro agente detectado
Revisar IDs de sección, texto, densidad y comportamiento responsive	Una persona en la vista previa de Open Design
Exportar o entregar los archivos	La misma carpeta de proyecto local

El equipo sigue necesitando criterio: ahí vive el paso de revisión, y ningún plugin lo reemplaza. Lo que el plugin elimina es la re-explicación: las restricciones, el mapa de tokens y la ruta de salida dejan de ser conocimiento tribal y se convierten en un archivo del repositorio.

Qué hacer a continuación

Si tu equipo tiene una exportación de Figma, una sincronización de tokens, un kit de marca o una plantilla de presentación que vuelve una y otra vez, porta primero la porción repetible más pequeña. Empieza con un SKILL.md, añade open-design.json, adjunta el DESIGN.md de la marca, suelta un ejemplo real, valídalo y abre el PR antes de que el flujo de trabajo crezca hasta convertirse en una herramienta privada que nadie más puede reutilizar. El ejemplo de captura de pantalla a prototipo muestra la versión con forma de plugin de principio a fin: una skill portátil más un sidecar de Open Design.

Prueba este flujo de trabajo.

Lecturas relacionadas

31 skills, 72 sistemas: cómo funciona la biblioteca de Open Design — las primitivas que envuelve un plugin
Por qué construimos Open Design como una capa de skills, no como un producto — por qué el flujo de trabajo tiene forma de archivo en lugar de forma de cuenta
La alternativa de código abierto a Figma — dónde aterriza portar tu flujo de trabajo en relación con el referente del sector
Flujo de trabajo de diseño BYOK: ejecuta Claude, Codex o Qwen con tu propia clave — cómo el mismo plugin puede ejecutarse en la ruta de modelo que tu equipo ya confía