Un pipeline d’export d’assets, c’est toute la chaîne qui va du fichier de design aux fichiers exploitables par un build : exporter, redimensionner, optimiser, renommer, placer. C’est exactement le type de tâche répétitive et lourde en manipulations de fichiers qu’un agent sait parfaitement gérer, et exactement le genre de travail qui reste bloqué parce que le designer doit demander à un développeur de s’en charger. Un agent épinglé au dossier des assets, accessible dans une salle, élimine cet intermédiaire.
The request
« @assets export the icon set from the design file at 1x, 2x and 3x, optimise, and put them in /public/icons. Post a contact sheet. »
Ce que fait l’agent
- Il appelle l’API de l’outil de design pour récupérer les composants d’icônes actuels.
- Il les exporte aux trois résolutions dans un dossier temporaire.
- Il lance l’optimiseur déjà installé sur la machine.
- Il les renomme selon la convention du projet, documentée dans le
README.mddu dossier. - Il déplace les fichiers dans
/public/icons, remplaçant le jeu précédent. - Il génère une planche contact et la publie dans la salle avec le décompte des fichiers.
Le designer suit chaque étape dans la timeline et obtient la planche contact à la fin. Temps total : environ une minute.
Ce qui se met en pause
L’étape 1 lit le token d’API de l’outil de design. Il s’agit d’une action de type credential, elle se met donc en pause la première fois pour demander l’accord du propriétaire, avec une carte affichant qui a fait la demande et ce que l’agent souhaite lire. Le propriétaire valide ; le token ne quitte jamais la machine et le designer ne le voit jamais. Voir four actions an agent should always ask before doing.
Si l’agent souhaitait également commiter et pousser les nouvelles icônes sur main, cela se mettrait également en pause. La plupart des équipes le laissent plutôt commiter sur une branche et ouvrir une pull request, ce qui ne déclenche aucune pause.
La configuration
- Un agent, un dossier. Épinglez
assetsau répertoire des assets graphiques du dépôt du site, ou à un dossier d’exports dédié si vous préférez tenir l’agent à l’écart du code. - Écrivez les conventions. Un
README.mdavec la nomenclature, les tailles, les formats et les chemins de destination. L’agent le lit à chaque exécution. - Mode de permission
acceptEdits. Écrire des fichiers fait partie de son rôle ; les commandes continuent de demander confirmation. Voir permission modes, explained. - Autorisation permanente pour les designers. Une seule validation chacun, puis ils peuvent lui faire des demandes librement.
- Conservez le token sur la machine, à l’emplacement de configuration habituel de l’outil. Ne le collez ni dans la demande, ni dans le README.
Variantes
Pourquoi une salle et pas un script
Un script réalise l’export. Une salle permet à la personne qui remarque le changement de déclencher l’action, d’en suivre l’avancement et d’obtenir le résultat — sans terminal, sans ticket et sans mobiliser un ingénieur pour les opérations de routine, tandis que les cas sensibles (credentials, suppressions, pushs) s’arrêtent toujours pour validation auprès du propriétaire. Elle conserve aussi une trace de qui a exporté quoi et à quel moment. Voir coding agents do more than code.
Foire aux questions
Le designer a-t-il besoin d’un accès à l’API de l’outil de design ? Non. Le token reste sur la machine du propriétaire et l’agent l’utilise sur place. Le designer fait la demande ; le propriétaire valide la lecture de l’identifiant.
L’agent peut-il ouvrir une pull request ? Oui, si le répertoire de l’agent se situe à l’intérieur du dépôt et qu’il a accès à git sur la machine. Ouvrir une PR sur une branche ne déclenche pas de pause ; pousser vers une branche partagée en déclenche une.
Que faire si le designer veut modifier la convention de nommage ? Modifiez le README dans le dossier, ou demandez à l’agent de le faire. Il relit les conventions à neuf lors de chaque demande.
L’export prend une minute. L’attente était le vrai problème. Offrez une salle à votre agent d’assets.
Publié le