Download
← Zurück zum Journal

So portierst du einen Figma-Workflow in ein Open Design Plugin

Der 0.8.0-preview-Thread fordert Mitwirkende auf, alte Design-Workflows ein Plugin nach dem anderen zu portieren. Hier ist der konkrete Weg für einen Figma-Export, eine Token-Synchronisierung oder ein Brand-Kit.

18. Mai 2026 8 Min. Lesezeit Artikel
So portierst du einen Figma-Workflow in ein Open Design Plugin

Ein Figma-Workflow beginnt meist als Muskelgedächtnis: diese Frames exportieren, jene Tokens synchronisieren, jenes Deck-Template neu aufbauen, die Spezifikation an die Entwicklung übergeben. Es ist die Art von Arbeit, die im Kopf einer Person lebt und bei jedem neuen Projekt aufs Neue erklärt wird.

Der 0.8.0-preview-Thread stellt eine schärfere Anforderung: dieses Muskelgedächtnis in ein Plugin zu portieren. Kein Panel, das an eine Canvas geschraubt wird. Kein privates Skript, das nur ein Team ausführen kann. Ein wiederverwendbarer Open Design Workflow, den ein Agent aufgreifen, ausführen, prüfen und über dieselbe local-first-Schleife wie jede andere Design-Aufgabe weitergeben kann.

Das ist die praktische Version des 0.8.0-preview-Aufrufs für Plugins. Wenn dein Team heute einen wiederholbaren Design-Workflow hat, zeigt dieser Beitrag, wie es aussieht, ihn in einen Plugin-förmigen Beitrag zu verwandeln — welche Dateien er braucht, wie der Agent ihn aufgreift und wo er landet, sobald er veröffentlicht ist.

Der portierenswerte Workflow ist kleiner, als du denkst

Fang nicht mit „Figma ersetzen“ an. Fang mit einer einzigen lästigen, wiederholbaren Aufgabe an.

Gute Kandidaten für ein erstes Plugin:

Aktueller WorkflowPlugin-förmige Version
Eine Figma-Marketingseite exportieren und im Code neu aufbauenfigma-migration-Plugin, das das Layout extrahiert, Tokens zuordnet und ein Web-Artefakt erzeugt
Jeden Monat ein Brand-Kit in Launch-Slides verwandelnDeck-Plugin mit einer SKILL.md, Beispiel-Assets und einem fest verankerten Design-System
Für jeden Kunden dasselbe Mobile-Onboarding-Mockup erstellenMobile-Screen-Plugin mit Eingabefeldern für Zielgruppe, Tonalität, Feature-Liste und Plattform
Eine Komponenten-Spezifikation in Storybook-fertiges UI umwandelnCode-Migrations-Plugin, das das Repo liest, Komponenten zuordnet und ein prüfbares Diff schreibt

Die Einheit ist nicht die ganze Design-Abteilung. Die Einheit ist ein Workflow, den jemand bereits zweimal pro Woche wiederholt. Wenn du ihn nicht in einem einzigen Satz beschreiben kannst — „X in Y verwandeln, mit diesen Einschränkungen“ — handelt es sich wahrscheinlich um zwei Plugins, nicht um eines, und du solltest ihn aufteilen, bevor du eine Zeile Markdown schreibst.

Genau deshalb ist Open Designs Skill-Layer hier so wichtig. Ein Plugin ist keine undurchsichtige Laufzeiterweiterung. Es ist ein Ordner voller Dateien: ein SKILL.md-Vertrag, optionale Design-Systeme, optionale Beispiele und ein open-design.json-Sidecar, das Open Design mitteilt, wie der Workflow angezeigt und angewendet wird. Zwischen dir und den Regeln steht kein Binärformat, was bedeutet, dass jeder das Plugin lesen, forken oder später reparieren kann.

