Como portar um fluxo do Figma para um plugin do Open Design

Um fluxo do Figma normalmente começa como memória muscular: exporte estes frames, sincronize aqueles tokens, reconstrua aquele template de deck, entregue a especificação para a engenharia. É o tipo de trabalho que mora na cabeça de alguém e é reexplicado toda vez que um projeto novo começa.

A thread do 0.8.0-preview faz um pedido mais afiado: porte essa memória muscular para um plugin. Não um painel parafusado num canvas. Não um script privado que só um time consegue rodar. Um fluxo reutilizável do Open Design que um agente possa pegar, executar, revisar e repassar pelo mesmo loop local-first de qualquer outra tarefa de design.

Esta é a versão prática da convocação de plugins do 0.8.0-preview. Se o seu time tem um fluxo de design repetível hoje, este post mostra como é transformá-lo em uma contribuição em formato de plugin — que arquivos ele precisa, como o agente o pega e onde ele aterrissa depois de publicado.

O fluxo que vale a pena portar é menor do que você pensa

Não comece com “substituir o Figma.” Comece com um trabalho chato e repetível.

Bons candidatos a primeiro plugin:

Fluxo atual	Versão em formato de plugin
Exportar uma página de marketing do Figma e reconstruí-la em código	plugin `figma-migration` que extrai layout, mapeia tokens e gera um artefato web
Transformar um kit de marca em slides de lançamento todo mês	plugin de deck com um `SKILL.md`, ativos de exemplo e um design system travado
Criar o mesmo mockup de onboarding mobile para todo cliente	plugin de tela mobile com campos de entrada para público, tom, lista de recursos e plataforma
Converter uma especificação de componente em UI pronta para Storybook	plugin de migração de código que lê o repositório, mapeia componentes e escreve um diff revisável

A unidade não é o departamento de design inteiro. A unidade é um fluxo que alguém já repete duas vezes por semana. Se você não consegue descrevê-lo em uma única frase — “transforme X em Y, com estas restrições” — provavelmente são dois plugins, não um, e você deveria dividi-lo antes de escrever uma linha de Markdown.

É por isso que a camada de skills do Open Design importa aqui. Um plugin não é uma extensão de runtime opaca. É uma pasta de arquivos: um contrato SKILL.md, design systems opcionais, exemplos opcionais e um sidecar open-design.json que diz ao Open Design como exibir e aplicar o fluxo. Não há formato binário entre você e as regras, o que significa que qualquer um pode ler o plugin, forká-lo ou consertá-lo depois.

Um frame de design sendo extraído de um canvas e largado dentro de uma caixa de módulo portátil, selecionado em uma moldura verde sobre um fundo editorial quase branco — Portar um fluxo significa tirar a parte repetível do canvas e colocá-la em um plugin portátil.

O ângulo do Open Design é portabilidade

A especificação de plugins enuncia o contrato com clareza: o SKILL.md continua sendo o contrato executável do agente, enquanto o open-design.json adiciona metadados de marketplace, campos de entrada, padrões, prévias e ligação de contexto.

Isso dá a um fluxo duas vidas. No Open Design, ele aparece como um plugin com prévia, entradas, proveniência e um caminho de “usar” em um clique. No Claude Code, Cursor, Codex, Gemini CLI, OpenClaw ou outro catálogo de skills, a mesma pasta ainda funciona como uma skill de agente comum, porque o comportamento central mora em Markdown. Você não está escrevendo para um runtime que vai ser descontinuado no ano que vem; está escrevendo um arquivo que um agente lê do mesmo jeito daqui a dois anos.

O passeio pela biblioteca já explica as primitivas de base: skills, sistemas, adaptadores e o daemon. Plugins adicionam distribuição e repetibilidade em torno dessas primitivas — eles são a unidade que um time entrega, revisa e reutiliza, em vez da skill bruta que um agente por acaso descobre em disco.

Para um fluxo de Figma-para-código, as superfícies normalmente parecem com isto:

Superfície	Arquivo concreto
Comportamento do agente	`SKILL.md`
Metadados do Open Design	`open-design.json`
Contrato de marca ou visual	`design-systems/{brand}/DESIGN.md`
Saída de exemplo	`example.html` ou `examples/{plugin-id}/example.html` dentro da pasta do plugin
Mídia de prévia	`preview/poster.png` ou `preview/index.html` dentro da pasta do plugin

O resultado não é um gerador de screenshots. É um fluxo de agente reutilizável com um contrato visível — toda regra que o agente segue está na pasta onde um humano pode ler e editar.

Um caminho concreto de portabilidade

Aqui está o caminho mínimo para um plugin que porta um fluxo de landing-page do Figma. A coisa toda são seis passos, e a maioria é Markdown.

