Cursors AI kan skriva mycket UI-kod. Vad den inte kan göra är att läsa din Figma-fil. Du klistrar in en skärmbild och den gissar — fel avstånd, felaktiga färgvärden, påhittade komponentnamn. Problemet är inte modellen. Det är den saknade strukturerade kontexten.

figmascope överbryggar det gapet. Det exporterar en Figma-fil som ett zip-paket — designtokens, per-skärmslayoutträd, referensrenderingar, komponentinventering, UI-strängar — allt en språkmodell behöver för att generera exakt kod snarare än trovärdig-liknande kod. Huvudappen körs helt i din webbläsare utan backend eller uppladdning.

Den här sidan går igenom hela arbetsflödet från Figma-URL till Cursor-kodgenerering. Om du använder Claude Code istället för Cursor, se Figma till Claude Code för det Claude-specifika arbetsflödet. För en bredare titt på vad som gör överlämning agentredo, se AI-designöverlämning.

Vad som finns i kontextpaketet

När du kör figmascope mot en Figma-fil får du en .zip som innehåller:

Ingenting laddas upp. Din Personal Access Token lever bara i webbläsarminnet och skickas enbart till api.figma.com. ZIP-filen sätts ihop på klientsidan och levereras till din webbläsares nedladdning.

Steg 1 — Skaffa en Figma Personal Access Token

Gå till Figma → Kontoinställningar → Personal Access Tokens och skapa en token med Filinnehåll: skrivskyddad behörighet. Det är det minimum som krävs.

Token lämnar aldrig din webbläsarsession; figmascope skickar den i X-Figma-Token-headern i förfrågningar till api.figma.com och ingenstans annars. Se PAT-säkerhet och figmascope för den fullständiga hotmodellen.