Ein Design-Frame, der aus einer Canvas extrahiert und in eine portable Modul-Box abgelegt wird, ausgewählt in einem grünen Rahmen auf einem nahezu weißen redaktionellen Untergrund
Einen Workflow zu portieren bedeutet, den wiederholbaren Teil aus der Canvas herauszuheben und in ein portables Plugin zu überführen.

Der Open-Design-Aspekt ist Portabilität

Die Plugin-Spezifikation formuliert den Vertrag klar: SKILL.md bleibt der ausführbare Agent-Vertrag, während open-design.json Marketplace-Metadaten, Eingabefelder, Standardwerte, Vorschauen und Kontext-Verdrahtung hinzufügt.

Das gibt einem Workflow zwei Leben. In Open Design erscheint er als Plugin mit Vorschau, Eingaben, Herkunft und einem Ein-Klick-„Verwenden“-Pfad. In Claude Code, Cursor, Codex, Gemini CLI, OpenClaw oder einem anderen Skill-Katalog funktioniert derselbe Ordner weiterhin als reiner Agent-Skill, weil das Kernverhalten in Markdown lebt. Du schreibst nicht für eine Laufzeit, die nächstes Jahr abgekündigt wird; du schreibst eine Datei, die ein Agent in zwei Jahren genauso liest.

Der Bibliotheks-Rundgang erklärt bereits die Basis-Primitiven: Skills, Systeme, Adapter und den daemon. Plugins fügen Verteilung und Wiederholbarkeit rund um diese Primitiven hinzu — sie sind die Einheit, die ein Team ausliefert, prüft und wiederverwendet, statt des rohen Skills, den ein Agent zufällig auf der Festplatte entdeckt.

Für einen Figma-zu-Code-Workflow sehen die Oberflächen meist so aus:

OberflächeKonkrete Datei
Agent-VerhaltenSKILL.md
Open Design Metadatenopen-design.json
Brand- oder Visual-Vertragdesign-systems/{brand}/DESIGN.md
Beispiel-Ausgabeexample.html oder examples/{plugin-id}/example.html innerhalb des Plugin-Ordners
Vorschau-Medienpreview/poster.png oder preview/index.html innerhalb des Plugin-Ordners

Das Ergebnis ist kein Screenshot-Generator. Es ist ein wiederverwendbarer Agent-Workflow mit einem sichtbaren Vertrag — jede Regel, der der Agent folgt, liegt in dem Ordner, in dem ein Mensch sie lesen und bearbeiten kann.

Ein konkreter Portierungs-Pfad

Hier ist der Minimalpfad für ein Plugin, das einen Figma-Landingpage-Workflow portiert. Das Ganze umfasst sechs Schritte, und die meisten davon sind Markdown.

1. Benenne die wiederholbare Aufgabe

Schreib den einen Satz auf, der die Aufgabe beschreibt: „Verwandle einen Figma-Marketing-Frame in eine responsive Astro-Seite, im Haus-Brand-System, bereit zur Prüfung.“ Wenn du es nicht in einen Satz bekommst, grenze es ein, bis es passt. Der Name wird zu deiner Plugin-ID (figma-workflow) und zum Titel, der im Marketplace angezeigt wird.

2. Schreibe den Skill-Vertrag

SKILL.md ist der ausführbare Vertrag, den der Agent liest. Das Front Matter benennt den Skill und seinen Trigger; der Body ist das Briefing — Eingabeform, Ausgabepfad, Einschränkungen und eine Review-Checkliste, die der Agent vor der Übergabe selbst anwenden sollte.

---
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. Füge das Open Design Sidecar hinzu

open-design.json ist das, was aus einem nackten Skill ein Marketplace-Plugin macht: Titel, Beschreibung, deklarierte Eingaben, Vorschau und Quell-Repo. Das sind die Metadaten, die das „Verwenden“-Panel und die Herkunftszeile antreiben.

