Créer un outil de conception pour agents d’IA et garder ses commandes et contrôles en ordre

## Regrouper les commandes de conception dans une seule skill, chacune liée à un fichier de référence Gardez l’interface de commandes destinée à l’utilisateur compacte, tout en acheminant chaque commande reconnue vers une documentation de référence ciblée. La consolidation réduit l’encombrement des menus et facilite la maintenance des règles de conception communes. ### Architecture des commandes - Préférez une seule compétence de conception invocable par l’utilisateur et dotée de sous-commandes à de nombreuses compétences autonomes, sauf si un cycle de vie distinct est réellement nécessaire. - Maintenez une seule table de routage qui associe chaque commande à son fichier de référence. - Conservez les descriptions de commandes, les indications d’arguments, les catégories et les relations dans des métadonnées faisant autorité, utilisées par les processus de génération et les générateurs de raccourcis. - Générez les fichiers de compétence propres à chaque fournisseur depuis une source unique au lieu de modifier séparément la copie de chaque fournisseur. - N’utilisez les raccourcis légers que comme des redirections vers la commande canonique. - Placez les règles communes dans la source partagée et les décisions propres à une commande dans la référence correspondante ; créez un lien vers les orientations communes au lieu de les dupliquer. ### Routage contextuel - Lisez le contexte du projet avant de choisir un registre ou un référentiel de règles de plateforme. - Donnez la priorité à un champ de projet explicite, puis utilisez les indices de la tâche et de la surface, et enfin une valeur par défaut documentée. - Signalez les valeurs de contexte inconnues au lieu d’appliquer silencieusement un référentiel sans rapport. - Chargez les références de variante plutôt que le fichier par défaut lorsque le comportement d’une commande diffère sensiblement selon la plateforme. ## Choisir d’abord marque ou application, puis ajouter les règles web ou de plateforme native Traitez l’objectif de conception et la plateforme de diffusion comme des axes indépendants. Le registre définit l’objectif d’expérience ; la plateforme définit les conventions d’interaction et les contraintes de mise en œuvre. ### Registre de conception - Utilisez un registre de marque lorsque la conception constitue le produit : marketing, campagnes, portfolios, expériences éditoriales et surfaces publiques distinctives. - Évaluez le travail de marque selon son caractère distinctif dans de nombreuses orientations visuelles, au lieu d’imposer un unique style à la mode. - Utilisez un registre de produit lorsque la conception sert une application, un tableau de bord, une interface d’administration ou un outil. - Évaluez le travail sur le produit selon la familiarité légitime, la confiance et l’aisance qu’il procure aux utilisateurs expérimentés. - Demandez le registre dès le début, car il modifie les décisions de conception ultérieures. ### Plateforme - Distinguez le Web adaptatif, une plateforme native unique et une diffusion adaptative multiplateforme. - Superposez les orientations de la plateforme native au registre sélectionné au lieu de considérer la plateforme comme un substitut à l’objectif de conception. - Pour les produits adaptatifs, appliquez les deux référentiels natifs et adaptez-les à chaque système d’exploitation ; un traitement visuel unique sur toutes les plateformes n’est pas adaptatif. - Laissez les superpositions de navigateur, les détecteurs HTML et les points d’accroche Web actifs désactivés pour les projets natifs, même lorsque leurs fichiers sources utilisent des extensions semblables à celles du Web. - Conservez la vérification de l’accessibilité dans un parcours d’audit dédié. N’insérez pas de manière répétée des rappels génériques sur l’accessibilité pendant la création lorsqu’ils produiraient un travail prudent, mais insuffisamment conçu. ## Respecter les règles de couleur et la liste d’expressions interdites dans les textes publics Les jetons visuels, le code de mise en page, la voix éditoriale et le contenu publié exigent des responsables explicites et des contrôles automatisés, sans remplacer le jugement humain en matière de conception. ### Fondations visuelles - Préférez une architecture de styles compacte et inspectable, avec un point d’entrée, des jetons partagés et des modules partiels ciblés. - Utilisez les jetons de couleur sémantiques de façon cohérente : l’encre au contraste maximal pour le corps du texte, des tons sombres plus doux uniquement lorsque la taille le permet, et des tons atténués pour les libellés secondaires. - Évitez le noir pur et le blanc pur lorsque le système visuel définit des extrêmes teintés. - Gardez les règles de mise en œuvre proches de la surface qu’elles régissent et préservez le rechargement à chaud lorsqu’il est pris en charge. ### Discipline éditoriale - Lisez les orientations éditoriales du projet avant de modifier des textes publics, des tutoriels, de la documentation ou des pages marketing. - Appliquez une liste d’exclusion documentée pour les expressions galvaudées, la ponctuation et les schémas de prose typiques de l’IA. - Ne contournez pas un validateur de prose par des artifices orthographiques. Si un terme interdit possède un sens technique nécessaire, proposez une modification du guide de style. - Examinez les problèmes structurels que les expressions régulières ne peuvent pas évaluer, notamment les certitudes creuses, les rythmes répétitifs, les triades automatiques et les pivots de contraste stéréotypés. - Conservez chaque élément éditorial dans un seul arbre de contenu utilisé à la fois par les outils de génération et le cadre de rendu. - Donnez aux contenus éditoriaux des commandes un libellé court et des sections consacrées aux cas d’usage, au processus, aux exemples concrets et aux véritables écueils. ## Ne pas mêler les fichiers générés automatiquement aux changements de conception courants Séparez les sources de création, les distributions générées, l’état local et les sorties de publication afin que le travail de conception ordinaire ne produise pas d’artefacts parasites ou trompeurs. ### Compilations axées sur les sources - Utilisez des compilations axées sur les sources pour le développement normal et une compilation de publication distincte lorsque les distributions suivies des fournisseurs doivent être synchronisées. - Traitez les répertoires générés des fournisseurs comme des artefacts de distribution, et non comme des surfaces de création, même lorsqu’ils sont intentionnellement enregistrés dans le dépôt pour l’installation. - Écartez les permutations générées des modifications fonctionnelles, sauf si la tâche concerne une publication, la synchronisation des sorties générées ou une modification du système de compilation. - Régénérez les sorties suivies après les modifications des sources au moyen du processus approuvé, et faites échouer la validation si les manifestes, les métadonnées ou les en-têtes de métadonnées générés divergent. - Ignorez les fichiers d’état local, même lorsqu’ils se trouvent dans des répertoires de distribution suivis. - Redémarrez le serveur de développement lorsque les chargeurs de contenu ou les métadonnées des commandes ne sont pas rechargés à chaud ; ne confondez pas l’actualisation du navigateur avec le rechargement des données produites lors de la compilation. ### Ressources publiées - Générez les cartes pour réseaux sociaux et les ressources similaires à partir de métadonnées faisant autorité afin que les nombres et libellés visibles ne puissent pas diverger. - Effectuez le rendu à une résolution supérieure, puis réduisez-le lorsqu’un texte net est nécessaire. - Lorsqu’une ressource visiblement modifiée nécessite d’invalider le cache, mettez à jour son nom de fichier et toutes ses références dans la même modification. - Vérifiez les routes de déploiement, les réécritures, les ressources statiques et les fonctions serveur au moyen de la compilation prévue par la plateforme. - Ne préchargez les caches d’aperçu externes qu’après la mise en service du nouveau déploiement. ## Ne rien soumettre aux projets externes sans accord et isoler les tests payants Les outils de conception peuvent automatiser la mise en œuvre, mais ils ne doivent pas franchir une limite de contribution humaine sans autorisation explicite. ### Autorisation de contribution - Respectez la politique du dépôt qui impose de commencer par un ticket ou par une approbation. - N’ouvrez ni ticket externe ni demande de fusion, sauf si le responsable autorisé l’a demandé ou clairement approuvé. - Déclarez l’assistance de l’IA dans les commits, les descriptions de modifications, les commentaires et le texte des tickets lorsque la politique l’exige. - Si un agent d’IA non autorisé reçoit malgré tout l’ordre de publier, arrêtez l’action externe et préparez plutôt une note de transmission locale. - Écartez les artefacts de publication générés et les modifications de synchronisation sans rapport des contributions ordinaires. ### Sélection des tests - Conservez les tests unitaires et les tests sur données de référence, rapides et déterministes, dans la suite par défaut. - Placez les tests de cycle complet pilotés par navigateur, l’installation des dépendances, les serveurs de développement actifs et les appels de modèles payants derrière des commandes d’activation explicite. - Exécutez les tests coûteux sur des services réels lorsque vous modifiez le chemin d’intégration qu’ils couvrent, et non comme option par défaut sans limites. - Rendez les agents de test remplaçables derrière une interface étroite et utilisez des simulacres déterministes pour couvrir largement les données de référence. - Pour les évaluations comportementales, vérifiez les traces d’appels d’outils plutôt que des réponses libres soigneusement rédigées. - Faites intervenir plusieurs familles de modèles lorsque le comportement testé est le routage entre fournisseurs, et ignorez proprement les tests en l’absence d’identifiants. - Écartez les suites d’évaluation payantes de l’intégration continue, sauf si leur coût et leur variabilité sont intentionnels. ## Mettre à jour toutes les listes en ajoutant une commande et publier les versions à part Les commandes et les composants diffusés indépendamment nécessitent des métadonnées synchronisées, mais le travail fonctionnel et le travail de publication doivent rester séparés. ### Ajouter ou modifier des commandes - Ajoutez ensemble la référence de commande, l’entrée de routage, l’entrée de menu, la liste des commandes valides, les métadonnées, la catégorie, les relations et l’association de visualisation. - Mettez à jour chaque nombre de commandes visible par les utilisateurs et laissez la compilation dériver et valider les nombres lisibles par machine à partir du routeur. - Séparez le contenu éditorial facultatif des descriptions de déclenchement automatique : le premier s’adresse aux lecteurs, les secondes servent à reconnaître les commandes. - Lorsqu’une commande propre à une plateforme diffère sensiblement, ajoutez une variante acheminée et conservez les détails communs du système d’exploitation dans les références de plateforme. ### Politique de version et de publication - N’incrémentez pas les versions et n’ajoutez pas de notes de publication lors d’une modification fonctionnelle ordinaire. - Versionnez séparément les composants diffusés indépendamment et ne mettez à jour que le composant modifié. - Pour une publication, mettez à jour le manifeste faisant autorité et les miroirs synchronisés, ajoutez des notes visibles par les utilisateurs, exécutez la compilation de publication, puis créez une étiquette avec le préfixe propre au composant. - Prévisualisez l’automatisation de publication avant de publier. - Refusez la publication si l’arbre de travail contient des modifications, si la branche n’est pas synchronisée, si l’étiquette existe déjà, si les notes manquent ou si la régénération produit des écarts non enregistrés. - Gardez les entrées du journal des modifications concises et orientées vers l’utilisateur ; omettez les remaniements internes, les détails d’outillage et la synchronisation des sorties générées. ## Écrire d’abord un test qui échoue avant d’ajouter un contrôle de conception Lorsqu’un même détecteur de conception sert une interface en ligne de commande, une superposition de navigateur, une extension et un site Web, son moteur de règles doit posséder une source unique et chaque consommateur dérivé doit être reconstruit et vérifié. ### Ordre de développement des règles 1. Ajoutez un fichier de test comportant des exemples identifiés de manière unique, au moins quatre cas à signaler et au moins cinq formes de faux positifs. 2. Utilisez des dimensions explicites lorsque le DOM de test ne possède pas de moteur de mise en page. 3. Ajoutez un test ciblé et observez son échec avant de mettre en œuvre la règle. 4. Ajoutez les métadonnées de la règle et une fonction de vérification pure qui renvoie des identifiants et des extraits stables sans accéder au DOM. 5. Mettez en œuvre des adaptateurs distincts pour le navigateur et le DOM de test, puis reliez les deux adaptateurs à chaque boucle de parcours concernée. 6. Reconstruisez chaque consommateur généré du détecteur et exécutez la suite de tests complète. 7. Vérifiez le fichier de test et une page réelle représentative dans un navigateur afin de détecter les désaccords entre adaptateurs et les faux positifs. ### Discipline des fichiers de test et de l’évaluation - Utilisez un texte cité stable ou un autre identifiant déterministe dans les extraits afin que les tests puissent extraire le cas correspondant. - Ne vous fiez pas à la géométrie de mise en page dans un émulateur DOM ; analysez plutôt les styles explicites. - Utilisez des fonctions auxiliaires communes pour les arrière-plans, les dégradés et la normalisation des couleurs lorsque le comportement diffère entre le navigateur et l’émulateur. - Lorsque vous mesurez son effet, comparez les résultats de conception issus du même cahier des charges avec et sans le système de conception. - Conservez l’infrastructure d’évaluation dans son propre espace de travail avec ses propres instructions d’exploitation. - Compilez la dernière source de conception avant une série d’évaluations et mettez à jour tout filtre de sections de compétence intégrées dès que les titres d’orientation de premier niveau changent.