Aider est un assistant de programmation en binôme IA fonctionnant dans le terminal. Il lit les fichiers que vous lui indiquez, génère les modifications sous forme de diffs unifiés, et les applique directement à votre base de code. Chaque modification est vérifiable avant d'être intégrée. Ce workflow centré sur les diffs s'accorde bien avec une passation de design adaptée aux tokens — vous pouvez voir exactement si le code généré utilise spacing.16 du fichier de tokens ou s'il a dérivé vers un 16px codé en dur.
Ce guide couvre l'intégralité du pipeline Aider + figmascope : génération du bundle, chargement dans une session Aider, utilisation du mode Architect pour l'échafaudage initial, et itération avec des prompts d'édition ciblés.
Prérequis
Installez Aider si ce n'est pas encore fait :
pip install aider-chat
# ou
brew install aider
Aider prend en charge plusieurs backends de modèles. Les exemples ici utilisent Claude Sonnet via l'API Anthropic, mais le workflow est identique avec OpenAI ou des modèles locaux.
export ANTHROPIC_API_KEY=sk-ant-...
# ou OPENAI_API_KEY pour GPT-4o
Étape 1 : Générer le bundle
Rendez-vous sur figmascope.dev, collez l'URL de votre fichier Figma et cliquez sur Export Agent Context. L'exporteur s'exécute dans votre navigateur — votre token d'accès personnel Figma reste dans localStorage et ne quitte jamais votre machine.
Le téléchargement arrive sous forme de context-bundle.zip.
Étape 2 : Décompresser dans votre projet
unzip ~/Downloads/context-bundle.zip -d ./design/
ls design/
# CONTEXT.md _meta.json components/ screens/ strings.json tokens.json
Étape 3 : Lancer Aider avec les fichiers du bundle dans la portée
Passez les fichiers du bundle dont vous avez besoin en ligne de commande. Aider les charge comme contexte en lecture seule — le modèle peut les référencer mais ne les modifiera pas à moins que vous n'utilisiez explicitement /add pour les promouvoir en fichiers éditables.
aider \
--read design/CONTEXT.md \
--read design/tokens.json \
--read design/strings.json \
design/screens/home.json \
src/screens/HomeScreen.kt
Le modèle : --read pour les fichiers du bundle (contexte uniquement, non éditables), arguments positionnels pour les fichiers sources qu'Aider doit modifier. Cela garde le bundle propre — la machinerie de diff d'Aider n'essaiera pas de modifier tokens.json.
Si vous voulez qu'Aider crée un nouveau fichier plutôt que d'en modifier un existant, nommez simplement le chemin cible qui n'existe pas encore. Aider le créera.
Étape 4 : Ajouter des PNG de référence
Aider peut inclure des images comme contexte pour les modèles multimodaux. Utilisez la commande /add après le lancement :
/add design/screens/home.png
Le PNG est un rendu à 2× depuis Figma. Avec un modèle multimodal (Claude Sonnet, GPT-4o), Aider l'inclut comme référence visuelle. Utilisez-le pour des vérifications de cohérence lors de la revue — la spec canonique est le JSON, pas l'image.
Étape 5 : Mode Architect — échafaudage initial
La commande /architect d'Aider utilise un modèle en deux étapes : un passage pour planifier, un passage pour implémenter. C'est le bon point de départ pour un écran complet, où vous voulez une structure cohérente avant d'éditer des éléments individuels.
/architect Implement design/screens/home.json as a Jetpack Compose screen.
Context:
- Read CONTEXT.md for framework constraints and target conventions.
- All spacing, color, and radius values come from tokens.json.
Map token keys directly: spacing.16 → 16.dp, color.7f5cfe → Color(0xFF7F5CFE).
- Use string keys from strings.json via stringResource() with the fallback field as the literal fallback.
- IR node kinds: stack(vertical)→Column, stack(horizontal)→Row, overlay→Box,
absolute→Box+Modifier.offset, leaf(text)→Text, leaf(rect)→Box+Modifier.background.
- Do not hardcode any value that has a token equivalent.
Output to: src/screens/HomeScreen.kt
Aider génère d'abord un plan, vous le montre, puis produit le diff. Révisez le plan — si le mapping des nœuds semble incorrect, corrigez-le avant que la passe d'implémentation ne s'exécute.
Étape 6 : Éditer des fichiers spécifiques avec des références de tokens
Une fois l'échafaudage en place, utilisez des prompts /edit ciblés pour corriger des problèmes spécifiques. C'est là que le workflow de diff d'Aider brille — chaque modification est un changement petit et vérifiable plutôt qu'une régénération complète.
The card component in HomeScreen.kt uses hardcoded 12dp for corner radius.
Check tokens.json for the correct radius token and replace it.
Aider produit un diff minimal : une ou deux lignes modifiées, rien d'autre touché. Vous pouvez voir exactement ce qui a changé.
Pour un audit des espacements sur l'ensemble du fichier :
Audit every .dp value in src/screens/HomeScreen.kt against the spacing tokens in design/tokens.json.
Produce a diff that replaces any hardcoded value with its token equivalent where one exists.
Leave a // TODO comment for any value that doesn't match a spacing token.
Étape 7 : Vérifier les diffs par rapport à la spec
La vue de diff d'Aider est la surface de revue. Avant d'accepter toute modification, vérifiez :
- Les lignes ajoutées référencent-elles des clés de tokens plutôt que des valeurs littérales ?
- Les chaînes de caractères apparaissent-elles dans
strings.json, ou sont-elles codées en dur comme texte d'interface ? - L'imbrication des nœuds dans le code généré correspond-elle à l'ordre parent-enfant dans le JSON IR ?
Si un diff semble incorrect, rejetez-le avec n à l'invite et dites à Aider ce qu'il faut corriger. La boucle de feedback courte — prompt, diff, accepter/rejeter, affiner — signifie que vous détectez les dérives immédiatement plutôt qu'après l'intégration d'un grand bloc de code.
Pourquoi le workflow de diff d'Aider se marie bien avec le bundle
La dérive des tokens est visible dans les diffs. Si une ligne générée dit color = Color(0xFF7F5CFE) au lieu de color = tokens.colorPrimary, vous le voyez avant la fusion. Il n'y a pas de « vérifier plus tard » — la revue se fait en ligne.
Le raffinement itératif est peu coûteux. Vous ne régénérez pas l'écran complet à chaque modification. Chaque prompt de suivi produit un diff ciblé. Le bundle fournit le contexte stable ; Aider assure l'édition chirurgicale.
Le bundle est versionné aux côtés du code. Quand le design évolue, réexportez le bundle depuis figmascope, diff-ez-le par rapport à la version précédente, et demandez à Aider d'appliquer uniquement les nœuds modifiés. Le workflow s'adapte à plusieurs itérations de design sans réimplémentation complète.
Modèles courants et pièges
Ne pas ajouter tous les écrans en même temps. Passez un JSON d'écran à la fois. Plus de contexte n'est pas toujours mieux — Aider (et le modèle sous-jacent) fonctionne mieux avec un contexte ciblé qu'avec un dump de tous les écrans du fichier.
Utilisez --read pour le bundle, pas les arguments positionnels. Si vous passez tokens.json comme argument positionnel, Aider pourrait essayer de le modifier. Utilisez --read pour le marquer comme contexte en lecture seule.
Vérifiez _meta.json avant le premier prompt. Le tableau warnings liste les remplissages et effets que l'exporteur n'a pas pu résoudre complètement. Informez Aider à l'avance pour qu'il n'approxime pas silencieusement :
cat design/_meta.json | python3 -c "import sys,json; w=json.load(sys.stdin).get('warnings',[]); print('\n'.join(w))"
Incluez les éventuels avertissements dans votre prompt architect : « Ignorer le remplissage hero-background — dégradé non supporté. Laisser un commentaire TODO. »
Préférez Aider pour les éditions chirurgicales et vérifiables — et utilisez Cursor ou Claude Code quand vous avez besoin d'un contexte de session complet sur de nombreux fichiers. Les trois workflows démarrent de la même façon : l'application principale figmascope gère l'export dans votre navigateur.