Varje figmascope-export börjar med en .zip som innehåller sju artefakter. CONTEXT.md är den som läses först — med avsikt. Det är inte en README. Det är inte genererad dokumentation. Det är ett kompilatorliknande kontrakt mellan designen och agenten som ska omvandla den till kod.

Det här inlägget går igenom vad som finns i den, varför den är strukturerad som den är och vad som går fel när du hoppar över den.

Hur ett kontrakt ser ut kontra hur dokument ser ut

Dokumentation beskriver vad som finns. Ett kontrakt specificerar vad som måste vara sant. Den distinktionen är viktig när din läsare är en LLM som glatt hittar på avståndsvärden, plattar ut layouthierarkier eller hårdkodar hexfärger i det ögonblick den inte har ett bättre alternativ.

CONTEXT.md öppnar med en måldeklaration:

# CONTEXT.md — Jetpack Compose-mål

Den här filen är den auktoritativa specen för att generera UI-kod från det här paketet.
Läs den innan du läser någon annan fil.

"Jetpack Compose-mål" är inte dekoration. Agenten använder det för att välja Composable-primitiver, hantera dp vs sp-enheter, veta att Modifier.padding() är rätt abstraktion för avstånd och förstå att Box med Alignment är hur du hanterar overlay-layouter. Ett React/Tailwind-mål genererar en annan CONTEXT.md med andra primitiver i begränsningarna.

Instruktionen "läs detta först" är också avsiktlig. Agenter bearbetar kontext sekventiellt. Om en tokenregel dyker upp efter att agenten redan har börjat resonera om en komponent, anländer begränsningen för sent. Att front-loada kontraktet innebär att reglerna är aktiva från den första genereringsstokenen.

Avsnittet med strikta begränsningar

Den mest belastningsbärande delen av CONTEXT.md är begränsningsblocket:

## Strikta begränsningar (måste följas)

- Hårdkoda aldrig dp-värden om en token finns inom ±2dp
- Platta aldrig ut layouthierarkin — bevara varje stack/overlay/absolute-nod
- Använd stringRef-värden från strings.json, infoga aldrig bokstavlig text inline
- Behandla saknade fält som frånvarande, inte noll
- Hitta inte på komponentnamn som inte finns i components/inventory.json

Varje begränsning finns för att vi sett agenter bryta mot den. Regeln om ±2dp är det tydligaste exemplet. Utan den kommer en agent som stöter på gap: 14 på en stacknod att skriva Arrangement.spacedBy(14.dp). Med regeln vet den att kontrollera om spacing.16 eller spacing.12 är inom 2dp och använda token istället. Det är ett annat resultat — ett som förblir sammanhängande när tokenvärdet ändras, ett som inte gör det.

Hierarkiregeln finns för att Compose är ett layoutträd. När en agent plattar ut en kapslad stack till en platt lista av positionerade element, förstör den det responsiva beteende som den ursprungliga strukturen antydde. IR:n bevarar varje kapslingsnivå av ett skäl — se Per-skärms-IR — Stack, Overlay, Absolute, Leaf för hur den kapslingen kodar layoutintentionen.

Begränsningen är inte "använd tokens om du vill". Det är "hårdkoda aldrig om en token finns." Det är ett förbud, inte ett förslag. LLM:er svarar annorlunda på förbud än på förslag.

Regeln om stringRef är viktig för i18n. Om en agent infogar "Speed Test" inline istället för att referera resursnyckel har du skapat ett lokaliseringshål. Begränsningen pekar agenten explicit till strings.json.

Hur agenten läser CONTEXT.md sekventiellt

LLM-kontextfönster bearbetar token vänster-till-höger. Strukturen i CONTEXT.md utnyttjar detta. Ordningen är:

  1. Måldeklaration (sätter hela genereringsramen)
  2. Strikta begränsningar (förbud som gäller varje beslut)
  3. Paketkarta (vilka filer som finns och vad var och en innehåller)
  4. Tokenanvändningsregler (hur man löser avstånd, färg, radie, typografi)
  5. Omfångsnoteringar (ärliga luckor — vad det här paketet täcker och inte täcker)

Paketskartsektionen berättar för agenten vilka filer som ska läsas och i vilken ordning:

## Paketinnehåll

