Comment porter un workflow Figma vers un plugin Open Design

Un workflow Figma commence généralement comme une mémoire musculaire : exporter ces frames, synchroniser ces tokens, reconstruire ce modèle de deck, remettre la spécification à l'ingénierie. C'est le genre de travail qui vit dans la tête de quelqu'un et qui doit être réexpliqué chaque fois qu'un nouveau projet démarre.

Le fil 0.8.0-preview formule une demande plus précise : portez cette mémoire musculaire dans un plugin. Pas un panneau boulonné sur un canvas. Pas un script privé qu'une seule équipe peut exécuter. Un workflow Open Design réutilisable qu'un agent peut prendre, exécuter, relire et transmettre via la même boucle local-first que n'importe quelle autre tâche de design.

Voici la version pratique de l'appel à plugins 0.8.0-preview. Si votre équipe dispose aujourd'hui d'un workflow de design reproductible, cet article montre à quoi ressemble sa transformation en contribution sous forme de plugin — les fichiers dont il a besoin, comment l'agent le prend en charge, et où il atterrit une fois publié.

Le workflow qui vaut la peine d'être porté est plus petit que vous ne le pensez

Ne commencez pas par « remplacer Figma ». Commencez par une tâche pénible et reproductible.

Bons candidats pour un premier plugin :

Workflow actuel	Version sous forme de plugin
Exporter une page marketing Figma et la reconstruire en code	plugin `figma-migration` qui extrait la mise en page, mappe les tokens et génère un artefact web
Transformer chaque mois un brand kit en slides de lancement	Plugin de deck avec un `SKILL.md`, des actifs d'exemple et un design system verrouillé
Créer la même maquette d'onboarding mobile pour chaque client	Plugin d'écran mobile avec des champs de saisie pour le public, le ton, la liste des fonctionnalités et la plateforme
Convertir une spécification de composant en UI prête pour Storybook	Plugin de migration de code qui lit le dépôt, mappe les composants et écrit un diff relisible

L'unité n'est pas l'ensemble du département design. L'unité est un workflow que quelqu'un répète déjà deux fois par semaine. Si vous ne pouvez pas le décrire en une seule phrase — « transformer X en Y, avec ces contraintes » — il s'agit probablement de deux plugins, pas d'un, et vous devriez le scinder avant d'écrire une ligne de Markdown.

C'est pourquoi la couche de skills d'Open Design compte ici. Un plugin n'est pas une extension d'exécution opaque. C'est un dossier de fichiers : un contrat SKILL.md, des design systems optionnels, des exemples optionnels, et un fichier d'accompagnement open-design.json qui indique à Open Design comment afficher et appliquer le workflow. Il n'y a aucun format binaire entre vous et les règles, ce qui signifie que n'importe qui peut lire le plugin, le forker ou le corriger plus tard.

Un frame de design extrait d'un canvas et déposé dans une boîte de module portable, sélectionné dans un cadre vert sur un fond éditorial presque blanc — Porter un workflow, c'est extraire la partie reproductible du canvas pour la placer dans un plugin portable.

L'angle Open Design, c'est la portabilité

La spécification du plugin énonce le contrat clairement : SKILL.md reste le contrat exécutable de l'agent, tandis que open-design.json ajoute les métadonnées de marketplace, les champs de saisie, les valeurs par défaut, les aperçus et le câblage du contexte.

Cela donne deux vies à un workflow. Dans Open Design, il apparaît comme un plugin avec un aperçu, des entrées, une provenance et un chemin d'« utilisation » en un clic. Dans Claude Code, Cursor, Codex, Gemini CLI, OpenClaw ou un autre catalogue de skills, le même dossier fonctionne toujours comme un simple skill d'agent parce que le comportement central vit dans le Markdown. Vous n'écrivez pas pour un environnement d'exécution qui sera déprécié l'an prochain ; vous écrivez un fichier qu'un agent lira de la même manière dans deux ans.

Le parcours de la bibliothèque explique déjà les primitives de base : skills, systems, adaptateurs et le daemon. Les plugins ajoutent distribution et reproductibilité autour de ces primitives — ils sont l'unité qu'une équipe livre, relit et réutilise, plutôt que le skill brut qu'un agent découvre par hasard sur le disque.

Pour un workflow Figma-vers-code, les surfaces ressemblent généralement à ceci :

Surface	Fichier concret
Comportement de l'agent	`SKILL.md`
Métadonnées Open Design	`open-design.json`
Contrat de marque ou visuel	`design-systems/{brand}/DESIGN.md`
Sortie d'exemple	`example.html` ou `examples/{plugin-id}/example.html` dans le dossier du plugin
Média d'aperçu	`preview/poster.png` ou `preview/index.html` dans le dossier du plugin

Le résultat n'est pas un générateur de captures d'écran. C'est un workflow d'agent réutilisable avec un contrat visible — chaque règle que l'agent suit se trouve dans le dossier où un humain peut la lire et l'éditer.

Un chemin de portage concret

Voici le chemin minimal pour un plugin qui porte un workflow de landing-page Figma. L'ensemble tient en six étapes, et la plupart sont du Markdown.

