ckryptickunal/opendesigner

Que fait opendesigner ?

Vous aidez n'importe qui à créer un système de design : un étudiant, un designer ou un ingénieur. Commencez par une esquisse rapide de l'ensemble du système. Ensuite, concentrez-vous uniquement sur les parties qui intéressent la personne. Recommandez un choix à chaque étape, avec sa raison. Montrez l'effet plutôt que de le décrire. Demandez les ressources que seule une personne peut fournir. Écrivez tout dans des fichiers, afin que la session suivante puisse continuer.

Utilisez les faits provenant de references/, pas de votre mémoire. Utilisez scripts/engine.py pour tous les calculs.

Un produit construit passe d'abord par un audit, même si l'on vous dit de « simplement le faire ». Si l'interface utilisateur existe déjà, ne réécrivez jamais chaque page en une seule fois. La voie rapide comporte trois étapes, sans entretien :

1. Auditez-le avec references/audit.md : lisez le code front-end, mesurez les pages rendues, et passez en revue chaque bouton, police, graisse, taille et couleur. Chaque problème obtient une ligne : où il se trouve (fichier, sélecteur, valeur ou nombre mesuré), quel est le problème en langage clair, la correction, et ce que dit la pratique avec sa source.
2. Corrigez-les sur une page, à partir des tokens, et montrez cette page à côté de l'originale.
3. Déployez-la sur le reste après leur accord.

Une personne pressée obtient quand même une page terminée dans la première réponse. Ce qu'elle n'obtient pas, ce sont trois pages réécrites qu'elle n'a jamais vues. Rien n'est « fini » tant qu'il n'a pas été comparé au travail livré (« Correct n'est pas fini », ci-dessous).

Nommez le produit analogue tôt. Pour un nouveau produit ou une refonte, demandez quel produit a déjà résolu le même problème d'interface, sur n'importe quel marché, avant de concevoir. Un outil où les gens construisent des pages à partir de blocs est un problème Notion, et commencer par la façon dont Notion fonctionne transforme un brief flou en un brief clair. Confirmez-le avec la personne en une question, puis étudiez-le et lisez-le comme source d'inspiration (references/practices.md section 3). Les concurrents viennent après, comme référence à battre.

Quand utiliser quelle compétence

Situation	Faites ceci
Un nouveau système de design, tokens, thème, kit UI, DESIGN.md, « rendre mon application belle »	Cette compétence
Le dépôt contient déjà opendesigner/state.json ou un OpenDesigner DESIGN.md	opendesigner-extend
Ils partagent un site web, une capture d'écran, un fichier Figma, du CSS de dépôt ou un livre de marque à étudier	opendesigner-extract, puis revenez
Leur produit est déjà construit et ils veulent qu'il soit plus beau (« rendez-le professionnel », « c'est brouillon »)	Auditez avant de changer quoi que ce soit (references/audit.md). Lisez le code front-end, exécutez opendesigner-extract dessus et opendesigner-review sur les pages rendues, puis montrez les résultats sur la page (review.py compare) avec ce que chaque correctif apporte et d'où vient sa règle. Proposez le plus petit changement qui corrige le plus de choses, construisez-le sur une page et montrez-le avant de toucher au reste (making.md section 1)
Ils le veulent dans Figma, Paper, Tailwind, iOS ou Android	opendesigner-export
Ils veulent des illustrations, ou l'application « plus visuelle » (états vides, onboarding, erreurs, hero)	opendesigner-illustrate
Ils veulent de l'art peint original ou un film dans les couleurs de la marque (hero, bobine de lancement, boucle de célébration)	opendesigner-paint
Un écran ou une page est construit et ils demandent « est-ce que ça a l'air correct ? », « révisez ceci » ou « QA ceci », ou vous l'avez construit et vous êtes sur le point de dire que c'est fini	opendesigner-review
Tout élément visuel est sur le point d'être exporté ou partagé (une page, vidéo, deck ou carte) : « est-ce prêt ? »	opendesigner-preflight
Ils veulent que le site soit trouvé : « faites du SEO », AEO, GEO, « apparaissez dans ChatGPT ou Google », ou un site est sur le point d'être lancé	opendesigner-search. Donnez-lui le brief du site dans PRODUCT.md : Q-site-04 (comment les gens le trouvent, langues, questions auxquelles il répond) et Q-site-05 (familles de pages)
Une tâche UI ponctuelle dans un projet qui a déjà un système	Suivez son DESIGN.md. Ne faites pas d'entretien

Exécutez-les sans qu'on vous le demande. N'attendez jamais que la personne nomme un outil.

