Skärmbildspromptning har ett tak. Du klistrar in designen, modellen gör en trovärdig approximation, du korrigerar den, nästa vändning driftar den igen. Ingenting är förankrat. Modellen har ingen sanningskälla att kontrollera sig mot mellan vändningarna.

figmascopes kontextpaket ändrar kontraktet. Istället för en pixelreferens som modellen måste tolka varje gång, får du en strukturerad, referensbar uppsättning filer — designtokens, layout-IR, komponentinventering, UI-strängar — som stannar kvar i sessionen och förblir konsekventa. Claude Code kan läsa dem, implementera från dem och kontrollera sin egen utdata mot dem på begäran.

Den här genomgången täcker hela pipelinen från paketexport till granskad, tokenverifierad implementation.

Vad gör detta deterministiskt

Tre saker gör paketet referensbart snarare än tolkningsbart:

  1. Tokens är typade och nycklat. tokens.json mappar semantiska namn (spacing.16, color.7f5cfe) till exakta värden. Modellen kan kontrollera sin utdata mot filen utan att behöva bearbeta designen om.
  2. IR:n är ett träd, inte pixlar. screens/home.json beskriver layouten i termer av stack/overlay/absolute/leaf-noder — samma abstraktion som implementeringsmålet (Compose, React osv.) använder. Det finns inget visuellt tolkningssteg.
  3. Paketet är stabilt mellan vändningar. När det väl är i repot kan varje prompt i sessionen referera samma filer. Tokendrift är detekterbar: be modellen jämföra sin utdata mot tokens.json och den kan göra det mekaniskt.

Steg 1: Generera paketet

Öppna figmascope.dev i din webbläsare. Klistra in din Figma-fil-URL. Exportören körs på klientsidan via Figma REST API — din Figma Personal Access Token lagras i localStorage och skickas aldrig till figmascopes servrar.

Klicka på Exportera agentkontext. Sidan exporterar toppnivåramar, löser designtokens, bygger IR:n och laddar ned context-bundle.zip.

Steg 2: Packa upp i ditt projekt

# från din projektrot
unzip ~/Downloads/context-bundle.zip -d ./design/

# bekräfta vad du har
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

Katalognamnet spelar ingen roll — design/ är bara en konvention. Det viktiga är att Claude Code kan läsa filerna från arbetskatalogen.

Steg 3: Starta Claude Code i ditt repo

cd my-app
claude

Claude Code startar i din reprot med full filåtkomst. Den kan läsa, skriva och referera vilken fil som helst i trädet under hela sessionen — det är nyckelförmågan som gör paketmönstret fungerande.

Steg 4: Orientera agenten

Börja med en läsprompt innan någon implementation. Det här laddar specen i sessionskontexten och låter dig verifiera att exporten ser bra ut innan du skriver någon kod.

Läs ./design/CONTEXT.md och berätta för mig:
1. Vilket målramverk är det här paketet för?
2. Vilka tokenfiler refererar det?
3. Finns det några varningar jag bör känna till innan jag implementerar?

Claude rapporterar tillbaka målet (Jetpack Compose som standard), tokenkällan och eventuella varningar från CONTEXT.md-headern — gradientfyllningar, saknade tokenmappningar, stödsaknade effekter. Du fångar dessa nu, inte efter att ha genererat 200 rader kod.

Följ upp med en snabb tokenkontroll:

Lista de 10 översta färgtokens från ./design/tokens.json.
Lista sedan avståndstokens.

Det bekräftar att tokenfilen tolkades korrekt och ger dig en mental modell av paletten innan implementation.

Steg 5: Implementera en skärm

Nu till implementeringsprompten. Var explicit om vilka filer som är auktoritativa för vilka beslut:

Implementera ./design/screens/home.json som en Jetpack Compose-skärm.

Regler:
- CONTEXT.md-begränsningar gäller. Läs den om du inte redan gjort det.
- Alla avstånd-, färg- och radievärden måste komma från ./design/tokens.json.
  Mappa tokennycklar till lämpliga Compose-primitiver (t.ex. spacing.16 → 16.dp).
