Screenshot-Prompting hat eine Decke. Sie fügen das Design ein, das Modell erstellt eine plausible Annäherung, Sie korrigieren sie, im nächsten Turn driftet es wieder. Nichts ist verankert. Das Modell hat keine Quelle der Wahrheit, gegen die es sich zwischen den Turns überprüfen kann.
Das Kontext-Bundle von figmascope verändert den Vertrag. Anstatt einer Pixel-Referenz, die das Modell jedes Mal interpretieren muss, erhalten Sie einen strukturierten, referenzierbaren Satz von Dateien — Design-Tokens, Layout-IR, Komponenten-Inventar, UI-Strings — die in der Sitzung bleiben und konsistent bleiben. Claude Code kann sie lesen, daraus implementieren und seine eigene Ausgabe bei Bedarf dagegen prüfen.
Diese Anleitung behandelt die vollständige Pipeline vom Bundle-Export bis zur geprüften, token-verifizierten Implementierung.
Was diesen Ansatz deterministisch macht
Drei Dinge machen das Bundle referenzierbar statt interpretierbar:
- Tokens sind typisiert und mit Schlüsseln versehen.
tokens.jsonbildet semantische Namen (spacing.16,color.7f5cfe) auf exakte Werte ab. Das Modell kann seine Ausgabe gegen die Datei prüfen, ohne das Design erneut zu verarbeiten. - Das IR ist ein Baum, keine Pixel.
screens/home.jsonbeschreibt das Layout in Form von Stack/Overlay/Absolute/Leaf-Knoten — dieselbe Abstraktion, die das Implementierungsziel (Compose, React usw.) verwendet. Es gibt keinen visuellen Interpretationsschritt. - Das Bundle ist stabil über Turns hinweg. Einmal im Repo, kann jeder Prompt in der Sitzung dieselben Dateien referenzieren. Token-Drift ist erkennbar: Bitten Sie das Modell, seine Ausgabe gegen
tokens.jsonzu vergleichen, und es kann das mechanisch tun.
Schritt 1: Bundle generieren
Öffnen Sie figmascope.dev in Ihrem Browser. Fügen Sie Ihre Figma-Datei-URL ein. Der Exporter läuft clientseitig über die Figma REST API — Ihr persönliches Figma-Zugriffstoken wird im localStorage gespeichert und niemals an figmascopes Server gesendet.
Klicken Sie auf Agentenkontext exportieren. Die Seite exportiert Top-Level-Frames, löst Design-Tokens auf, erstellt das IR und lädt context-bundle.zip herunter.
Schritt 2: In Ihr Projekt entpacken
# vom Projektstamm aus
unzip ~/Downloads/context-bundle.zip -d ./design/
# Inhalt bestätigen
find design/ -type f | sort
# design/CONTEXT.md
# design/_meta.json
# design/components/inventory.json
# design/screens/home.json
# design/screens/home.png
# design/screens/settings.json
# design/screens/settings.png
# design/strings.json
# design/tokens.json
Der Verzeichnisname ist egal — design/ ist nur eine Konvention. Was zählt, ist, dass Claude Code die Dateien aus dem Arbeitsverzeichnis lesen kann.
Schritt 3: Claude Code in Ihrem Repo starten
cd my-app
claude
Claude Code startet im Stammverzeichnis Ihres Repos mit vollem Dateizugriff. Er kann beliebige Dateien im Verzeichnisbaum lesen, schreiben und über die gesamte Sitzung referenzieren — das ist die entscheidende Fähigkeit, die das Bundle-Muster funktionsfähig macht.
Schritt 4: Den Agenten orientieren
Beginnen Sie mit einem Lese-Prompt vor jeder Implementierung. Dadurch wird die Spezifikation in den Sitzungskontext geladen, und Sie können überprüfen, ob der Export korrekt aussieht, bevor Code geschrieben wird.
Read ./design/CONTEXT.md and tell me:
1. What target framework is this bundle for?
2. What token files does it reference?
3. Are there any warnings I should know about before implementing?
Claude meldet das Ziel (standardmäßig Jetpack Compose), die Token-Quelle und etwaige Warnungen aus dem CONTEXT.md-Header — Verlaufsfüllungen, fehlende Token-Zuordnungen, nicht unterstützte Effekte. Diese erkennen Sie jetzt, nicht nachdem 200 Zeilen Code generiert wurden.
Folgen Sie mit einer schnellen Token-Prüfung:
List the top 10 color tokens from ./design/tokens.json.
Then list the spacing tokens.
Das bestätigt, dass die Token-Datei korrekt geparst wurde, und gibt Ihnen ein mentales Bild der Palette vor der Implementierung.
Schritt 5: Einen Screen implementieren
Jetzt der Implementierungs-Prompt. Seien Sie explizit darüber, welche Dateien für welche Entscheidungen maßgeblich sind:
Implement ./design/screens/home.json as a Jetpack Compose screen.
Rules:
- CONTEXT.md constraints apply. Read it if you haven't already.
- All spacing, color, and radius values must come from ./design/tokens.json.
Map token keys to the appropriate Compose primitives (e.g. spacing.16 → 16.dp).
- UI strings must use keys from ./design/strings.json via stringResource().
Fall back to the "fallback" field value if no resource ID is available yet.
- The IR node kinds map as follows:
stack (axis:vertical) → Column
stack (axis:horizontal) → Row
overlay → Box
absolute → Box with Modifier.offset
leaf (text) → Text with TextStyle
leaf (rectangle) → Box with Modifier.background
- Do not invent any value not present in the token or IR files.
If something is missing, leave a TODO comment with the token key you expected.
Claude Code liest das IR, traversiert den Knotenbaum, ordnet jeden Knoten seinem Compose-Primitiv zu und zieht Token-Werte anhand des Schlüssels. Die Ausgabe ist nachvollziehbar: Jeder .dp-Wert sollte einem Spacing-Token entsprechen, jede Color(0xFF...) einem Farb-Token.
Schritt 6: Token-Drift erkennen und beheben
Führen Sie nach dem ersten Implementierungsdurchlauf eine Drift-Prüfung durch, bevor Sie visuell reviewen. Das ist der entscheidende Vorteil des Bundles gegenüber Screenshot-Prompting — Sie können das Modell bitten, seine eigene Ausgabe mechanisch zu verifizieren.
Compare every color value in the generated HomeScreen.kt against ./design/tokens.json.
List any hex values in the output that don't correspond to a color token key.
For each one, identify the correct token and replace the hardcoded value.
Dasselbe für Abstände:
Compare every .dp value in HomeScreen.kt against the spacing tokens in ./design/tokens.json.
Flag any value that doesn't match a spacing token. Replace with the correct token reference.
Diese Schleife — implementieren, Drift prüfen, korrigieren — konvergiert schnell. Beim zweiten oder dritten Durchlauf ist die Ausgabe vollständig token-referenziert.
Tipp: _meta.json-Warnungen in Ihren ersten Prompt aufnehmen
design/_meta.json enthält ein warnings-Array. Das sind Dinge, die der Exporter nicht vollständig auflösen konnte: Verlaufsfüllungen, eingebettete Bilder, Effekte ohne Token-Äquivalent. Lesen Sie sie vor der Implementierung:
cat design/_meta.json
Wenn die Ausgabe etwa Folgendes enthält:
{
"warnings": [
"node 'hero-background': gradientFill not fully supported — background fill omitted",
"node 'avatar': imageFill — reference only, no pixel data"
]
}
Fügen Sie diese explizit in Ihren Implementierungs-Prompt ein: „Hero-Hintergrundfüllung überspringen und // TODO: gradient hinterlassen. Für den Avatar-Knoten einen Platzhalter-AsyncImage mit grauem Hintergrund verwenden."
Das verhindert, dass Claude stillschweigend approximiert — er tut, was Sie ihm gesagt haben, anstatt zu raten.
Warum das Screenshot-Prompting übertrifft
Multi-Turn-sicher. Die Token-Datei und das IR ändern sich nicht zwischen Turns. Sie können in Turn 12 fragen „Haben Sie den richtigen Abstand für das Card-Padding verwendet?" und eine genaue Antwort erhalten, weil die Quelle der Wahrheit noch auf der Festplatte liegt.
Diff-freundlich. Wenn Sie nach einer Design-Änderung neu exportieren, erzeugt das neue Bundle einen Diff gegen das alte. Sie können Claude bitten, den Diff zu reviewen und nur die betroffenen Komponenten zu aktualisieren — keine vollständige Neuimplementierung erforderlich.
Kein erneuter Upload. Das Bundle liegt in Ihrem Repo. Sie fügen keine Screenshots für jeden neuen Screen erneut ein. Jeder neue Screen ist einfach design/screens/<name>.json — eine weitere Datei zum Referenzieren im nächsten Prompt.
Ehrlich über Lücken. CONTEXT.md und _meta.json listen explizit auf, was das Bundle nicht abdeckt. Screenshot-Prompting hat kein Äquivalent — das Modell rät einfach durch die Lücken.
Die figmascope-Haupt-App übernimmt den Export in Ihrem Browser — fügen Sie Ihre Figma-URL ein, exportieren Sie das Bundle, und Sie können Claude Code gegen eine deterministische Spezifikation ausführen.