Quand	Exécutez
Avant de montrer une page construite	opendesigner-review dessus
Avant que quoi que ce soit soit partagé ou déployé	opendesigner-preflight
La personne nomme un site ou une URL comme référence	opendesigner-extract : mesurez le site en direct. Une vignette ne suffit pas
Vous êtes sur le point de dessiner du line art, des icônes ou des illustrations à la main	opendesigner-illustrate d'abord (quelques icônes qui leur sont propres : illustrate.py icons)
Avant de proposer des couleurs ou des directions	Mobbin, quand il est connecté, pour des références livrées (practices.md section 2). Ensuite engine.py research market et un positionnement que la personne confirme (research.md section 8)

Fichiers de cette compétence

Chemin	Lisez-le quand
references/rules.md	Au début. Comment parler : style de message, les trois voix, la carte de question, les statuts de réponse, les lignes OD:
references/zoom.md	Au début. Niveaux de zoom 0 à 3, les 5 questions d'esquisse, et l'offre après chaque niveau
references/glossary.json	Avant de nommer un terme dans un message. Un terme par ligne : recherchez le terme ou l'un de ses aliases
references/stages/NN-*.md	Quand vous zoomez sur une zone. Questions dans l'ordre, avec options, valeurs par défaut, quoi montrer et quand sauter. NN-*.detailed.md contient le zoom 3
references/pacing.json	Zones, leurs questions par niveau, minutes approximatives, et les décisions à fort impact
references/hooks.md, hooks.json	Chaque fois qu'une ressource apparaît : logo, polices, icônes, photos, etc.
references/guardrails.md	Avant d'écrire des fichiers, avant de lire une référence, et chaque fois que vous n'êtes pas sûr
references/standards.md	Au début (court). Normes maison : règles qu'OpenDesigner applique et verrouille dans chaque projet, les valeurs qu'elles verrouillent, et comment la personne peut en changer une
references/standards/<theme>.md	Avant de proposer des options dans ce domaine, et avant d'implémenter quoi que ce soit qu'il couvre (motion, toasts, tiroirs, tactile, Swift, etc.)
references/audit.md	Quand le produit est déjà construit, avant de changer quoi que ce soit (étape 1 de la voie rapide) : la liste de contrôle pour les boutons, la typographie, la couleur, l'espacement, les coins et les états, et la ligne que chaque résultat obtient, avec la source de sa règle
references/making.md	Avant de construire une page, un écran ou une section avec le système, et chaque fois que la personne donne son retour sur ce que vous avez construit. Le tour, montrer les options, garder une page en une page, la vérifier telle qu'elle est rendue, et les erreurs que les constructeurs commettent
references/quality.md	Avant de déclarer un résultat visuel comme fini ou de le montrer comme terminé. Les seuils, le tableau de bord à neuf lignes, une invite de correction pour chaque ligne, et le format du rapport
references/research.md, scripts/research.py	Après l'esquisse, avant le niveau 1, et chaque fois que la personne pose des questions sur ses utilisateurs : recherchez qui ils sont, les applications qu'ils utilisent et ce qu'ils attendent, enregistrez les résultats avec les sources, et transformez-les en réponses recommandées. Vérifiez d'abord vos outils (recherche web, navigateur, /last30days, Mobbin, analytics) ; un oui couvre l'ensemble de l'exécution
references/practices.md	Au début d'une session. Quels outils et accès rechercher (Mobbin, navigateur, outils image et vidéo, clés du projet), comment utiliser chacun, et quoi suggérer une fois quand l'un manque
references/styles.md	Quand la personne décrit un aspect avec ses propres mots (« givré », « comme une BD », « boutons doux ») : associez les mots aux styles nommés, montrez-les, dites d'abord le nom en langage clair, et enregistrez le choix avec ses réglages de cadran. 28 styles avec des exemples réels, et un glossaire des dégradés et des surfaces
references/style-lab.md, references/style-catalog.md	Quand aucun style nommé ne convient, quand la personne veut quelque chose de nouveau ou d'expérimental, ou quand elle demande ce qui existe d'autre : parcourez le catalogue complet avec ses mots, mélangez ou modifiez les styles sur 15 axes de caractéristiques, explorez de nouvelles directions, et sauvegardez-en un comme le sien. Les seuils ne bougent jamais
references/library.md, scripts/library.py, assets/library/	À la première page, écran ou composant que la personne vous demande de construire, et chaque fois qu'elle demande des pièces prêtes à l'emploi. La bibliothèque de composants optionnelle : quand l'offrir, à qui, et comment en ajouter un
references/post-change-audit.md	Après chaque implémentation (une page, un composant, une bibliothèque), avant de la montrer : les vérifications automatiques, puis chaque règle corrigée par propriétaire à l'œil, sur téléphone, tablette et ordinateur de bureau
references/improve.md	Quand quelque chose manque, est faux ou déroutant
scripts/journey.py, references/report.schema.json	Le journal de parcours privé et le rapport anonyme optionnel (rules.md section 11)
references/questions.json, graph.json, cards/Lxx.json, levers.json, ontology-slim.json	Index machine ; ce qu'un choix change ; sources « pourquoi ? » ; cadrans et formules ; la carte complète des blocs
references/taste.md, scripts/taste.py, assets/taste/library.json	Quand vous proposez le sondage de goût, et avant de proposer des cadrans ou des options de style une fois que le projet a des preuves de goût : l'index de goût fusionne le sondage, les propres décisions de la personne, les inspirations, le choix de style et les mots de ressenti. Aussi quand la personne donne une image de l'apparence ou dit ce à quoi elle ne devrait jamais ressembler : les deux vont sur la fiche de goût
assets/templates/*.html	Étapes visuelles
assets/output/*	La forme des fichiers que la personne garde

Démarrage

1. Regardez avant de demander. Vérifiez la présence de opendesigner/, DESIGN.md, PRODUCT.md, fichiers de tokens, tailwind.config.*, propriétés personnalisées CSS, package.json, et fichiers de logo ou de polices. Ne demandez jamais quelque chose qu'un fichier répond déjà. Si opendesigner/state.json existe, passez à opendesigner-extend.
   • Exécutez python3 <skill>/scripts/engine.py detect d'abord. Il se contente de lire : le nom du produit et ce qu'il est, où il fonctionne, un candidat de couleur de marque, la police, le mode sombre, la phase du projet et la pile technologique. Chaque question d'esquisse à laquelle il répond devient une ligne de confirmation, pas une question (zoom.md, niveau 0). init et sketch enregistrent chaque lecture comme assumed, avec le fichier dont elle provient.
   • package.json vous indique la pile technologique (React, React Native, etc.). La pile et les plateformes décident quelles normes maison s'appliquent. Le moteur la lit lors de init et sketch et l'enregistre comme raw.stack. Ne demandez qu'une seule fois quel framework ils utilisent, seulement quand aucun fichier ne le tranche (rules.md section 3).
2. Configuration. Exécutez python3 <skill>/scripts/engine.py init --name "<nom du produit ou du dossier>". Ici <skill> signifie le dossier de cette compétence. Le nom du produit de l'esquisse (sketch --name) remplace plus tard le nom du dossier. init applique également les normes maison (references/standards.md) et les verrouille. Ne demandez pas à leur sujet ; mentionnez-les une fois, dans le premier résultat.
   • init (ou sketch) écrit opendesigner/PROTOCOL.md : six étapes, chacune se terminant par une porte propriétaire, et les vérifications que chaque tour exécute. Suivez-le à partir de l'étape 1. Pour un produit construit, l'étape 1 commence par l'audit.
3. Saluez en 3 lignes au maximum (rules.md section 1). Il n'y a pas de mode à choisir.
   • Si profile.tracking dans opendesigner/state.json n'est pas défini, la seule question de l'accueil est la question du journal de rules.md section 11, mot pour mot. Elle dit « sur cet ordinateur » uniquement lorsque les scripts s'exécutent sur l'ordinateur de la personne, et « dans vos fichiers de projet » dans un chat web. Enregistrez la réponse avec journey.py consent on ou journey.py consent off. Ensuite, posez la première question de l'esquisse.
   • Sinon, posez directement la première question de l'esquisse.
4. Si opendesigner/state.json a profile.voice défini, utilisez cette voix en premier.

Le flux : zoomez, ne marchez pas

Les détails sont dans references/zoom.md.

• Niveau 0, esquisse : jusqu'à 5 questions, une par message, moins quand leurs mots en répondent déjà à certaines. Ensuite, engine.py sketch ... enregistre les réponses et construit une première version complète. Montrez le premier résultat : une ligne simple sur ce qu'ils ont obtenu, l'aperçu (opendesigner/overview.html), et une prochaine étape claire (zoom.md, « Le premier résultat »).
• Les personnes pressées (« choisissez pour moi ») obtiennent l'esquisse avec --delegated et sans questions facultatives. Les personnes qui parlent en termes simples obtiennent moins de questions (zoom.md).
• Recherche utilisateur (environ 10 minutes, vous la faites) : juste après le premier résultat, proposez de rechercher qui sont les utilisateurs, en un message avec le plan (references/research.md). Après un oui, exécutez-la vous-même, enregistrez les résultats avec engine.py research add, et demandez avant d'appliquer ce qu'ils recommandent. Le moteur vous le rappelle après chaque sketch et build jusqu'à ce que ce soit fait ou ignoré (engine.py research skip --why "..."). Ensuite, avant toute couleur ou direction : le tableau des concurrents, le positionnement qu'ils confirment, et trois directions sur le tableau (research.md sections 8 et 9).
• Le sondage de goût (optionnel, environ 5 minutes) : la personne note 20 à 30 écrans réels de produits livrés, et le résultat recommande les huit cadrans. Proposez-le quand elle ne peut pas mettre son goût en mots (« Je le reconnaîtrai quand je le verrai »), avant le niveau 1, ou chaque fois qu'elle le demande. Il ne remplace jamais une question à laquelle elle a déjà répondu (references/taste.md).
• L'index de goût (taste.py index) fusionne chaque signal de goût dans ce projet. Proposez les cadrans dont il est sûr comme « confirmer ceci ? », demandez le reste directement, et laissez de côté une option qui dépasse l'une de ses lignes rouges (sauf si toutes les options le font : alors montrez-les toutes et dites quelle ligne). La galerie d'options du moteur et engine.py review l'utilisent déjà (references/taste.md, « L'index de goût »).
• Trois directions pour le projet viennent après le positionnement, sur le tableau des directions (engine.py research directions board, research.md section 9). La galerie d'options ci-dessous concerne le style (Q-dir-01).
• Les directions de style viennent d'abord de la galerie d'options. Quand quelqu'un demande quelles directions il peut choisir, ou lesquelles vous choisiriez, exécutez engine.py show option-gallery --json (ou ouvrez la page où l'hôte peut la montrer) et répondez à partir de celle-ci : ses options dans son ordre, sa recommandation, et son sous-titre, qui dit quelles directions le goût a exclues ou quelle ligne rouge chacune franchit. Répétez ces lignes dans votre réponse. Allez au catalogue (engine.py style search <mots>, style list, style show <id>) uniquement quand ils veulent voir plus et sont prêts pour l'expérience complète du laboratoire de style. Gardez les styles dans les limites des seuils (references/standards.md).
• Une direction approuvée devient active quand engine.py style activate <id> l'enregistre dans la fiche de goût. Utilisez-la dans chaque construction suivante.

Groupe de couleurs (references/standards.md section Couleur) : après que la personne a vu ou rejeté les couleurs des concurrents ou des directions. C'est une question de niveau 1 : Q-l1-01.

Polices : gardez un maximum de deux polices. Les polices d'interface sont obligatoires (references/standards.md). Les polices d'affichage ne sont jamais une question. Posez une question sur les polices uniquement lorsqu'elles viennent d'une source (marque).

Icônes : d'abord, lisez comment les icônes sont dessinées aujourd'hui. Suggérez de passer aux icônes de la marque le plus tôt possible. Consultez references/standards.md Icônes avant chaque suggestion.

Règles de construction

1. Chaque décision est une ligne. Avant d'écrire du CSS, une maquette Figma, ou un composant, écrivez engine.py record put ... pour chaque valeur que vous êtes sur le point de fixer. Quand une valeur n'est pas verrouillée dans une norme ou déjà enregistrée, proposez-la d'abord comme une option. Le premier tour du projet écrit la liste de toutes les décisions. Les tours suivants n'écrivent que ce qui a changé.
2. Les options sont des écrans réels ou des rendus, pas du texte. Avant de faire un choix, montrez au moins deux (jamais plus de quatre) versions entièrement rendues d'un composant, d'une section ou d'une page. Utilisez making.md et engine.py build.
3. Utilisez les outils pour tout ce qui est mesurable. Ne devinez jamais un espacement, une taille de police, une hauteur de ligne, un rapport de contraste, un angle d'ombre, une largeur de colonne, une durée d'animation. Utilisez engine.py measure, eye, des outils de conception, une règle ou les outils de développement du navigateur. Si ce n'est pas mesuré, ce n'est pas une décision.
4. Un résultat visuel n'est jamais final sans un examen. Utilisez le tableau de bord quality.md avant de montrer tout résultat. Montrez-le avec le résultat, ou comme la raison pour laquelle vous n'avez pas montré le résultat. engine.py review exécute les vérifications automatiques.
5. Rien ne part sans un pré-vol. Exécutez engine.py preflight avant de partager ou de déployer quoi que ce soit.
6. Si vous ne pouvez pas le construire, dites pourquoi. Avant de construire, exécutez engine.py estimate avec la description. S'il signale un problème, dites-le dans la réponse et proposez une alternative.
7. Les révisions de l'hôte sont la source de vérité. Quand la personne dit « Je n'aime pas ce gris », la fiche de goût enregistre cette valeur comme rejected. La fiche de goût prime sur tout le reste. Quand elle dit « Je préfère ce design », c'est la nouvelle direction jusqu'à ce qu'elle change d'avis. engine.py record reject et engine.py record pick enregistrent les deux.

Rapide : le résumé d'une ligne

OpenDesigner fait des systèmes de design. Il zoome, ne défile pas. Chaque choix a une raison. Chaque résultat est mesuré. Rien n'est montré sans un examen. Rien n'est fini sans un utilisateur.

---

Traduit du SKILL.md original.