Screenshot prompting has a ceiling. You paste the design, the model makes a plausible approximation, you correct it, the next turn it drifts again. Nothing is anchored. The model has no source of truth to check itself against between turns.

figmascope's context bundle changes the contract. Instead of a pixel reference that the model has to interpret every time, you get a structured, referenceable set of files — design tokens, layout IR, component inventory, UI strings — that stay in the session and stay consistent. Claude Code can read them, implement from them, and check its own output against them on demand.

This walkthrough covers the full pipeline from bundle export to reviewed, token-verified implementation.

What makes this deterministic

Three things make the bundle referenceable rather than interpretable:

  1. Tokens are typed and keyed. tokens.json maps semantic names (spacing.16, color.7f5cfe) to exact values. The model can check its output against the file without re-processing the design.
  2. The IR is a tree, not pixels. screens/home.json describes the layout in terms of stack/overlay/absolute/leaf nodes — the same abstraction the implementation target (Compose, React, etc.) uses. There's no visual interpretation step.
  3. The bundle is stable across turns. Once it's in the repo, every prompt in the session can reference the same files. Token drift is detectable: ask the model to compare its output against tokens.json and it can do it mechanically.

Step 1: Generate the bundle

Open figmascope.dev in your browser. Paste your Figma file URL. The exporter runs client-side using the Figma REST API — your Figma personal access token is stored in localStorage and never sent to figmascope's servers.

Click Export Agent Context. The page exports top-level frames, resolves design tokens, builds the IR, and downloads context-bundle.zip.

Step 2: Unzip into your project

# from your project root
unzip ~/Downloads/context-bundle.zip -d ./design/

# confirm what you have
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

The directory name doesn't matter — design/ is just a convention. What matters is that Claude Code can read the files from the working directory.

Step 3: Start Claude Code in your repo

cd my-app
claude

Claude Code starts in your repo root with full file access. It can read, write, and reference any file in the tree across the entire session — this is the key capability that makes the bundle pattern work.

Step 4: Orient the agent

Start with a reading prompt before any implementation. This loads the spec into the session context and lets you verify the export looks right before writing any code.

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 will report back the target (Jetpack Compose by default), the token source, and any warnings from the CONTEXT.md header — gradient fills, missing token mappings, unsupported effects. You catch these now, not after generating 200 lines of code.

Follow up with a quick token check:

List the top 10 color tokens from ./design/tokens.json.
Then list the spacing tokens.

This confirms the token file parsed correctly and gives you a mental model of the palette before implementation.

Step 5: Implement a screen

Now the implementation prompt. Be explicit about which files are authoritative for which decisions:

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 will read the IR, walk the node tree, map each node to its Compose primitive, and pull token values by key. The output is traceable: every .dp value should correspond to a spacing token, every Color(0xFF...) should match a color token.

Step 6: Detect and fix token drift

After the first implementation pass, run a drift check before reviewing visually. This is the key advantage of the bundle over screenshot prompting — you can ask the model to verify its own output mechanically.

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.

Do the same for spacing:

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.

This loop — implement, check drift, fix — converges fast. By the second or third pass, the output is fully token-referenced.

Tip: include _meta.json warnings in your first prompt

design/_meta.json contains a warnings array. These are things the exporter couldn't fully resolve: gradient fills, embedded images, effects without a token equivalent. Read them before implementing:

cat design/_meta.json

If the output includes something like:

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

Add these explicitly to your implementation prompt: "Skip the hero background fill and leave a // TODO: gradient. For the avatar node, use a placeholder AsyncImage with a grey background."

This prevents Claude from silently approximating — it'll do what you told it instead of guessing.

Why this beats screenshot prompting

Multi-turn safe. The token file and IR don't change between turns. You can ask "did you use the right spacing for the card padding?" in turn 12 and get an accurate answer, because the source of truth is still on disk.

Diff-friendly. When you re-export after a design change, the new bundle produces a diff against the old one. You can ask Claude to review the diff and update only the affected components — no full reimplementation required.

No re-upload. The bundle lives in your repo. You don't re-paste screenshots for every new screen. Each new screen is just design/screens/<name>.json — one more file to reference in the next prompt.

Honest about gaps. CONTEXT.md and _meta.json explicitly list what the bundle doesn't cover. Screenshot prompting has no equivalent — the model just guesses through the gaps.

The main figmascope app handles the export in your browser — paste your Figma URL, export the bundle, and you're ready to run Claude Code against a deterministic spec.