Wenn Entwickler nach „Figma Inspector" suchen, wollen sie meist eines von zwei Dingen: Eigenschaftswerte von Knoten einsehen, ohne einen Dev-Mode-Sitz zu benötigen, oder Figma-Inhalte an einen KI-Agenten übergeben. Die erste Kategorie ist durch Plugins gut abgedeckt. Die zweite Kategorie bedient fast nichts — bis auf figmascope.
Dieser Artikel vergleicht beide Kategorien, erklärt, warum sie unterschiedliche Probleme lösen, und zeigt, wie ein agentenfähiger Export in der Praxis aussieht. Probieren Sie den Export selbst auf figmascope.dev aus, oder lesen Sie den vollständigen Vergleich hier weiter. Den praktischen Workflow finden Sie unter Figma zu Cursor oder Figma zu Claude Code.
Was „Figma Inspector"-Tools tatsächlich leisten
Der klassische Figma-Inspector ist das rechte Panel in Figmas eigener UI. Einen Knoten auswählen: Fill, Stroke, Effekte, Abmessungen, Constraints, Typografie sehen. Im Dev Mode (ab 2023) erweitert sich dieses Panel um Code-Snippets — CSS-Eigenschaften, die aus dem Knoten inferiert werden, Auto-Layout als Flexbox ausgedrückt, Farben mit ihren Variable-Namen, sofern Variables eingerichtet sind.
Plugins wie Inspect, Figma to Code, Anima und Dutzende weitere erweitern das noch. Manche generieren React- oder SwiftUI-Snippets aus ausgewählten Knoten. Manche exportieren CSS-Dateien. Manche annotieren die Canvas für Handoff-Reviews.
All diese Tools sind für einen menschlichen Entwickler konzipiert, der auf den Bildschirm schaut. Sie zeigen Informationen auf Anfrage, Knoten für Knoten, ausgewählt von einer Person, die weiß, welchen Knoten sie interessiert.
Warum dieses Modell für KI-Agenten nicht funktioniert
Ein Sprachmodell sitzt nicht in Figma und klickt sich durch Knoten. Es benötigt den gesamten relevanten Kontext in seinem Kontextfenster, bevor es mit der Codegenerierung beginnt. Knotenweises Inspizieren erzeugt Fragmente. Was der Agent braucht, ist ein strukturiertes Dokument, das den gesamten Screen abdeckt: die Hierarchie, die Token-Werte, die Strings, die Komponentenreferenzen — alles auf einmal.
Es gibt auch ein Formatproblem. Dev Mode erzeugt CSS-Snippets, die ungefähr richtig sind, aber nicht ganz — Eigenschaftsnamen unterscheiden sich je nach Framework, Kurzform-Eigenschaften müssen expandiert werden, absolute Pixelwerte müssen auf Ihr Token-System abgebildet werden. Ein Agent, der rohe Dev-Mode-Ausgabe konsumiert, wird Token-Namen neu halluzinieren, Abstandswerte erfinden und Code erzeugen, der aussieht, als hätte ihn jemand geschrieben, der Ihr Design nur einmal kurz gesehen hat.
Inspector-Tools beantworten die Frage: „Was ist dieser Knoten?" Agenten-Tools beantworten: „Was ist dieser gesamte Screen, in einem Format, über das das Modell schlussfolgern kann?"
figmascope als Figma-Inspector-Alternative
figmascope ist kein Panel innerhalb von Figma. Es läuft in Ihrem Browser, kommuniziert direkt mit der Figma REST API und exportiert ein Context-Bundle — ein strukturiertes Zip mit allem, was ein KI-Agent zur Implementierung des Designs benötigt. Das Token-Format ist detailliert beschrieben unter Design Token Export für KI-Agenten, und die übergreifende Handoff-Philosophie wird in AI Design Handoff behandelt.
Der Export umfasst:
- Eine Layout-IR für jeden Frame, typisiert und mit Tokens querverwiesen — kein Haufen roher CSS-Angaben
- Design tokens in einem stabilen JSON-Format, keine Liste von Hex-Werten ohne semantische Namen
- Konsolidierte UI-Strings mit Ressourcenschlüsseln, keine über einzelne Knoten verstreuten Textwerte
- Referenz-Renders mit 2×-Auflösung, damit der Agent neben den Daten eine visuelle Grundwahrheit hat
- Ein
CONTEXT.md-Spezifikationsdokument, das der Agent zuerst liest und das Token-Benennungskonventionen, Umfang und etwaige Anomalien erläutert
Direktvergleich
| Funktion | Figma Dev Mode | Inspector-Plugins | figmascope |
|---|---|---|---|
| Einzelknoten-Eigenschaftswerte | Ja | Ja | Nein (nicht der Zweck) |
| Vollbild-Layout-Baum-Export | Nein | Teilweise | Ja — screens/*.json |
| Typisiertes design tokens JSON | Nein | Manche Plugins | Ja — tokens.json |
| KI-Agenten-Spezifikationsdokument | Nein | Nein | Ja — CONTEXT.md |
| Konsolidierte Strings mit Schlüsseln | Nein | Nein | Ja — strings.json |
| Komponenteninventar | Teilweise | Teilweise | Ja — components/inventory.json |
| Referenz-Renders | Manueller Export | Nein | Ja — screens/*.png (2×) |
| Token-Häufigkeitsinferenz | Nein | Nein | Ja — Fallback für Dateien ohne Variables |
| Erfordert Figma-Sitz | Dev-Mode-Sitz erforderlich | Unterschiedlich | Nein — nur PAT erforderlich |
| Datenschutz / kein Upload | Daten bei Figma verarbeitet | Je nach Plugin | Clientseitig, Token nur an api.figma.com |
Figma Dev Mode — Stärken und Schwächen
Das Code-Panel des Dev Mode ist für menschliche Entwickler genuiner Nutzen, wenn sie schnell einen Abstandswert ablesen oder einen Font-Stack prüfen wollen. Die Variable-Verknüpfung ist ein Schritt in die richtige Richtung — wenn die Figma-Datei Variables sauber nutzt, zeigt Dev Mode den Variable-Namen neben dem aufgelösten Wert.
Wo er für KI-Workflows zu kurz greift:
- Kein Datei-Export. Sie können einen Knoten lesen; Sie können keine maschinenlesbare Repräsentation der gesamten Frame-Hierarchie exportieren.
- CSS-Snippets sind Framework-spezifisch und für Nicht-Web-Ziele (iOS, Android, React Native) oft ungeeignet.
- Keine Strings-Konsolidierung. Textwerte sind pro Knoten sichtbar, aber nicht aggregiert.
- Kein agentlesbares Spezifikationsdokument. Dev Modes Annotationen sind für Menschen, die in der App lesen, nicht für Sprachmodelle, die daraus schlussfolgern.
- Erfordert einen Dev-Mode-Sitz (45 $/Editor/Monat, Stand 2025). figmascope benötigt nur einen Personal Access Token, der kostenlos ist.
Figma Inspector Plugins — die Landschaft
Es gibt grob drei Kategorien von Figma-Inspector-Plugins:
- Property-Viewer — replizieren, was das rechte Panel im Dev Mode zeigt, oft für kostenlose Nutzer ohne Dev-Mode-Zugang. Beispiele: Figma Inspect, Handoff.
- Code-Generatoren — erzeugen framework-spezifischen Code aus ausgewählten Knoten. Beispiele: Figma to Code, Anima, Locofy. Sie generieren Code aus der Einzelauswahl, nicht als strukturierten Vollexport.
- Token-Exporter — exportieren design tokens aus Figma Variables. Beispiele: Tokens Studio (ehem. Figma Tokens), Variables2JSON. Diese lösen das Token-Export-Problem, aber nicht die Layout-IR- oder Agenten-Spezifikationsprobleme.
figmascope gehört keiner dieser Kategorien an. Vom Geist her steht es dem „Token-Exporter" am nächsten, löst aber ein umfassenderes Problem: den vollständigen strukturierten Kontext bereitzustellen, den ein KI-Agent braucht, um einen gesamten Screen korrekt zu implementieren.
Eine detailliertere Aufschlüsselung der Plugin-Landschaft finden Sie unter figmascope vs Figma plugins.
Wann welches Tool verwenden
Diese Tools schließen sich nicht gegenseitig aus. Ein realistischer Workflow:
- Verwenden Sie Dev Mode oder ein Inspector-Plugin, wenn Sie als Entwickler punktuell die Werte eines bestimmten Knotens prüfen, eine Abstandsentscheidung mit dem Designer bestätigen oder nachsehen möchten, zu welchem Variable eine Farbe aufgelöst wird.
- Verwenden Sie figmascope, wenn Sie einen gesamten Screen (oder eine Datei) an einen KI-Agenten zur Codegenerierung übergeben. Führen Sie es einmal pro Design-Meilenstein aus und committen Sie das Bundle ins Repository.
Der Unterschied ist synchrone Inspektion (Mensch liest einen Knoten nach dem anderen) versus Batch-Export (Agent erhält das Gesamtbild in einem strukturierten Dokument).
Der PAT — was er zugreift, was nicht
figmascope verwendet einen Figma Personal Access Token, um die Datei über die REST API zu lesen. Der Token wird in Ihrem Browser eingegeben, verbleibt für die Sitzung im Browser-Speicher und wird ausschließlich als Header an api.figma.com gesendet. Kein Server empfängt ihn. Wenn Sie den Tab schließen, ist er weg.
Das erforderliche Mindestberechtigungsniveau ist File content: read-only. figmascope schreibt nicht in Figma, erstellt keine Kommentare und greift nicht auf Team-Dateien zu, auf die der Token keine Leseberechtigung hat. Das vollständige Bedrohungsmodell finden Sie unter PAT-Sicherheit und figmascope.
So sieht die Ausgabe in einem echten Projekt aus
Nach dem Export liegt das Context-Bundle neben Ihrem Quellcode:
myapp/
├── src/
│ ├── screens/
│ └── components/
├── design/
│ ├── CONTEXT.md ← agent reads this first
│ ├── tokens.json ← typed design tokens
│ ├── _meta.json ← export manifest, warnings
│ ├── components/
│ │ └── inventory.json ← canonical component names + ids
│ ├── screens/
│ │ ├── Home.json ← layout IR
│ │ ├── Home.png ← 2× render
│ │ ├── Profile.json
│ │ └── Profile.png
│ └── strings.json ← all UI copy, dot-notation keys
└── package.json
Das ist das Artefakt, das Sie committen, in CLAUDE.md oder .cursorrules referenzieren und an das Sie Ihren Agenten verweisen. Ein Export, der gesamte benötigte Kontext.
Vergleichen Sie das mit einem typischen Inspector-Workflow: Entwickler öffnet Figma, klickt Knoten für Knoten durch, kopiert Werte in den Code, verpasst einen Variable-Namen, macht den mobilen Padding-Abstand falsch, verbringt zwanzig Minuten damit, Design und Implementierung abzugleichen. Der strukturierte Export beseitigt diese Schleife vollständig, wenn ein Agent die Implementierung übernimmt.
Das Bundle in der KI-Konfiguration des Projekts referenzieren
Claude Code liest CLAUDE.md beim Sitzungsstart. Cursor liest .cursorrules. Beide unterstützen eine projektweite Anweisungsdatei, die die KI vor jeder Aktion orientiert. Fügen Sie einen kurzen Design-Abschnitt hinzu, der auf Ihr design/-Verzeichnis zeigt:
# For CLAUDE.md (Claude Code)
## Design context
All design data is in `design/`. Before implementing any UI:
1. Read `design/CONTEXT.md` for scope and token conventions
2. Use `design/tokens.json` for all color, spacing, radius, and typography values
3. Use `design/components/inventory.json` for canonical component names
4. Use `design/strings.json` for all UI copy — reference by dot-notation key
5. Validate against `design/screens/*.png` renders
# For .cursorrules (Cursor)
Always read design/CONTEXT.md before implementing UI.
Token values are in design/tokens.json — never hardcode colors or spacing.
Component names come from design/components/inventory.json.
UI strings come from design/strings.json with dot-notation keys.
Damit weiß jede Agenten-Sitzung im Projekt automatisch, dass das Design-Verzeichnis existiert und wie es zu nutzen ist — kein wiederholtes Prompten erforderlich.
Die MCP-Alternative — und warum sie nicht dasselbe ist
Figmas eigener Model Context Protocol (MCP)-Server ermöglicht es einer KI, sich direkt mit der Figma API zu verbinden und Knoten auf Anfrage abzufragen. Das ist nützlich für explorative Arbeit — die Frage „Welche Farbe hat dieser Button?" in einem Live-Gespräch. Es erzeugt kein reproduzierbares, versioniertes Artefakt. Jedes Mal, wenn der Agent läuft, liest er die Live-Figma-Datei neu, die sich inzwischen geändert haben kann. Es gibt kein CONTEXT.md, das den Umfang erklärt. Es gibt kein vorgeneriertes Token-Wörterbuch mit stabilen Namen. Es gibt kein Warnsystem für anomales Layout.
figmascope und Figma MCP lösen unterschiedliche Probleme. MCP ist online, live und gut für interaktive Erkundung. figmascope erzeugt ein offline verfügbares, versioniertes, strukturiertes Artefakt, das für deterministischen Codegen zum Implementierungszeitpunkt geeignet ist. Den detaillierten Vergleich finden Sie unter figmascope vs Figma MCP, und im figmascope-Blog finden Sie weitere Vertiefungen zu KI-Design-Workflows.