Come portare un flusso di lavoro Figma in un plugin Open Design

Un flusso di lavoro Figma di solito inizia come memoria muscolare: esporta questi frame, sincronizza quei token, ricostruisci quel template di deck, consegna le specifiche all'ingegneria. È il tipo di lavoro che vive nella testa di qualcuno e viene rispiegato ogni volta che inizia un nuovo progetto.

Il thread 0.8.0-preview fa una richiesta più netta: porta quella memoria muscolare in un plugin. Non un pannello bullonato su un canvas. Non uno script privato che solo un team può eseguire. Un flusso di lavoro Open Design riutilizzabile che un agente può raccogliere, eseguire, rivedere e passare avanti attraverso lo stesso ciclo local-first di qualsiasi altra attività di design.

Questa è la versione pratica della chiamata ai plugin di 0.8.0-preview. Se il tuo team ha oggi un flusso di lavoro di design ripetibile, questo articolo mostra cosa significa trasformarlo in un contributo a forma di plugin: di quali file ha bisogno, come l'agente lo raccoglie e dove finisce una volta pubblicato.

Il flusso di lavoro che vale la pena portare è più piccolo di quanto pensi

Non iniziare con "sostituisci Figma". Inizia con un singolo lavoro fastidioso e ripetibile.

Buoni candidati per un primo plugin:

Flusso di lavoro attuale	Versione a forma di plugin
Esporta una pagina marketing Figma e ricostruiscila in codice	Plugin `figma-migration` che estrae il layout, mappa i token e genera un artefatto web
Trasforma un brand kit in slide di lancio ogni mese	Plugin di deck con un `SKILL.md`, asset di esempio e un design system bloccato
Crea lo stesso mockup di onboarding mobile per ogni cliente	Plugin per schermate mobile con campi di input per pubblico, tono, elenco di funzionalità e piattaforma
Converti una specifica di componenti in UI pronta per Storybook	Plugin di migrazione del codice che legge il repository, mappa i componenti e scrive un diff revisionabile

L'unità non è l'intero reparto di design. L'unità è un flusso di lavoro che qualcuno già ripete due volte a settimana. Se non riesci a descriverlo in una singola frase — "trasforma X in Y, con questi vincoli" — probabilmente sono due plugin, non uno, e dovresti dividerlo prima di scrivere una riga di Markdown.

Ecco perché il livello di skill di Open Design conta qui. Un plugin non è un'estensione di runtime opaca. È una cartella di file: un contratto SKILL.md, design system opzionali, esempi opzionali e un file laterale open-design.json che dice a Open Design come visualizzare e applicare il flusso di lavoro. Non c'è alcun formato binario tra te e le regole, il che significa che chiunque può leggere il plugin, forkarlo o correggerlo in seguito.

Un frame di design che viene estratto da un canvas e inserito in una scatola modulare portabile, selezionato in una cornice verde su uno sfondo editoriale quasi bianco — Portare un flusso di lavoro significa sollevare la parte ripetibile dal canvas e metterla in un plugin portabile.

L'angolazione di Open Design è la portabilità

La specifica del plugin enuncia il contratto in modo chiaro: SKILL.md rimane il contratto eseguibile dell'agente, mentre open-design.json aggiunge metadati per il marketplace, campi di input, valori predefiniti, anteprime e collegamento del contesto.

Questo dà a un flusso di lavoro due vite. In Open Design, appare come un plugin con anteprima, input, provenienza e un percorso "usa" con un clic. In Claude Code, Cursor, Codex, Gemini CLI, OpenClaw o un altro catalogo di skill, la stessa cartella funziona ancora come una semplice skill di agente perché il comportamento principale vive in Markdown. Non stai scrivendo per un runtime che verrà deprecato l'anno prossimo; stai scrivendo un file che un agente leggerà allo stesso modo tra due anni.

La panoramica della libreria spiega già le primitive di base: skill, sistemi, adattatori e il daemon. I plugin aggiungono distribuzione e ripetibilità attorno a quelle primitive: sono l'unità che un team rilascia, rivede e riutilizza, anziché la skill grezza che un agente capita di scoprire su disco.

Per un flusso di lavoro da Figma a codice, le superfici di solito si presentano così:

Superficie	File concreto
Comportamento dell'agente	`SKILL.md`
Metadati di Open Design	`open-design.json`
Contratto di brand o visivo	`design-systems/{brand}/DESIGN.md`
Output di esempio	`example.html` o `examples/{plugin-id}/example.html` dentro la cartella del plugin
Media di anteprima	`preview/poster.png` o `preview/index.html` dentro la cartella del plugin

Il risultato non è un generatore di screenshot. È un flusso di lavoro di agente riutilizzabile con un contratto visibile: ogni regola che l'agente segue è nella cartella dove un umano può leggerla e modificarla.

Un percorso di porting concreto

Ecco il percorso minimo per un plugin che porta un flusso di lavoro Figma per landing page. L'intera cosa è sei passi, e la maggior parte di essi è Markdown.