- tokens.json — designtokens (avstånd, radie, färg, typografi)
- screens/*.json — per-skärms-IR i stack/overlay/absolute/leaf-format
- components/inventory.json — komponentidentitetslista
- strings.json — i18n-resursnycklar
- _meta.json — generationsmetadata och varningar

Utan den här kartan kanske en agent inte vet att components/inventory.json finns, eller kanske behandlar _meta.json som huvud-specen. Den explicita uppräkningen guidar läsordningen.

Omfångsnoteringar — vad v0.4 ärligt nog inte täcker

Omfångsnotateringssektionen är där figmascope dokumenterar sina egna begränsningar. Det är avsiktligt och icke-förhandlingsbart. En agent som inte vet att en spec är ofullständig kommer med säkerhet att fylla luckorna med påhitt. Det är värre än att veta att luckan finns.

## Omfångsnoteringar (v0.4)

- Gradientfyllningar stöds inte. Noder med gradientfyllningar ger en varning
  i _meta.json under warnings. Behandla som en enfärgsapproximation eller TODO.
- Typografitokens kräver att Figma Variables är ifyllda. Om tokensSource
  är "inferred-from-frequency" eller "none" kan typografitäckningen vara partiell.
- Det här paketet täcker bara UI-struktur. Navigation, tillståndshantering
  och nätverksanrop är utanför omfånget.
- Komponentinstanser identifieras av componentId. Fullständiga komponentkälls-
  props ingår inte — inventeringen ger identitet, inte implementation.

Gradientvarningen är särskilt viktig. Figma stöder komplexa gradientfyllningar som saknar direkt Compose-ekvivalent utan anpassad ritning. Istället för att tyst droppa gradienter eller generera trasig kod, skickar figmascope en background-gradient-not-supported:<name>-varning i _meta.json och noterar det här så att agenten vet att behandla påverkade noder som en känd lucka snarare än ett fel i sin egen output.

Typografinotan ansluter till fältet tokensSource i _meta.json. När en Figma-fil saknar Variables, härleder figmascope tokens från frekvens — vanliga värden blir tokens, ovanliga gör det inte. Omfångsnoten berättar för agenten att den här härledningen är ofullkomlig och att den inte ska anta fullständig typografitäckning. Se tokens.json förklarad för hur inferens-fallbacken fungerar.

FEL/RÄTT-exempel

Låt oss göra detta konkret. Givet en stacknod med gap: 16 och en tokenfil som innehåller spacing.16: 16:

Utan CONTEXT.md-begränsningar (FEL):

Column(
    modifier = Modifier.padding(horizontal = 24.dp),
    verticalArrangement = Arrangement.spacedBy(16.dp)
) {

Med CONTEXT.md-begränsningar (RÄTT):

Column(
    modifier = Modifier.padding(horizontal = Spacing.spacing24),
    verticalArrangement = Arrangement.spacedBy(Spacing.spacing16)
) {

RÄTT-utdata är tokenrefererad. När designsystemet ändrar spacing.16 från 16dp till 14dp förblir koden korrekt utan en kodbasomfattande sök-och-ersätt.

Ett annat exempel — stränghantering. Givet en lövnod med text: "Speed Test" och stringRef: "speed.test":

FEL:

Text(text = "Speed Test")

RÄTT:

Text(text = stringResource(R.string.speed_test))

Begränsningen pekar till strings.json, nyckeln är speed.test och agenten vet hur man mappar punktnotation till Android-resurs-ID:n. Det är bara möjligt om agenten läste begränsningen innan den genererade komponenten.

Varför inte bara prompta agenten själv?

Du kan skriva dessa instruktioner manuellt i din prompt. figmascope externaliserar dem till en fil för att:

Målet är inte att prompt-engineera runt agentens standarder. Det är att leverera en spec som gör standarderna irrelevanta.

Struktur jämfört med alternativ

Figmas Dev Mode producerar mätvärden, variabler och kodsnippets. Den producerar inte en spec. Agenten som använder Dev Mode-output måste härleda regler från exempel — vilket innebär att den härleder fel regler för kantfall.

Locofy och liknande verktyg genererar kod direkt. De har ingen CONTEXT.md-ekvivalent eftersom de inte förväntar sig att en agent ska läsa en spec — de förväntar sig att vara agenten. Det fungerar när verktygets kodgenerering exakt matchar ditt stack. Det fungerar inte när du har projektspecifika namnkonventioner, ett anpassat komponentbibliotek eller ett designsystem med tokens som verktyget inte känner till.

CONTEXT.md är ett maskinläsbart designbriefing. Det är det som existerade som en Confluence-sida eller Notion-dokument i varje pre-LLM-designöverlämning, bara strukturerat för en publik som faktiskt följer regler.

Vad man gör med det

När du öppnar en figmascope-export i Cursor eller Claude Code:

  1. Lägg till @CONTEXT.md i din kontext innan någon prompt om designen.
  2. Referera skärm-JSON:en du arbetar med: @screens/home.json.
  3. Om du rör tokens, lägg till @tokens.json.
  4. Om du arbetar med strängar, lägg till @strings.json.

CONTEXT.md-begränsningarna gäller för hela sessionen när de väl laddats. Du lägger inte till dem per prompt — du lägger till dem en gång i början och låter dem rama in varje efterföljande generering.

De andra artefakterna i paketet täcks i resten av den här serien. Börja med tokens.json förklarad för hur tokensystemet hanterar filer med och utan Figma Variables, eller Per-skärms-IR för hur Figma-layouter mappas till stack/overlay/absolute/leaf-noder. Redo att prova? Klistra in din Figma-URL på figmascope.dev och exportera ditt första paket.