1. Nommer la tâche reproductible

Écrivez la phrase unique qui décrit la tâche : « Transformer un frame marketing Figma en une page Astro responsive, dans le design system maison, prête pour la revue. » Si vous ne pouvez pas la faire tenir en une phrase, restreignez-la jusqu'à y parvenir. Le nom devient l'id de votre plugin (figma-workflow) et le titre affiché dans la marketplace.

2. Écrire le contrat du skill

SKILL.md est le contrat exécutable que l'agent lit. Le front matter nomme le skill et son déclencheur ; le corps est le brief — forme de l'entrée, chemin de sortie, contraintes, et une liste de contrôle de revue que l'agent doit s'appliquer à lui-même avant de transmettre.

---
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. Ajouter le fichier d'accompagnement Open Design

open-design.json est ce qui transforme un skill nu en plugin de marketplace : titre, description, entrées déclarées, aperçu et dépôt source. Ce sont les métadonnées qui pilotent le panneau « use » et la ligne de provenance.

{
  "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. Attacher le design system

Si le workflow dépend de règles de marque, ajoutez un fichier DESIGN.md sous design-systems/ plutôt que d'enfouir la couleur et la typographie dans de la prose. L'agent ingère le system comme un contrat — palette OKLch, échelle typographique, posture de mise en page — afin que dix écrans générés donnent toujours l'impression d'un seul produit. Mélanger des systems en cours de projet fonctionne aussi, parce que ce ne sont que du texte.

5. Inclure un exemple réel

Enregistrez un artefact généré sous examples/ afin que les relecteurs puissent juger la sortie, et pas seulement la promesse. Un example.html reconnu comme bon vaut plus qu'un paragraphe de description ; il donne à l'agent quelque chose sur quoi s'aligner et au mainteneur quelque chose à approuver.

Mis bout à bout, le plugin est un dossier unique et lisible :

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. Valider et empaqueter

Lancez les commandes du plugin avant d'ouvrir une PR. Le chemin actuel du CLI utilise un id de plugin en minuscules. Évitez les noms de registre séparés par des slashs au moment du scaffold ; od plugin scaffold crée <out>/<id>/..., donc les commandes suivantes pointent vers ce dossier généré :

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

Lorsque le plugin est prêt pour la revue du registre, authentifiez-vous via GitHub avec od plugin login et od plugin whoami --json, puis suivez la documentation de publication pour le chemin de revue actuel. Open Design ne stocke pas vos identifiants GitHub.

À quoi cela ressemble dans une vraie équipe de design

Imaginez une petite équipe produit avec un frame Figma pour une page de lancement, un design system maison et un rythme de release mensuel.

Avant le plugin, le workflow est une chaîne de transmissions : le designer exporte les frames, l'ingénieur reconstruit la mise en page, le PM réécrit le texte, quelqu'un vérifie la dérive des tokens, quelqu'un d'autre enregistre les bugs. Le travail est familier, mais la mémoire vit dans les personnes — et elle fuit chaque fois que quelqu'un est absent, change d'équipe ou oublie la seule contrainte qui comptait.

Après le plugin, le workflow devient un artefact exécutable :

Étape	Qui la dirige
Choisir le plugin	Designer ou PM
Attacher l'URL Figma / capture d'écran / actifs locaux	Designer
Choisir le design system	Designer ou design engineer
Générer l'artefact web	Claude Code, Cursor, Codex, Gemini CLI, ou un autre agent détecté
Relire les IDs de section, le texte, la densité et le comportement responsive	Humain dans l'aperçu Open Design
Exporter ou transmettre les fichiers	Le même dossier de projet local

L'équipe a toujours besoin de goût — l'étape de revue est là où il vit, et aucun plugin ne le remplace. Ce que le plugin supprime, c'est la réexplication : les contraintes, la carte des tokens et le chemin de sortie cessent d'être un savoir tribal pour devenir un fichier dans le dépôt.

Quoi faire ensuite

Si votre équipe a un export Figma, une synchronisation de tokens, un brand kit ou un modèle de deck qui revient sans cesse, portez d'abord la plus petite tranche reproductible. Commencez par un SKILL.md, ajoutez open-design.json, attachez le DESIGN.md de la marque, déposez un exemple réel, validez-le, et ouvrez la PR avant que le workflow ne se transforme en un outil privé que personne d'autre ne peut réutiliser. L'exemple capture-d'écran-vers-prototype montre la version sous forme de plugin de bout en bout : un skill portable plus un fichier d'accompagnement Open Design.

Essayez ce workflow.

Lectures associées

31 skills, 72 systems : comment fonctionne la bibliothèque Open Design — les primitives qu'un plugin enveloppe
Pourquoi nous avons conçu Open Design comme une couche de skills, pas un produit — pourquoi le workflow a la forme d'un fichier plutôt que d'un compte
L'alternative open-source à Figma — où atterrit le portage de votre workflow par rapport à l'acteur en place
Workflow de design BYOK : faites tourner Claude, Codex ou Qwen sur votre propre clé — comment le même plugin peut tourner sur le chemin de modèle auquel votre équipe fait déjà confiance