flcker/figma-ui-web

Figma Web UI Entwicklungsrichtlinien (Framelink MCP Edition)

Löst das Problem der mangelhaften Design-Umsetzung bei der Entwicklung von Web-Frontend UIs mit Figma-Designs. Die Ursache: Die Canvas-Daten von Figma (absolute Koordinaten, Inline-Farbwerte, Pixel-Layer-Stapel) werden fälschlicherweise als „Implementierungsdaten“ betrachtet und direkt übernommen, was zu fehlerhaftem responsive Design, ungenauen Farben, Schriftarten und fehlenden Assets führt.

Diese Skill richtet sich an die beiden Werkzeuge von Framelink figma-developer-mcp:

Werkzeug	Kanal	Funktion
get_figma_data	Präzisionskanal	Lädt Canvas-Daten nach fileKey + nodeId: Layout, Inhalt, visuelle Informationen, Komponenteninfo
download_figma_images	Visueller Kanal	Exportiert SVG/PNG/GIF von Knoten-IDs in ein lokales Verzeichnis

Hinweis: Dies ist die Framelink-Version, nicht der offizielle Figma MCP Server (offizielle Werkzeuge: get_design_context/get_variable_defs/download_assets). Die Methodik dieser Skill ist für beide Varianten gültig, die Werkzeugnamen sind jedoch an Framelink angepasst.

Falls das Ziel ein Desktop-Frontend (Qt Widget / QML / WinUI / Flutter) ist, verwenden Sie figma-ui-desktop anstelle dieser Skill.

Kernprinzipien

1. Zweikanal-parallel, kein Single-Kanal-Code. Der Präzisionskanal liefert exakte Werte, der visuelle Kanal zeigt das Gesamtlayout und den Text. Die alleinige Verwendung eines Kanals führt zwangsläufig zu Verzerrungen – insbesondere wenn nur der visuelle Kanal verwendet wird (gleichbedeutend mit dem Ablesen von Screenshots) oder nur der Datenkanal (gleichbedeutend mit blindem Schreiben).
2. Exakte Werte verwenden, keine visuellen Schätzungen. Farben, Schriftgrößen, Zeilenhöhen, Schriftgewichte, Abstände, Eckenradien, Rahmen, Schatten – immer die exakten Werte aus dem Design übernehmen.
3. Design anfordern, nicht selbstständig UI schreiben.
4. Nach der Implementierung muss ein Validierungszyklus erfolgen: Screenshot-Vergleich mit dem Design → Defekte automatisch erkennen und beheben → manuelle Prüfung → Iteration. 100% in einem Schritt gibt es nicht; 70-80% werden durch den Prozess erreicht, der Rest durch die Validierungsschleife.

Arbeitsablauf

Phase 1: Grobdurchsicht (Anforderungen und Struktur verstehen)

Bei großen Designs zuerst eine Grobdurchsicht durchführen, um eine Überlastung des Kontexts durch einmaliges Laden des gesamten Designs zu vermeiden:

1. Mit get_figma_data die oberste Struktur laden (depth steuert die Durchlaufebene, beginnend mit einer flachen Ebene), um einen Überblick über Seiten/Blöcke/Komponenten zu erhalten.
2. Mit download_figma_images das gesamte Seitenbild exportieren, um Layout und Text zu verstehen.

Phase 2: Feindurchsicht (exakte Daten vor der Implementierung abrufen)

Für die konkret zu implementierende Komponente/den Block gleichzeitig aufrufen:

• get_figma_data (mit nodeId, Knotenweise Koordinaten, Farbwerte, Schriftgrößen, Abstände, Eckenradien, Rahmen abrufen)
• download_figma_images (das Blockbild exportieren, um die relative Position der Komponenten zu bestätigen)

Nach Erhalt der Daten zuerst eine Strukturanalyse durchführen, bevor Code geschrieben wird:

• Welche Knoten sind Wiederholungsmuster (Karten, Listenelemente, Schaltflächen) → in Komponenten extrahieren
• Welche absoluten Positionierungen sind eigentlich Layouts (horizontale Anordnung, Zentrierung, verteilter Ausdruck) → in flex/grid umwandeln
• Welche haben semantische Rollen (Navigation/Formular/Liste) → auf die Komponentenbibliothek des Ziel-Frameworks abbilden
• Bild-/Icon-Knoten → mit download_figma_images die Originaldateien herunterladen und in assets ablegen, nicht selbst zeichnen

Phase 3: Implementierung

• Farben, Schriftgrößen, Abstände exakt aus dem Design übernehmen, kein „sieht etwa gleich aus“
• Vorrangig die vorhandene Projekt-Komponentenbibliothek verwenden, zuerst die Komponenten-Props (theme/size/variant) prüfen, um doppelte Stildefinitionen zu vermeiden
• Icons aus der Projekt-Icon-Bibliothek verwenden, keine Icons von Drittanbietern
• Dateinamen für Stylesheets, CSS-Klassennamenskonventionen und Nesting-Tiefe gemäß den Projektrichtlinien einhalten

Phase 4: Validierungszyklus

Mit Playwright MCP die lokale Seite als Screenshot öffnen, den Screenshot mit dem Design-Screenshot nebeneinander vergleichen, offensichtliche Defekte automatisch beheben; manuelle Prüfung: Menschen erkennen feinere Probleme (Abstände, Schriftgewichte, Farbnuancen) und melden sie aktiv der KI zur präzisen Behebung, in die nächste Iteration gehen.

Anti-Faulheits-Regeln

KI neigt dazu, nur einen Kanal für die Code-Erstellung zu verwenden. Daher müssen folgende Anforderungen klar formuliert werden:

• „Rufe gleichzeitig get_figma_data und download_figma_images auf, um das Design zu lesen“
• „Es ist nicht erlaubt, Code zu schreiben, nachdem das Design nur über Bilder/Screenshots gelesen wurde“
• „Lies die exakten Werte von get_figma_data zeilenweise und vergleiche Farben, Schriftgrößen, Abstände; mache keine visuellen Schätzungen“

Komponentenrichtlinien (projektspezifisch ersetzen)

Das Folgende ist eine Vorlage, die beim konkreten Projekt durch die dort geltenden Richtlinien ersetzt werden sollte:

• Vorrangig die Projekt-Komponentenbibliothek verwenden (z.B. @notta/components), bei Unklarheit aktiv den Benutzer fragen
• Zuerst die Komponenten-Props prüfen, um doppelte Stildefinitionen zu vermeiden
• Icons aus der Projekt-Icon-Bibliothek verwenden
• Dateinamen für Stylesheets, CSS-Klassennamenskonventionen und Nesting-Tiefe gemäß den Projektrichtlinien einhalten

Check-Liste für die Design-Umsetzungsgenauigkeit

Nach der Generierung Punkt für Punkt prüfen (zuverlässiger als „sieht das Gesamtbild ähnlich aus?“):

• Farben (wurde der exakte Hex-Wert verwendet, nicht ein ähnlicher)
• Schriftgröße / Zeilenhöhe / Schriftgewicht
• Abstände / Ränder / Innenabstände
• Eckenradien / Rahmen / Schatten
• Layout (entspricht flex/grid dem Design-Layout?)
• z-index / Ebenen
• Werden Icons/Bilder als Originaldateien und nicht selbst gezeichnet?

Quellenangabe

Die Methodik ist an den UI-Entwicklungsprozess mit offiziellem Figma MCP + Playwright angelehnt (siehe „Effiziente UI-Entwicklung und Fehlerbehebung mit Figma mcp und Playwright mcp“). Die Kernidee ist „Zweikanal-Ansatz + Validierungszyklus + klare Anti-Faulheits-Anforderungen“. Die Werkzeugnamen wurden an Framelink figma-developer-mcp angepasst.