flcker/figma-ui-desktop

Figma Desktop-UI-Entwicklungsrichtlinie (Framelink MCP-Version)

Löst das Problem der schlechten Umsetzungstreue bei der Entwicklung von Desktop-UI mit Figma-Designs. Die Ursache liegt darin, dass die Figma-„Canvas-Daten“ (absolute Koordinaten, Inline-Farbwerte, Pixel-Layer-Stapel) als „Implementierungsdaten“ betrachtet und direkt übernommen werden, was zu starren Layouts, ungenauen Farben und Schriftarten sowie fehlenden Ressourcen führt.

Warum für Desktop Framelink anstelle des offiziellen Figma MCP Servers? Das offizielle MCP-Kerntool get_design_context erzeugt standardmäßig nur Web-Code (React/Tailwind, umschaltbar auf Vue/HTML/iOS), unterstützt aber kein Qt Widget / QML / WinUI / Flutter und ist kostenpflichtig. Framelink zielt darauf ab, „nur framework-unabhängige Figma-Daten zu liefern, die Übersetzung dem Modell zu überlassen“ – dieser vermeintliche Nachteil ist bei Desktop-Szenarien mit mehreren Frameworks tatsächlich ein Vorteil: Das Modell kann die Canvas-Daten nach Erhalt in jedes beliebige Ziel-Framework übersetzen, anstatt auf Web beschränkt zu sein.

Dieses Skill richtet sich an die beiden Tools von Framelink figma-developer-mcp:

Tool	Kanal	Funktion
get_figma_data	Präziser Kanal	Ruft Canvas-Daten nach fileKey + nodeId ab: Layout, Inhalt, visuelle Informationen, Komponenteninformationen
download_figma_images	Visueller Kanal	Exportiert Knoten als SVG/PNG/GIF in ein lokales Verzeichnis

Wenn das Ziel ein Web-Frontend (React/Vue/HTML) ist, verwenden Sie figma-ui-web anstelle dieses Skills.

Kernprinzipien

1. Beide Kanäle parallel nutzen, nie nur einen zum Schreiben von Code verwenden. Der präzise Kanal liefert exakte Werte, der visuelle Kanal das Gesamtlayout und den Text. Die Verwendung nur eines Kanals führt zwangsläufig zu Verzerrungen.
2. Exakte Werte verwenden, keine visuellen Schätzungen. Farben, Schriftgrößen, Schriftgewichte, Abstände, Ecken, Rahmen, Schatten – stets die exakten Werte aus dem Design übernehmen.
3. Zuerst das Design anfordern, nicht eigenständig UI schreiben.
4. Nach der Implementierung muss eine Validierung erfolgen: tatsächlichen Programm-Screenshot mit dem Design vergleichen → erkannte Mängel automatisch beheben → menschliche Kritik für weitere Iterationen.

Arbeitsablauf

Phase 1: Überblickslesen (Anforderungen und Struktur verstehen)

Wenn das Design zu groß ist, zuerst überblickslesen, um eine Überlastung durch das Abrufen aller Daten auf einmal zu vermeiden:

1. Mit get_figma_data die Top-Level-Struktur abrufen (depth steuert die Durchlaufebene, beginnend mit flachen Ebenen), um zu verstehen, welche Seiten/Blöcke/Steuerelemente es gibt.
2. Mit download_figma_images das gesamte Oberflächenbild exportieren, um Layout und Text zu verstehen.

Phase 2: Detailiertes Lesen (Exakte Daten vor der Implementierung erfassen)

Für den konkret zu implementierenden Block / das Steuerelement gleichzeitig aufrufen:

• get_figma_data (mit nodeId, knotenweise Koordinaten, Farbwerte, Schriftgrößen, Abstände, Ecken, Rahmen lesen)
• download_figma_images (das Blockbild exportieren, um die relative Position der Steuerelemente zu bestätigen)

Nach dem Erhalt zuerst eine Strukturanalyse durchführen, dann Code schreiben:

• Welche Knoten sind wiederholte Muster (Listeneinträge, Karten, Schaltflächen) → In benutzerdefinierte Steuerelemente/Komponenten des Ziel-Frameworks extrahieren
• Welche absolute Positionierung ist eigentlich Layout (horizontale Anordnung, Zentrierung, bündig ausrichten, Raster) → Gemäß der folgenden Mapping-Tabelle in das entsprechende Framework-Layout übersetzen
• Welche sind semantische Rollen (Navigation/Formular/Liste) → Auf vorhandene Steuerelementbibliotheken des Ziel-Frameworks abbilden
• Bild/Symbol-Knoten → Mit download_figma_images die Originaldatei herunterladen und im Ressourcenverzeichnis ablegen, nicht manuell zeichnen

Phase 3: Implementierung (Framework-unabhängige Übersetzung)

Farben/Schriftgrößen/Abstände mit den exakten Werten aus dem Design verwenden. Bei der Übersetzung die folgende Mapping-Tabelle „Canvas-Konzept → Ziel-Framework“ konsultieren, keine Steuerelemente erfinden – wenn das Ziel-Framework Standard-Layouts/Steuerelemente hat, diese verwenden; absolute Koordinaten nur beibehalten, wenn eine genaue Pixelpositionierung wirklich erforderlich ist.