1. Nomeie o trabalho repetível

Anote a única frase que descreve o trabalho: “Transforme um frame de marketing do Figma em uma página Astro responsiva, no sistema de marca da casa, pronta para revisão.” Se você não consegue caber em uma frase, estreite até conseguir. O nome vira o id do seu plugin (figma-workflow) e o título exibido no marketplace.

2. Escreva o contrato da skill

O SKILL.md é o contrato executável que o agente lê. O front matter nomeia a skill e seu gatilho; o corpo é o briefing — formato de entrada, caminho de saída, restrições e um checklist de revisão que o agente deve aplicar a si mesmo antes de repassar.

---
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. Adicione o sidecar do Open Design

O open-design.json é o que transforma uma skill nua em um plugin de marketplace: título, descrição, entradas declaradas, prévia e repositório de origem. Esses são os metadados que dirigem o painel de “usar” e a linha de proveniência.

{
  "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. Anexe o design system

Se o fluxo depende de regras de marca, adicione um arquivo DESIGN.md dentro de design-systems/ em vez de enterrar cor e tipografia na prosa. O agente ingere o sistema como um contrato — paleta OKLch, escala tipográfica, postura de layout — para que dez telas geradas ainda pareçam um único produto. Misturar sistemas no meio do projeto também funciona, porque são apenas texto.

5. Inclua um exemplo real

Salve um artefato gerado dentro de examples/ para que os revisores possam julgar a saída, não só a promessa. Um example.html comprovadamente bom vale mais que um parágrafo de descrição; ele dá ao agente algo para fazer correspondência de padrões e dá a um mantenedor algo para aprovar.

Juntando tudo, o plugin é uma única pasta legível:

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. Valide e empacote

Rode os comandos do plugin antes de abrir um PR. O caminho atual do CLI usa um id de plugin em minúsculas. Evite nomes de registro separados por barra na hora do scaffold; od plugin scaffold cria <out>/<id>/..., então os comandos seguintes apontam para aquela pasta gerada:

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

Quando o plugin estiver pronto para a revisão do registro, autentique-se pelo GitHub com od plugin login e od plugin whoami --json, depois siga a documentação de publicação para o caminho de revisão atual. O Open Design não armazena suas credenciais do GitHub.

Como isso fica em um time de design real

Imagine um pequeno time de produto com um frame do Figma para uma página de lançamento, um sistema de marca da casa e um ritmo mensal de releases.

Antes do plugin, o fluxo é uma cadeia de repasses: o designer exporta frames, o engenheiro reconstrói o layout, o PM reescreve o texto, alguém checa o desvio de tokens, outra pessoa registra bugs. O trabalho é familiar, mas a memória mora nas pessoas — e vaza toda vez que alguém está fora, troca de time ou esquece a única restrição que importava.

Depois do plugin, o fluxo vira um artefato executável:

Passo	Quem dirige
Escolher o plugin	Designer ou PM
Anexar URL do Figma / screenshot / ativos locais	Designer
Escolher o sistema de marca	Designer ou design engineer
Gerar o artefato web	Claude Code, Cursor, Codex, Gemini CLI ou outro agente detectado
Revisar IDs de seção, texto, densidade e comportamento responsivo	Humano na prévia do Open Design
Exportar ou repassar arquivos	A mesma pasta de projeto local

O time ainda precisa de bom gosto — o passo de revisão é onde ele mora, e nenhum plugin o substitui. O que o plugin remove é o reexplicar: as restrições, o mapa de tokens e o caminho de saída deixam de ser conhecimento tribal e viram um arquivo no repositório.

O que fazer a seguir

Se o seu time tem uma exportação do Figma, sincronização de tokens, kit de marca ou template de deck que fica voltando, porte primeiro a menor fatia repetível. Comece com um SKILL.md, adicione open-design.json, anexe o DESIGN.md da marca, coloque um exemplo real, valide-o e abra o PR antes de o fluxo virar uma ferramenta privada que ninguém mais consegue reutilizar. O exemplo de screenshot-para-protótipo mostra a versão em formato de plugin de ponta a ponta: uma skill portátil mais um sidecar do Open Design.

Experimente este fluxo.

Leitura relacionada

31 skills, 72 sistemas: como funciona a biblioteca do Open Design — as primitivas que um plugin embrulha
Por que construímos o Open Design como uma camada de skills, não um produto — por que o fluxo tem formato de arquivo em vez de formato de conta
A alternativa open-source ao Figma — onde portar seu fluxo aterrissa em relação ao incumbente
Fluxo de design BYOK: rode Claude, Codex ou Qwen com sua própria chave — como o mesmo plugin pode rodar no caminho de modelo em que seu time já confia