OpenDesigner : faire émerger un design system pour son projet en quelques réponses

À qui cela s'adresse

Aux développeurs et aux petites équipes qui utilisent déjà un assistant de codage IA mais dont le projet n'a pas encore de règles visuelles unifiées : vous n'avez peut-être que quelques maquettes ou quelques descriptions orales, tandis que les couleurs, les polices et les espacements du code sont écrits différemment d'une page à l'autre ; ou bien le projet démarre à peine et personne n'a le temps de construire d'abord un design system complet. C'est un complément pour les outils IA que vous utilisez déjà : il transforme des préférences difficiles à formuler en fichiers que le code peut consommer directement, plutôt que de vous envoyer dans un autre logiciel de design ; c'est un projet open source gratuit sous licence MIT, il ne remplace pas votre éditeur, il y ajoute simplement une couche de capacités. Ceux qui acceptent de répondre à quelques questions courtes, d'accepter que les résultats soient écrits dans le répertoire du projet, et de relire eux-mêmes avant la fusion sont bien placés pour l'essayer une fois. Ceux qui viennent de reprendre le code de quelqu'un d'autre et qui veulent d'abord cerner le ton visuel peuvent s'en servir pour un survol rapide.

Votre première tentative en 3 minutes

Vérifiez d'abord les prérequis : Python 3.10 ou plus récent doit être présent sur la machine. Le moteur est un simple fichier Python, aucune dépendance à installer.

Première étape, installez la skill. La voie recommandée est la place de marché de plugins de Claude Code : saisissez /plugin marketplace add ckryptickunal/OpenDesigner dans la conversation, appuyez sur Entrée, puis saisissez /plugin install opendesigner@opendesigner.

Deuxième étape, repérez l'emplacement d'installation. Les outils qui prennent en charge les Agent Plugins lisent le fichier plugin.json à la racine, tandis que les clients qui lisent les skills les récupèrent par convention dans le répertoire .agents/skills/ ; les clients qui ne passent pas par la place de marché exigent que vous copiez vous-même la skill dans .agents/skills/ de votre projet.

Troisième étape, déclenchez une tâche à faible risque. Ouvrez votre projet, dites dans la conversation « Create a design system for this project. » et il posera au maximum cinq questions courtes, chacune assortie d'une réponse suggérée et de sa justification, si bien qu'il vous suffit de les confirmer ou de les réécrire une par une. Pour la première fois, choisissez de préférence un répertoire propre ou créez d'abord une branche, afin que les tokens générés ne se mélangent pas au code existant.

Quatrième étape, convenez à l'avance des effets de bord et des points de confirmation. Le moteur écrit ses résultats sous forme de DESIGN.md, PRODUCT.md et d'un répertoire opendesigner/ contenant les tokens, les différents exports et une page d'aperçu. L'écriture sur le disque réécrit directement le contenu du dépôt : créez donc une branche ou faites un commit avant ; ne le laissez écrire qu'une fois les réponses confirmées.

Cinquième étape, observez les signaux de succès observables. Les trois artefacts ci-dessus apparaissent dans le projet et l'autocontrôle ne signale aucune erreur : le contraste du texte est validé selon WCAG 2.2 AA, les cibles de clic font au moins 24 px, le focus clavier est visible et la préférence de mouvement réduit est prise en charge ; dès qu'une erreur apparaît, la build s'arrête.

Cas d'usage

Premier cas : poser la première version d'un design system pour un nouveau projet. Une fois le plugin installé, dites dans le projet la phrase déclencheuse anglaise ci-dessus, répondez aux cinq questions courtes au maximum qu'il pose et vous obtenez un design system complet plutôt que des fragments épars. La première version n'a pas besoin d'être parfaite, c'est le point de départ de vos questions et itérations suivantes. Vous pouvez ensuite approfondir : couleurs, polices, espacements et animations s'affinent chacun dans une nouvelle série de questions, et les résultats atterrissent toujours dans les mêmes trois fichiers et répertoires. Les preuves s'arrêtent là : la documentation officielle indique que le nombre de questions est plafonné à cinq et que les dimensions à approfondir sont ces quatre-là, mais elle ne dit pas si l'on peut ajuster le nombre de questions, ni ne décrit la forme de l'interaction de chaque série d'approfondissement.

Deuxième cas : réutiliser la même skill dans un client dépourvu de place de marché de plugins. Copiez la skill dans le répertoire .agents/skills/ du projet, puis demandez comme d'habitude la génération d'un design system dans la conversation et répondez aux questions ; les résultats et les règles d'autocontrôle sont exactement les mêmes que dans le premier cas. Si le projet possède déjà ses conventions de tokens, vérifiez avant de copier que les deux schémas de nommage n'entrent pas en conflit. La documentation officielle indique seulement que ces clients lisent les skills dans ce répertoire, sans expliquer comment mettre à jour après la copie ni fournir d'étapes supplémentaires de dépendances ou de configuration.

Limites d'usage

Le moteur n'a qu'une seule exigence ferme : Python 3.10 ou plus récent, et aucune dépendance à installer au-delà. Les modes d'installation sont eux aussi ceux que la documentation officielle énonce : hors de la place de marché de plugins, la skill doit être copiée manuellement, et le projet ne fournit aucune commande de mise à jour automatique ou de vérification pour ce chemin manuel. À l'exécution, il réécrit directement les fichiers du projet : prévoyez donc une branche ou un commit avant de commencer. L'autocontrôle intégré est une barrière ferme : un contraste inférieur à WCAG 2.2 AA, des cibles de clic sous 24 px, un focus clavier invisible ou une préférence de mouvement réduit non traitée arrêteront la build ; il ne corrige rien à votre place, il faut corriger puis relancer. La question sous-jacente des cinq questions est qu'elles doivent pouvoir recevoir une réponse brève ; lorsque des règles métier complexes entrent en jeu, le moteur ne peut pas trancher. Un design system n'est pas non plus un produit final : les tokens et les documents restent dans le dépôt, et la documentation officielle n'explique ni comment les fusionner avec une bibliothèque de composants existante, ni s'il faut les faire entrer dans le suivi de version, c'est à vous de trancher. Dépôt : <https://github.com/ckryptickunal/OpenDesigner >.