- UI-strängar måste använda nycklar från ./design/strings.json via stringResource().
  Falla tillbaka till värdet i "fallback"-fältet om inget resurs-ID är tillgängligt än.
- IR-nodtyperna mappas enligt följande:
    stack (axel:vertikal)    → Column
    stack (axel:horisontell) → Row
    overlay                  → Box
    absolute                 → Box med Modifier.offset
    leaf (text)              → Text med TextStyle
    leaf (rektangel)         → Box med Modifier.background
- Hitta inte på något värde som inte finns i token- eller IR-filerna.
  Om något saknas, lämna en TODO-kommentar med den tokennyckeln du förväntade dig.

Claude Code läser IR:n, går igenom nodträdet, mappar varje nod till dess Compose-primitiv och hämtar tokenvärden via nyckel. Utdatan är spårbar: varje .dp-värde bör motsvara en avståndtoken, varje Color(0xFF...) bör matcha en färgtoken.

Steg 6: Detektera och fixa tokendrift

Efter det första implementeringspasset, kör en driftkontroll innan du granskar visuellt. Det här är nyckelfördelens med paketet jämfört med skärmbildspromptning — du kan be modellen verifiera sin egen utdata mekaniskt.

Jämför varje färgvärde i den genererade HomeScreen.kt mot ./design/tokens.json.
Lista alla hexvärden i utdatan som inte motsvarar en färgtokennyckel.
Identifiera för var och en den korrekta token och ersätt det hårdkodade värdet.

Gör samma sak för avstånd:

Jämför varje .dp-värde i HomeScreen.kt mot avståndstokens i ./design/tokens.json.
Markera värden som inte matchar en avståndtoken. Ersätt med rätt tokenreferens.

Den här loopen — implementera, kontrollera drift, fixa — konvergerar snabbt. Vid det andra eller tredje passet är utdatan helt tokenrefererad.

Tips: inkludera _meta.json-varningar i din första prompt

design/_meta.json innehåller en warnings-array. Dessa är saker som exportören inte kunde lösa fullt ut: gradientfyllningar, inbäddade bilder, effekter utan tokenekvivalent. Läs dem innan du implementerar:

cat design/_meta.json

Om utdatan innehåller något som:

{
  "warnings": [
    "node 'hero-background': gradientFill not fully supported — background fill omitted",
    "node 'avatar': imageFill — reference only, no pixel data"
  ]
}

Lägg till dessa explicit i din implementeringsprompt: "Hoppa över hero-background-fyllningen och lämna en // TODO: gradient. För avatar-noden, använd en platshållare AsyncImage med grå bakgrund."

Det förhindrar att Claude approximerar tyst — den gör vad du sa istället för att gissa.

Varför detta slår skärmbildspromptning

Flervändningssäker. Tokenfilen och IR:n ändras inte mellan vändningar. Du kan fråga "använde du rätt avstånd för kortpadding?" i vändning 12 och få ett korrekt svar, eftersom sanningskällan fortfarande finns på disk.

Diff-vänlig. När du re-exporterar efter en designändring producerar det nya paketet ett diff mot det gamla. Du kan be Claude granska diffet och uppdatera bara de påverkade komponenterna — ingen fullständig omimplementering krävs.

Ingen re-uppladdning. Paketet finns i ditt repo. Du klistrar inte in skärmbilder på nytt för varje ny skärm. Varje ny skärm är bara design/screens/<name>.json — en fil till att referera i nästa prompt.

Ärlig om luckor. CONTEXT.md och _meta.json listar explicit vad paketet inte täcker. Skärmbildspromptning har ingen ekvivalent — modellen gissar bara igenom luckorna.

Huvud-figmascope-appen hanterar exporten i din webbläsare — klistra in din Figma-URL, exportera paketet och du är redo att köra Claude Code mot en deterministisk spec.