Screenshot-prompting heeft een plafond. Je plakt het ontwerp, het model maakt een plausibele benadering, je corrigeert het, de volgende beurt dwaalt het opnieuw af. Niets is verankerd. Het model heeft geen bron van waarheid om zichzelf tegen te controleren tussen beurten.
De contextbundel van figmascope verandert het contract. In plaats van een pixelreferentie die het model elke keer moet interpreteren, krijg je een gestructureerde, refereerbare set bestanden — ontwerptokens, layout IR, componentinventaris, UI-teksten — die in de sessie blijven en consistent blijven. Claude Code kan ze lezen, er vanuit implementeren en zijn eigen uitvoer er op aanvraag tegen controleren.
Deze doorloop behandelt de volledige pijplijn van bundelexport tot beoordeelde, token-geverifieerde implementatie.
Wat dit deterministisch maakt
Drie dingen maken de bundel refereerbaar in plaats van interpreteerbaar:
- Tokens zijn getypeerd en voorzien van sleutels.
tokens.jsonwijst semantische namen (spacing.16,color.7f5cfe) toe aan exacte waarden. Het model kan zijn uitvoer controleren aan de hand van het bestand zonder het ontwerp opnieuw te verwerken. - De IR is een boom, geen pixels.
screens/home.jsonbeschrijft de layout in termen van stack/overlay/absolute/leaf-knooppunten — dezelfde abstractie die het implementatiedoel (Compose, React, etc.) gebruikt. Er is geen visuele interpretatiesstap. - De bundel is stabiel over beurten heen. Zodra het in de repo staat, kan elke prompt in de sessie naar dezelfde bestanden verwijzen. Tokenafwijking is detecteerbaar: vraag het model zijn uitvoer te vergelijken met
tokens.jsonen het kan dat mechanisch doen.
Stap 1: Genereer de bundel
Open figmascope.dev in je browser. Plak je Figma-bestands-URL. De exporteur draait aan de clientzijde via de Figma REST API — je persoonlijke toegangstoken van Figma wordt opgeslagen in localStorage en wordt nooit naar de servers van figmascope gestuurd.
Klik op Exporteer agentcontext. De pagina exporteert top-level frames, lost ontwerptokens op, bouwt de IR en downloadt context-bundle.zip.
Stap 2: Pak uit in je project
# vanuit je projectroot
unzip ~/Downloads/context-bundle.zip -d ./design/
# bevestig wat je hebt
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
De mapnaam maakt niet uit — design/ is slechts een conventie. Wat belangrijk is, is dat Claude Code de bestanden kan lezen vanuit de werkdirectory.
Stap 3: Start Claude Code in je repo
cd mijn-app
claude
Claude Code start in je repo-root met volledige bestandstoegang. Het kan bestanden lezen, schrijven en verwijzen naar elk bestand in de boom gedurende de hele sessie — dit is de sleutelcapaciteit die het bundelpatroon laat werken.
Stap 4: Oriënteer de agent
Begin met een leesprompt vóór enige implementatie. Dit laadt de specificatie in de sessiecontext en laat je controleren of de export er goed uitziet voordat er code wordt geschreven.
Lees ./design/CONTEXT.md en vertel me:
1. Voor welk doelframework is deze bundel?
2. Naar welke tokenbestanden verwijst het?
3. Zijn er waarschuwingen die ik moet weten voor het implementeren?
Claude rapporteert terug het doel (standaard Jetpack Compose), de tokenbron en eventuele waarschuwingen uit de CONTEXT.md-koptekst — verloopvullingen, ontbrekende tokenmappings, niet-ondersteunde effecten. Je vangt deze nu op, niet nadat je 200 regels code hebt gegenereerd.
Volg dit op met een snelle tokencontrole:
Geef een overzicht van de top-10 kleurtokens uit ./design/tokens.json.
Geef daarna de afstandstokens.
Dit bevestigt dat het tokenbestand correct is geparseerd en geeft je een mentaal model van het palet vóór de implementatie.
Stap 5: Implementeer een scherm
Nu de implementatieprompt. Wees expliciet over welke bestanden gezaghebbend zijn voor welke beslissingen:
Implementeer ./design/screens/home.json als een Jetpack Compose-scherm.
Regels:
- CONTEXT.md-beperkingen zijn van toepassing. Lees het als je dat nog niet hebt gedaan.
- Alle afstand-, kleur- en straalwaarden moeten komen uit ./design/tokens.json.
Wijs tokensleutels toe aan de juiste Compose-primitieven (bijv. spacing.16 → 16.dp).
- UI-tekenreeksen moeten sleutels gebruiken uit ./design/strings.json via stringResource().
Gebruik als terugval de waarde van het veld "fallback" als er nog geen resource-ID beschikbaar is.
- De IR-knooppuntsoorten worden als volgt toegewezen:
stack (axis:vertical) → Column
stack (axis:horizontal) → Row
overlay → Box
absolute → Box met Modifier.offset
leaf (text) → Text met TextStyle
leaf (rectangle) → Box met Modifier.background
- Verzin geen waarde die niet in de token- of IR-bestanden aanwezig is.
Als er iets ontbreekt, laat een TODO-opmerking achter met de tokensleutel die je verwachtte.
Claude Code zal de IR lezen, de knooppuntboom doorlopen, elk knooppunt toewijzen aan zijn Compose-primitief en tokenwaarden ophalen op sleutel. De uitvoer is traceerbaar: elke .dp-waarde moet overeenkomen met een afstandstoken, elke Color(0xFF...) moet overeenkomen met een kleurtoken.
Stap 6: Detecteer en herstel tokenafwijking
Na de eerste implementatieronde, voer een afwijkingscontrole uit vóór visuele beoordeling. Dit is het belangrijkste voordeel van de bundel boven screenshot-prompting — je kunt het model vragen zijn eigen uitvoer mechanisch te verifiëren.
Vergelijk elke kleurwaarde in de gegenereerde HomeScreen.kt met ./design/tokens.json.
Geef een overzicht van hexwaarden in de uitvoer die niet overeenkomen met een kleurtoken-sleutel.
Identificeer voor elk het juiste token en vervang de hardcoded waarde.
Doe hetzelfde voor afstand:
Vergelijk elke .dp-waarde in HomeScreen.kt met de afstandstokens in ./design/tokens.json.
Markeer elke waarde die niet overeenkomt met een afstandstoken. Vervang door de juiste tokenreferentie.
Deze lus — implementeren, afwijking controleren, herstellen — convergeert snel. Na de tweede of derde ronde is de uitvoer volledig tokengerefereerd.
Tip: neem _meta.json-waarschuwingen op in je eerste prompt
design/_meta.json bevat een array warnings. Dit zijn dingen die de exporteur niet volledig kon oplossen: verloopvullingen, ingebedde afbeeldingen, effecten zonder een tokenequivalent. Lees ze vóór de implementatie:
cat design/_meta.json
Als de uitvoer er zoiets als dit bevat:
{
"warnings": [
"node 'hero-background': gradientFill not fully supported — background fill omitted",
"node 'avatar': imageFill — reference only, no pixel data"
]
}
Voeg deze expliciet toe aan je implementatieprompt: "Sla de heldenachtergrondvulling over en laat een // TODO: gradient achter. Gebruik voor het avatar-knooppunt een tijdelijke AsyncImage met een grijze achtergrond."
Dit voorkomt dat Claude stilletjes bij benadering werkt — het doet wat je hem vertelt in plaats van te raden.
Waarom dit beter is dan screenshot-prompting
Veilig over meerdere beurten. Het tokenbestand en de IR veranderen niet tussen beurten. Je kunt in beurt 12 vragen "heb je de juiste afstand gebruikt voor de kaartopvulling?" en een nauwkeurig antwoord krijgen, omdat de bron van waarheid nog steeds op schijf staat.
Diff-vriendelijk. Wanneer je na een ontwerpwijziging opnieuw exporteert, produceert de nieuwe bundel een diff ten opzichte van de oude. Je kunt Claude vragen de diff te beoordelen en alleen de getroffen componenten bij te werken — geen volledige herimplementatie vereist.
Geen opnieuw uploaden. De bundel leeft in je repo. Je plakt geen screenshots opnieuw voor elk nieuw scherm. Elk nieuw scherm is gewoon design/screens/<naam>.json — nog één bestand om naar te verwijzen in de volgende prompt.
Eerlijk over hiaten. CONTEXT.md en _meta.json geven expliciet aan wat de bundel niet dekt. Screenshot-prompting heeft geen equivalent — het model raadt door de hiaten heen.
De hoofd-figmascope-app regelt de export in je browser — plak je Figma URL, exporteer de bundel en je bent klaar om Claude Code te gebruiken tegen een deterministische specificatie.