1. Nomina il lavoro ripetibile

Scrivi la singola frase che descrive il lavoro: "Trasforma un frame marketing Figma in una pagina Astro responsive, nel sistema di brand interno, pronta per la revisione." Se non riesci a farlo stare in una frase, restringilo finché non ci riesci. Il nome diventa l'id del tuo plugin (figma-workflow) e il titolo mostrato nel marketplace.

2. Scrivi il contratto della skill

SKILL.md è il contratto eseguibile che l'agente legge. Il front matter nomina la skill e il suo trigger; il corpo è il brief: forma dell'input, percorso dell'output, vincoli e una checklist di revisione che l'agente dovrebbe auto-applicare prima di passare il lavoro.

---
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. Aggiungi il file laterale di Open Design

open-design.json è ciò che trasforma una skill nuda in un plugin di marketplace: titolo, descrizione, input dichiarati, anteprima e repository sorgente. Questi sono i metadati che guidano il pannello "usa" e la riga di provenienza.

{
  "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. Collega il design system

Se il flusso di lavoro dipende da regole di brand, aggiungi un file DESIGN.md sotto design-systems/ invece di seppellire colore e tipografia nella prosa. L'agente ingerisce il sistema come un contratto — palette OKLch, scala tipografica, postura del layout — così dieci schermate generate sembrano ancora un unico prodotto. Anche mescolare sistemi a metà progetto funziona, perché sono solo testo.

5. Includi un esempio reale

Salva un artefatto generato sotto examples/ così i revisori possono giudicare l'output, non solo la promessa. Un singolo example.html noto come valido vale più di un paragrafo di descrizione; dà all'agente qualcosa su cui fare pattern-matching e dà a un maintainer qualcosa da approvare.

Messo insieme, il plugin è una singola cartella leggibile:

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 e impacchetta

Esegui i comandi del plugin prima di aprire una PR. L'attuale percorso della CLI usa un id di plugin in minuscolo. Evita nomi di registro separati da slash al momento dello scaffold; od plugin scaffold crea <out>/<id>/..., quindi i comandi successivi puntano a quella cartella generata:

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 il plugin è pronto per la revisione del registro, autenticati tramite GitHub con od plugin login e od plugin whoami --json, poi segui la documentazione di pubblicazione per l'attuale percorso di revisione. Open Design non memorizza le tue credenziali GitHub.

Come appare questo in un vero team di design

Immagina un piccolo team di prodotto con un frame Figma per una pagina di lancio, un sistema di brand interno e un ritmo di rilascio mensile.

Prima del plugin, il flusso di lavoro è una catena di passaggi di consegna: il designer esporta i frame, l'ingegnere ricostruisce il layout, il PM riscrive i testi, qualcuno controlla la deriva dei token, qualcun altro segnala i bug. Il lavoro è familiare, ma la memoria vive nelle persone, e si disperde ogni volta che qualcuno è assente, cambia team o dimentica l'unico vincolo che contava.

Dopo il plugin, il flusso di lavoro diventa un artefatto eseguibile:

Passo	Chi lo dirige
Scegli il plugin	Designer o PM
Allega URL Figma / screenshot / asset locali	Designer
Scegli il design system	Designer o design engineer
Genera l'artefatto web	Claude Code, Cursor, Codex, Gemini CLI o un altro agente rilevato
Rivedi ID di sezione, testi, densità e comportamento responsive	Umano nell'anteprima di Open Design
Esporta o consegna i file	La stessa cartella di progetto locale

Il team ha ancora bisogno del gusto: il passo di revisione è dove vive, e nessun plugin lo sostituisce. Ciò che il plugin rimuove è il rispiegare: i vincoli, la mappa dei token e il percorso dell'output smettono di essere conoscenza tribale e diventano un file nel repository.

Cosa fare dopo

Se il tuo team ha un export Figma, una sincronizzazione di token, un brand kit o un template di deck che continua a tornare, porta prima la fetta ripetibile più piccola. Inizia con un SKILL.md, aggiungi open-design.json, collega il DESIGN.md del brand, inserisci un esempio reale, validalo e apri la PR prima che il flusso di lavoro cresca fino a diventare uno strumento privato che nessun altro può riutilizzare. L'esempio da screenshot a prototipo mostra la versione a forma di plugin dall'inizio alla fine: una skill portabile più un file laterale di Open Design.

Prova questo flusso di lavoro.

Letture correlate

31 skill, 72 sistemi: come funziona la libreria di Open Design: le primitive che un plugin avvolge
Perché abbiamo costruito Open Design come un livello di skill, non come un prodotto: perché il flusso di lavoro ha la forma di un file invece che di un account
L'alternativa open-source a Figma: dove finisce il porting del tuo flusso di lavoro rispetto al leader di mercato
Flusso di lavoro di design BYOK: usa Claude, Codex o Qwen con la tua chiave: come lo stesso plugin può girare sul percorso del modello di cui il tuo team già si fida