Phase 4: Validierung und Abschluss

Desktop hat keine Browser-Automatisierung wie Playwright. Validierungsmethode: Tatsächlichen kompilierten und ausgeführten Programm-Screenshot neben den Design-Screenshot legen, offensichtliche Mängel automatisch beheben; menschliche Kritik erkennt feinere Probleme (Abstände, Schriftgewichte, Farbnuancen), die dann gezielt an das KI zur Präzisionskorrektur übergeben werden, um in die nächste Iteration zu gehen.

Mapping-Tabelle: Canvas-Konzept → Ziel-Framework

Der Figma-Canvas verwendet absolute Koordinaten + Pixel-Layer, die Implementierung muss in die Layout-Semantik der jeweiligen Frameworks übersetzt werden. Konsultieren Sie bei der Übersetzung diese Tabelle:

Canvas/Design-Konzept	Qt Widget	QML (Qt Quick)	WinUI 3 (XAML)	Flutter
Horizontale Anordnung	QHBoxLayout	Row	StackPanel (Orientation=Horizontal)	Row
Vertikale Anordnung	QVBoxLayout	Column	StackPanel (Orientation=Vertical)	Column
Raster-Layout	QGridLayout	Grid / GridLayout	Grid	GridView / Table
Absolute Positionierung	setGeometry / move	Item + x/y	Canvas + Canvas.Left/Top	Stack + Positioned
Überlagerung/Abdeckung	Child-Widget überlagern / raise()	z-Eigenschaft / Stack	Canvas.ZIndex	Stack
Zentrierung	addStretch / setAlignment	anchors.centerIn	HorizontalAlignment/VerticalAlignment=Center	Center / Align
Bündig ausrichten	Beidseitig addStretch	anchors.left/right + margins	Ränder zuweisen	MainAxisAlignment.spaceBetween
Abstand	QSpacerItem / layout spacing	spacing-Eigenschaft	Margin / Padding	SizedBox / Padding / Spacer
Farbe	QPalette / Stylesheet	Theme / Eigenschaftsbindung	Ressourcenwörterbuch ResourceDictionary	ThemeData / ColorScheme
Schriftgröße/Schriftart	QFont	font.pixelSize	FontSize	TextStyle.fontSize
Abgerundete Ecken	Stylesheet border-radius	Rectangle radius	CornerRadius	BorderRadius
Schatten	QGraphicsDropShadowEffect	DropShadow	ThemeShadow / DropShadow	BoxShadow
Symbole	QIcon / Ressourcen	Image / Icon-Font	FontIcon / SymbolIcon	Icon
Komponenten-Wiederverwendung	Benutzerdefinierte QWidget-Unterklassen	Benutzerdefinierte QML Component	UserControl / Benutzerdefiniertes Steuerelement	Widget
Zustand/Variante	Enum + update()	State / Eigenschaftsgesteuert	VisualStateManager	setState / AnimatedWidget

Anti-Faulheits-Eiserne-Regeln

KI neigt dazu, nur einen Kanal zum Schreiben von Code zu verwenden. Dies muss explizit gefordert werden:

• „get_figma_data und download_figma_images gleichzeitig aufrufen, um das Design zu lesen“
• „Es ist nicht erlaubt, Code nur mit Bildern/Screenshots des Designs zu schreiben“
• „Jede Zeile der exakten Werte von get_figma_data lesen, Farben/Schriftgrößen/Abstände vergleichen, keine visuellen Schätzungen vornehmen“
• „Gemäß der Mapping-Tabelle in die Standard-Layouts/Steuerelemente des Ziel-Frameworks übersetzen, nichts erfinden“

Checkliste zur Umsetzungstreue

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

• Farben (wurden die exakten Werte verwendet, nicht nur Annäherungen?)
• Schriftgröße / Schriftgewicht
• Abstände / Ränder / Innenabstände
• Abgerundete Ecken / Rahmen / Schatten
• Layout (wurde in Standard-Layouts des Ziel-Frameworks übersetzt, anstatt absolute Koordinaten zu übernehmen?)
• Ebenen / Überlagerungsreihenfolge
• Wurden Originaldateien für Symbole/Bilder verwendet, nicht manuell gezeichnet?
• Wurden wiederholte Muster als Komponenten/benutzerdefinierte Steuerelemente extrahiert?

Referenzquellen

Die Methodik ist vom offiziellen Figma MCP + Playwright UI-Entwicklungsprozess inspiriert (siehe „Verbesserung der UI-Entwicklung und Debugging-Effizienz mit Figma MCP und Playwright MCP“). Die Kernidee „beide Kanäle + Validierung abschließen + Anti-Faulheits-Anforderungen“ bleibt erhalten, die Tool-Namen sind an Framelink figma-developer-mcp angepasst, die Mapping-Tabelle wurde um mehrere Desktop-Frameworks erweitert.