{
  "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. Verknüpfe das Design-System

Wenn der Workflow von Brand-Regeln abhängt, füge eine DESIGN.md-Datei unter design-systems/ hinzu, anstatt Farbe und Typografie in Fließtext zu vergraben. Der Agent nimmt das System als Vertrag auf — OKLch-Palette, Type-Ramp, Layout-Haltung — sodass zehn generierte Screens sich immer noch wie ein einziges Produkt anfühlen. Systeme mitten im Projekt zu mischen funktioniert ebenfalls, weil sie nur Text sind.

5. Lege ein echtes Beispiel bei

Speichere ein generiertes Artefakt unter examples/, damit Prüfende die Ausgabe beurteilen können und nicht nur das Versprechen. Eine bekanntermaßen gute example.html ist mehr wert als ein Absatz Beschreibung; sie gibt dem Agenten etwas zum Pattern-Matching und einem Maintainer etwas zum Freigeben.

Zusammengesetzt ist das Plugin ein einziger, lesbarer Ordner:

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. Validieren und packen

Führe die Plugin-Befehle aus, bevor du einen PR öffnest. Der aktuelle CLI-Pfad verwendet eine kleingeschriebene Plugin-ID. Vermeide beim Scaffolding mit Schrägstrichen getrennte Registry-Namen; od plugin scaffold erstellt <out>/<id>/..., sodass die Folgebefehle auf diesen generierten Ordner zeigen:

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

Wenn das Plugin bereit für die Registry-Prüfung ist, authentifiziere dich über GitHub mit od plugin login und od plugin whoami --json und folge dann der Veröffentlichungsdokumentation für den aktuellen Prüfpfad. Open Design speichert deine GitHub-Anmeldedaten nicht.

Wie das in einem echten Design-Team aussieht

Stell dir ein kleines Produktteam mit einem Figma-Frame für eine Launch-Seite, einem Haus-Brand-System und einem monatlichen Release-Rhythmus vor.

Vor dem Plugin ist der Workflow eine Übergabekette: Designer exportiert Frames, Entwickler baut das Layout neu auf, PM schreibt den Text um, jemand prüft Token-Drift, jemand anderes meldet Bugs. Die Arbeit ist vertraut, aber das Gedächtnis lebt in den Menschen — und es geht jedes Mal verloren, wenn jemand fehlt, das Team wechselt oder die eine Einschränkung vergisst, auf die es ankam.

Nach dem Plugin wird der Workflow zu einem ausführbaren Artefakt:

SchrittWer ihn steuert
Das Plugin auswählenDesigner oder PM
Figma-URL / Screenshot / lokale Assets anhängenDesigner
Das Brand-System wählenDesigner oder Design-Engineer
Das Web-Artefakt generierenClaude Code, Cursor, Codex, Gemini CLI oder ein anderer erkannter Agent
Section-IDs, Text, Dichte und responsives Verhalten prüfenMensch in der Open Design Vorschau
Dateien exportieren oder übergebenDerselbe lokale Projektordner

Das Team braucht weiterhin Geschmack — der Review-Schritt ist der Ort, an dem er lebt, und kein Plugin ersetzt ihn. Was das Plugin beseitigt, ist das erneute Erklären: die Einschränkungen, die Token-Zuordnung und der Ausgabepfad hören auf, Stammeswissen zu sein, und werden zu einer Datei im Repo.

Was als Nächstes zu tun ist

Wenn dein Team einen Figma-Export, eine Token-Synchronisierung, ein Brand-Kit oder ein Deck-Template hat, das immer wiederkehrt, portiere zuerst die kleinste wiederholbare Scheibe. Beginne mit einer SKILL.md, füge open-design.json hinzu, verknüpfe die Brand-DESIGN.md, lege ein echtes Beispiel bei, validiere es und öffne den PR, bevor der Workflow zu einem privaten Tool heranwächst, das niemand sonst wiederverwenden kann. Das Beispiel „Screenshot zu Prototyp“ zeigt die Plugin-förmige Version von Anfang bis Ende: ein portabler Skill plus ein Open Design Sidecar.

Probiere diesen Workflow aus.

Weiterführende Lektüre

← Zurück zum Journal GitHub · Quelle ↗