Steg 2 — Exportera kontextpaketet

  1. Öppna figmascope.dev i din webbläsare.
  2. Klistra in Figma-filens URL (t.ex. https://www.figma.com/file/ABC123/MyDesign).
  3. Klistra in din Personal Access Token.
  4. Klicka på Exportera kontextpaket.
  5. En figmascope-<fileKey>.zip laddas ned till din dator.

Packa upp det i ditt projekt. En vettig plats är en design/-mapp i repots rot:

unzip figmascope-ABC123.zip -d design/
# → design/CONTEXT.md
# → design/tokens.json
# → design/screens/Home.json
# → design/screens/Home.png
# → design/components/inventory.json
# → design/strings.json
# → design/_meta.json

Steg 3 — Öppna projektet i Cursor

Öppna din projektmapp i Cursor som vanligt. Katalogen design/ är nu en del av arbetsytan och Cursors indexerare inkluderar den.

Innan du promptar modellen, läs design/CONTEXT.md själv en gång. Den berättar vilka ramar som exporterades, vilket tokennamnsschema som används och listar eventuella varningar som uppstod vid export (t.ex. layout-mode-none-inferred för ramar där Figma inte rapporterade auto-layout). Dessa varningar är desamma som din agent kommer att stöta på.

Steg 4 — Skriv en effektiv Cursor-prompt

Den enklaste startpunkten är en referensprompt du kan klistra in i Cursor Chat:

Läs design/CONTEXT.md först, implementera sedan Home-skärmen.

Använd:
- design/tokens.json för alla färg-, avstånd- och typografivärden
- design/screens/Home.json för layoutträdet
- design/screens/Home.png som visuell referens
- design/strings.json för all text (använd resursnycklarna som i18n-identifierare)
- design/components/inventory.json för att matcha komponentnamn

Mål: React + Tailwind CSS. Mappa tokenvärden till Tailwind-konfigurationsposter snarare
än att hårdkoda hexvärden. Använd komponentnamnen från inventory.json som
komponentfilnamn (PascalCase).

Cursors Composer följer CONTEXT.mds begränsningar, letar upp layoutträdet i Home.json, hämtar avstånd från tokens.json och producerar kod som matchar ditt designsystem snarare än att approximera det.

Modellen känner inte till din design. Den vet vad du ger den. Strukturerad JSON slår en skärmbild varje gång.

Steg 5 — Mappa tokens till ditt ramverkskonfig

Den exporterade tokens.json använder en W3C-liknande kapslad form:

{
  "color": {
    "surface": { "$value": "#f6f2ea", "$type": "color" },
    "accent":  { "$value": "#d96a3a", "$type": "color" }
  },
  "spacing": {
    "4":  { "$value": "16px", "$type": "dimension" },
    "8":  { "$value": "32px", "$type": "dimension" }
  },
  "radius": {
    "sm": { "$value": "4px",  "$type": "dimension" },
    "md": { "$value": "8px",  "$type": "dimension" }
  },
  "typography": {
    "body": {
      "fontFamily": { "$value": "Inter",  "$type": "fontFamily" },
      "fontSize":   { "$value": "14px",   "$type": "dimension" },
      "fontWeight": { "$value": 400,       "$type": "number" }
    }
  }
}

För Tailwind, be Cursor generera ett tailwind.config.js theme.extend-block direkt från tokens.json. Se Designtoken-export för AI-agenter för en djupdykning i tokenformatet och frekvenshärledning. Tokenstrukturen är tillräckligt platt för att traverseras i ett enda Node-skript om du vill automatisera det:

// scripts/tokens-to-tailwind.js
const tokens = require('../design/tokens.json');

const colors = Object.fromEntries(
  Object.entries(tokens.color).map(([k, v]) => [k, v.$value])
);
const spacing = Object.fromEntries(
  Object.entries(tokens.spacing).map(([k, v]) => [k, v.$value])
);

module.exports = { colors, spacing };

Steg 6 — Hantera flerbildsprojekt

Varje ram i din Figma-fil blir en screens/<FrameName>.json och en matchande .png. För ett projekt med ett dussin skärmar, arbeta dig igenom dem stegvis. Cursor Composer hanterar en skärm per session väl; ge den skärmens JSON och PNG som explicita @file-referenser:

@design/screens/Settings.json
@design/screens/Settings.png

Implementera Inställningsskärmen. Följ samma komponentstruktur
som redan implementerats för Hem-skärmen. Använd tokens från design/tokens.json.

Komponentinventeringen (design/components/inventory.json) hjälper dig undvika namnsdrift mellan skärmar — varje komponent refererad i en skärm-JSON har ett kanoniskt id och name i inventeringen. Om du genererar ett delat komponentbibliotek, använd dessa namn som sanningskälla.

Hur IR ser ut i praktiken

Per-skärms-JSON använder en rekursiv nodstruktur. Ett förenklat exempel för en kortkomponent:

{
  "kind": "stack",
  "name": "ProductCard",
  "direction": "vertical",
  "gap": { "$ref": "spacing.4" },
  "padding": { "top": 16, "right": 16, "bottom": 16, "left": 16 },
  "background": { "$ref": "color.surface" },
  "radius": { "$ref": "radius.md" },
  "children": [
    {
      "kind": "leaf",
      "name": "ProductImage",
      "type": "image",
      "width": 320,
      "height": 200
    },
    {
      "kind": "leaf",
      "name": "ProductTitle",
      "type": "text",
      "text": { "$ref": "strings.product.card.title" },
      "style": { "$ref": "typography.heading.sm" }
    }
  ]
}

Tokenreferenser använder $ref-strängar som matchar nycklar i tokens.json. Modellen kan lösa dem utan ett separat uppslagssteg. Se per-skärms-IR förklarat för hela nodschemat.

Hålla kontexten färsk

Designfiler förändras. En bra vana: kör om figmascope när designen har en betydande revision, checka in den uppdaterade design/-mappen och notera versionen i din PR-beskrivning. _meta.json innehåller en tidsstämpel och Figma-filens lastModified-fält, så du kan se skillnaden mellan när paketet senast genererades om kontra när filen senast berördes.

// _meta.json
{
  "figmascopeVersion": "1.0.0",
  "fileKey": "ABC123",
  "exportedAt": "2026-05-11T09:14:00Z",
  "figmaLastModified": "2026-05-10T18:30:00Z",
  "frameCount": 12,
  "warnings": []
}

Om warnings inte är tomt, åtgärda dem innan du lämnar kontexten till agenten. Vanliga varningar: strings-collision (två noder med samma slug löste till samma nyckel) och layout-mode-none-inferred (en behållare utan explicit auto-layout, där figmascope härledde layout från barnpositioner).

Vanliga Cursor-arbetsflöden

Diffbaserade uppdateringar

När designen har en mindre revision — säg att ett avståndsvärde ändrades från spacing.4 till spacing.6 på kortkomponenten — kan du be Cursor att tillämpa bara deltat snarare än att generera om hela skärmen:

design/tokens.json uppdaterades. spacing.4 är nu 24px istället för 16px.
Hitta alla komponenter som använder spacing.4 och uppdatera dem. Rör inte något annat.

Detta fungerar eftersom dina genererade komponenter refererar tokennamn som Tailwind-klasser (gap-spacing-4) snarare än råa pixelvärden. En tokenändring är en sök-och-ersätt, inte en omdesign.

Lägga till en ny skärm i en befintlig kodbas

När du lägger till skärm N i en kodbas som redan har skärmarna 1 till N-1 implementerade, är det viktiga prompttillägget att förankra agenten i det befintliga komponentbiblioteket:

@design/screens/Checkout.json
@design/screens/Checkout.png

Implementera Kassan-skärmen. Återanvänd befintliga komponenter från src/components/
där komponentnamnet matchar design/components/inventory.json.
Skapa bara nya komponentfiler för komponenter som inte redan är implementerade.
Använd design/tokens.json för alla tokenvärden.

Komponentinventeringen är bryggan mellan designkomponentens namn och kodbas-filnamnet. Utan den hittar agenten på importsökvägar och skapar dubblettkomponenter.

Generera ett designsystemsunderlag

Innan du implementerar några skärmar, använd kontextpaketet för att generera ett designsystemsunderlag: tokenkonfigurationen, en färgpalettskomponent och basens typografistilar. Detta förankrar alla efterföljande skärmimplementationer till samma grund:

Läs design/tokens.json och design/CONTEXT.md.

Generera:
1. tailwind.config.ts theme.extend-block från alla tokens
2. src/styles/tokens.css med CSS-anpassade egenskaper för samma tokens
3. src/components/foundations/ColorPalette.tsx som visar alla färgtokens
4. src/styles/typography.css med typografitokenklasserna

Namnge alla klasser och variabler med tokennyckelsökvägarna
(t.ex. --color-accent, text-ink, bg-surface).

När detta underlag finns kan varje skärmimplementation referera till det. Agenten kommer inte att återhärled färger från designen i varje session — den använder de redan genererade klasserna.

Begränsningar att känna till på förhand

figmascopes kontextpaket fångar statisk struktur. Några saker det inte kan representera:

CONTEXT.md-filen noterar vilka ramar som exkluderades och varför, så agenten inte försöker implementera något som avsiktligt låg utanför omfånget.