Le prompting par capture d'écran a une limite. Vous collez le design, le modèle produit une approximation plausible, vous le corrigez, au tour suivant il dérive à nouveau. Rien n'est ancré. Le modèle n'a pas de source de vérité pour se vérifier entre les tours.
Le bundle de contexte de figmascope change le contrat. Au lieu d'une référence en pixels que le modèle doit interpréter à chaque fois, vous obtenez un ensemble de fichiers structurés et référençables — tokens de design, IR de mise en page, inventaire de composants, chaînes UI — qui restent dans la session et restent cohérents. Claude Code peut les lire, les implémenter et vérifier sa propre sortie à la demande.
Ce tutoriel couvre l'intégralité du pipeline, de l'export du bundle jusqu'à une implémentation revue et vérifiée en termes de tokens.
Ce qui rend cela déterministe
Trois choses rendent le bundle référençable plutôt qu'interprétable :
- Les tokens sont typés et indexés.
tokens.jsonmappe des noms sémantiques (spacing.16,color.7f5cfe) à des valeurs exactes. Le modèle peut vérifier sa sortie par rapport au fichier sans retraiter le design. - L'IR est un arbre, pas des pixels.
screens/home.jsondécrit la mise en page en termes de nœuds stack/overlay/absolute/leaf — la même abstraction qu'utilise la cible d'implémentation (Compose, React, etc.). Il n'y a pas d'étape d'interprétation visuelle. - Le bundle est stable entre les tours. Une fois dans le dépôt, chaque prompt de la session peut référencer les mêmes fichiers. La dérive des tokens est détectable : demandez au modèle de comparer sa sortie avec
tokens.jsonet il peut le faire mécaniquement.
Étape 1 : Générer le bundle
Ouvrez figmascope.dev dans votre navigateur. Collez l'URL de votre fichier Figma. L'exporteur s'exécute côté client en utilisant l'API REST Figma — votre token d'accès personnel Figma est stocké dans localStorage et n'est jamais envoyé aux serveurs de figmascope.
Cliquez sur Export Agent Context. La page exporte les frames de niveau supérieur, résout les tokens de design, construit l'IR, et télécharge context-bundle.zip.
Étape 2 : Décompresser dans votre projet
# depuis la racine de votre projet
unzip ~/Downloads/context-bundle.zip -d ./design/
# vérifier ce que vous avez
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
Le nom du répertoire n'a pas d'importance — design/ est juste une convention. Ce qui compte, c'est que Claude Code puisse lire les fichiers depuis le répertoire de travail.
Étape 3 : Démarrer Claude Code dans votre dépôt
cd my-app
claude
Claude Code démarre à la racine de votre dépôt avec un accès complet aux fichiers. Il peut lire, écrire et référencer n'importe quel fichier de l'arborescence tout au long de la session — c'est la capacité clé qui fait fonctionner le modèle bundle.
Étape 4 : Orienter l'agent
Commencez par un prompt de lecture avant toute implémentation. Cela charge la spec dans le contexte de session et vous permet de vérifier que l'export est correct avant d'écrire du 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 vous indiquera la cible (Jetpack Compose par défaut), la source des tokens, et tous les avertissements de l'en-tête CONTEXT.md — remplissages en dégradé, mappings de tokens manquants, effets non supportés. Vous les repérez maintenant, pas après avoir généré 200 lignes de code.
Poursuivez avec une vérification rapide des tokens :
List the top 10 color tokens from ./design/tokens.json.
Then list the spacing tokens.
Cela confirme que le fichier de tokens a bien été analysé et vous donne un modèle mental de la palette avant l'implémentation.
Étape 5 : Implémenter un écran
Voici maintenant le prompt d'implémentation. Soyez explicite sur les fichiers qui font autorité pour chaque décision :
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 lira l'IR, parcourra l'arbre de nœuds, mappera chaque nœud à sa primitive Compose, et extraira les valeurs de tokens par clé. La sortie est traçable : chaque valeur .dp devrait correspondre à un token d'espacement, chaque Color(0xFF...) devrait correspondre à un token de couleur.
Étape 6 : Détecter et corriger la dérive des tokens
Après la première passe d'implémentation, effectuez une vérification de dérive avant la revue visuelle. C'est l'avantage clé du bundle sur le prompting par capture d'écran — vous pouvez demander au modèle de vérifier mécaniquement sa propre sortie.
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.
Faites de même pour les espacements :
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.
Cette boucle — implémenter, vérifier la dérive, corriger — converge rapidement. Dès la deuxième ou troisième passe, la sortie est entièrement référencée par des tokens.
Astuce : inclure les avertissements de _meta.json dans votre premier prompt
design/_meta.json contient un tableau warnings. Ce sont des éléments que l'exporteur n'a pas pu résoudre complètement : remplissages en dégradé, images intégrées, effets sans token équivalent. Lisez-les avant d'implémenter :
cat design/_meta.json
Si la sortie inclut quelque chose comme :
{
"warnings": [
"node 'hero-background': gradientFill not fully supported — background fill omitted",
"node 'avatar': imageFill — reference only, no pixel data"
]
}
Ajoutez-les explicitement à votre prompt d'implémentation : « Ignorer le remplissage hero-background et laisser un // TODO: gradient. Pour le nœud avatar, utiliser un AsyncImage de substitution avec un fond gris. »
Cela empêche Claude d'approximer silencieusement — il fera ce que vous lui avez dit au lieu de deviner.
Pourquoi c'est mieux que le prompting par capture d'écran
Sûr multi-tour. Le fichier de tokens et l'IR ne changent pas entre les tours. Vous pouvez demander « avez-vous utilisé le bon espacement pour le padding de la carte ? » au tour 12 et obtenir une réponse exacte, car la source de vérité est toujours sur le disque.
Compatible avec les diffs. Quand vous réexportez après une modification du design, le nouveau bundle produit un diff par rapport à l'ancien. Vous pouvez demander à Claude de réviser le diff et de mettre à jour uniquement les composants affectés — aucune réimplémentation complète requise.
Pas de re-upload. Le bundle vit dans votre dépôt. Vous ne recollez pas des captures d'écran pour chaque nouvel écran. Chaque nouvel écran est juste design/screens/<name>.json — un fichier de plus à référencer dans le prochain prompt.
Honnête sur les lacunes. CONTEXT.md et _meta.json listent explicitement ce que le bundle ne couvre pas. Le prompting par capture d'écran n'a pas d'équivalent — le modèle ne fait que deviner à travers les lacunes.
L'application principale de figmascope gère l'export dans votre navigateur — collez votre URL Figma, exportez le bundle, et vous êtes prêt à exécuter Claude Code sur une spec déterministe.