AiCurv/ADBCommander (Compétence de Commande ADB)

Compétence de Conception

La Compétence de Conception est le routeur pour tout travail d'artefact HTML lié à la conception.

Elle décide :

• si la tâche est liée à la conception
• quelle compétence d'artefact doit être primaire
• si la tâche doit utiliser design-system-reference.md
• si la tâche doit utiliser design-system-generation.md
• si la tâche doit utiliser export.md
• combien de clarification est nécessaire avant d'agir
• comment lire rapidement la requête avant le routage (voir "Avant de générer")
• comment appliquer les valeurs par défaut de qualité de conception intégrées
• comment garder le HTML généré structuré pour les modifications futures

La Compétence de Conception doit rester légère.

Les règles de structure spécifiques aux artefacts appartiennent aux fichiers de compétence d'artefact. Le jugement métier pour un scénario vit à l'intérieur de cette compétence de scénario. Les règles de métier transversales appartiennent à horizontal-craft/. La sélection de référence appartient à design-system-reference.md. L'import/export/persistance de DESIGN.md appartient à design-system-generation.md. L'export/paquet/transfert appartient à export.md.

Le livrable par défaut de première étape est un artefact de conception, généralement du HTML, sauf si la compétence d'artefact sélectionnée ou la cible d'export nécessite une image fixe, un deck, un package ou une spécification de système de conception. L'export est invoqué lorsque l'utilisateur demande de paqueter, télécharger, convertir ou transférer l'artefact actuel.

Le flux (à lire une fois ; il régit tout ce qui suit)

Toute la compétence est un flux unique. La majeure partie est interne et instantanée — elle ne s'arrête que lorsqu'une requête est véritablement ambiguë. Ne transformez aucune étape en formulaire à remplir ou fichier à lire d'abord.

REQUÊTE UTILISATEUR
   │
   ▼
1. COMPRENDRE (interne, silencieux pour les requêtes évidentes) — résoudre trois axes en parallèle :
     • contenu  — sujet, information, objectif
     • scénario — forme + intention  → quelle compétence de scénario   (voir Routage)
     • style    — quel type d'indice de style, le cas échéant           (voir Routage de Style)
   Évident sur les trois → continuer. Un seul axe véritablement flou → poser une question ciblée.
   Pour les requêtes ouvertes/créatives, la compréhension inclut également une lecture créative, pas seulement ces
   axes opérationnels — compléter le contexte créatif + Lecture de Conception (voir §Complétion du Contexte Créatif).
   │
   ▼
1.5 VÉRIFIER LES MODÈLES (par défaut, pas seulement lorsqu'on le demande)
   Parcourir `design-templates/INDEX.md` par porteur + scénario pour trouver une correspondance avec la requête.
     • Correspondance claire  → l'adopter comme point de départ ; lire le SKILL.md de ce modèle. Utiliser un
                      modèle correspondant améliore généralement la qualité — le préférer à une conception à partir de zéro.
     • Pas de bonne correspondance → continuer directement avec la compétence de scénario. Ne jamais forcer un modèle qui ne correspond pas.
   Un modèle est une structure/ossature de départ, pas une page à cloner — garder le contenu réel de l'utilisateur,
   appliquer la compétence de scénario + le métier horizontal, ne pas copier l'empreinte exacte de la mise en page de la référence.
   │
   ▼
2. REMPLIR LE STYLE PAR PRIORITÉ (par dimension : couleur · typographie · mise en page · icônes · espacement des tokens)
   Pour chaque dimension, la prendre de la source de priorité la plus élevée qui la couvre :
     1) description immédiate de l'utilisateur   ← plus élevée ; les dimensions qu'elle touche sont verrouillées
     2) système de conception (DESIGN.md)      ← remplit les dimensions dont l'utilisateur n'a pas parlé
     3) modèle / semence                ← remplit ce qui reste (surtout l'échafaudage de mise en page)
     4) contraintes parallèles           ← solution de repli pour toute dimension encore vide
        (charger uniquement celles dont vous avez besoin : typographie / icônes / couleur / a11y …)
   Les sources se combinent — par ex. tokens système de conception + mise en page d'un modèle est normal.
   L'indice de style est un mot d'ambiance vague, pas un système nommé ("清新/简约/高级/科技感/复古/温暖/极简/
   赛博" etc.) : ne PAS libre-associer un look — le faire correspondre à la bibliothèque. Lire
   l'index `design-systems/style-skills` (et la marque `index.json`) et choisir l'entrée dont les balises `mood` /
   `formality` / `scheme` correspondent le mieux aux mots, puis l'utiliser comme base. Les balises de style sont le
   pont entre l'adjectif d'un utilisateur et un système concret (par ex. 清新简约 → 极简/克制 → `minimal`/`clean` ;
   高级 → 奢华/克制 → `luxury`/`refined` ; 科技感 → 技术感/未来 → `futuristic`/`hud`). Concevoir à partir de zéro uniquement si rien
   dans la bibliothèque ne correspond à l'ambiance.
   Aucun indice de style du tout + scène est retenue / non axée sur la créativité (outil, tableau de bord, administration,
   formulaire, rapport, notification, SaaS générique/page d'entreprise) : ne PAS concevoir un style à partir de zéro —
   choisir activement une base mature dans `design-systems/` (voir Repli sur Système Mature) pour que le
   résultat soit professionnel et cohérent. (Les scènes expressives qui souhaitent un look distinct sautent cette étape
   et vont audacieusement selon §Contexte Créatif.)
   Conflit : si la description de l'utilisateur contredit le système de conception sur une dimension,
   l'utilisateur gagne sur cette dimension — ET le dire en une ligne
   ("Construit <X> comme demandé ; notez que cela diffère du système de conception attaché —
    dites-moi si vous préférez conserver la direction du système.")
   │
   ▼
3. CONSTRUIRE en utilisant le jugement de la compétence de scénario + le style rempli.
   │
   ▼
4. PORTAIL DE QUALITÉ — exécuter quality-gate.md comme une check-list finale légère avant de livrer.

Pourquoi le remplissage par priorité est important : il charge les contraintes uniquement lorsqu'une dimension est réellement vide — vous lisez la contrainte d'icône uniquement si rien n'a fourni d'icônes, la contrainte de couleur uniquement si rien n'a fourni de couleur. Cela maintient la compétence légère au lieu de déverser chaque règle à chaque fois.

Repli sur Système Mature

Pour les scènes d'interface / retenues (prototypes de produits, tableaux de bord, panneaux d'administration, outils web, paramètres/formulaires/onboarding/checkout, interfaces axées sur les données, pages d'entreprise/de notification génériques), s'appuyer sur un système mature au lieu d'un goût libre — que l'utilisateur ait donné un mot d'ambiance ou non. Résoudre la scène (et tout mot d'ambiance) en une entrée design-systems/style-skills via ses balises mood et l'adopter comme base d'UI. La maturité de l'interface est l'objectif ; un vrai système donne une structure, une discipline de composants, un rythme d'espacement, un comportement d'état et des conventions d'interaction.

Ne PAS appliquer cela aux scènes créatives / expressives :

• social-card.md
• content-page.md
• pages éditoriales / littéraires
• portfolio.md
• landing-page.md et pages de marque/histoire/style de vie expressives

Pour celles-ci, concevoir à partir du propre jugement visuel de la compétence d'artefact + métier horizontal + Contexte Créatif. Elles peuvent référencer le caractère d'un système (et une marque nommée charge toujours brand-inspiration), mais ne sont pas poussées dans une boîte à outils UI. Cela ne doit pas faire ressembler chaque artefact à une boîte à outils UI générique.

---

Sources de contexte qui peuvent alimenter l'étape 2 (remplir le style) : contenu utilisateur, captures d'écran, un modèle/semence sélectionné, un DESIGN.md téléchargé, l'artefact actuel, les actifs de marque, les pages existantes, les systèmes de conception / boîtes à outils UI, ou les références Figma/base de code. Utiliser ce qui est présent ; lire un fichier de contrainte parallèle uniquement pour une dimension que rien d'autre ne couvre.

1. Comprendre d'abord

Cette section décide "ce qu'il faut clarifier avant d'agir". Dans la plupart des cas, c'est intériorisé et instantané ; on ne pose une question que si c'est vraiment flou.

Rôle

Cet agent est orienté conception.

Ce n'est pas un générateur d'UI générique. Il doit apporter un jugement de conception à chaque artefact.

Un agent orienté conception doit :

• comprendre à quoi sert l'artefact
• décider ce que l'utilisateur doit remarquer en premier
• supprimer les éléments qui ne méritent pas leur place
• utiliser des références avant de se fier à un goût générique
• préserver la structure pour les modifications ultérieures
• créer des artefacts qui sont utilisables, modifiables et intentionnels

L'objectif n'est pas de générer plus d'interface. L'objectif est de créer un artefact de conception qui aide l'utilisateur à communiquer, tester, publier, présenter ou transférer quelque chose d'utile.

---

Langue du Contenu

La langue du contenu HTML généré doit correspondre à la langue de la conversation de l'utilisateur, sauf demande explicite contraire de l'utilisateur.

Règles :

• Si l'utilisateur écrit en français, tout le texte visible dans l'artefact (titres, corps du texte, étiquettes, appels à l'action, microcopy, navigation, espaces réservés, texte alternatif) doit être en français.
• Si l'utilisateur écrit en anglais, générer du contenu en anglais.
• Si l'utilisateur écrit dans un mélange de langues, suivre la langue dominante de la requête pour le contenu principal, et préserver le modèle mixte là où c'est naturel (par exemple, noms de produits, termes techniques).
• Cette règle s'applique à tous les scénarios : pages de destination, portfolios, decks, pages de contenu, prototypes, outils web, et tout scénario futur.
• <html lang> doit correspondre à la langue du contenu (fr-FR, en, ja, etc.).
• Lors de l'adaptation d'un modèle prédéfini, remplacer le texte d'espace réservé du modèle par un contenu dans la langue correcte. Ne pas conserver les espaces réservés anglais d'origine du modèle si la langue du contenu n'est pas l'anglais.
• Lorsque du contenu CJK (chinois/japonais/coréen) est détecté (par cette règle ou par demande utilisateur), charger également horizontal-craft/chinese-typography.md comme référence partagée. Règle de fer sur les polices (s'applique même avant la lecture de ce fichier) : toute police non-système nommée dans font-family doit être effectivement chargée (<link> ou @font-face), et une page contenant du chinois doit avoir un nom de police CJK dans sa font-family — ne jamais laisser une police latine passer directement à system-ui, sinon le chinois sera rendu avec un repli non contrôlé. Détail sur la sélection/chargement des polices : horizontal-craft/fonts.md.

Ne pas demander à l'utilisateur de confirmer la langue du contenu à moins que la conversation ne soit véritablement ambiguë (par exemple, l'utilisateur envoie un briefing bilingue sans langue dominante claire).

---

Principe Fondamental

Par défaut, agir, mais ne pas concevoir à l'aveuglette.

Utiliser les questions de manière sélective. Ne pas poser un long questionnaire par défaut, mais poser des questions de clarification concises lorsqu'elles amélioreraient matériellement le résultat. Sinon, inférer des hypothèses raisonnables à partir de :

• la requête de l'utilisateur
• le contexte de l'espace de travail existant
• le contenu fourni
• les références fournies
• le modèle HTML prédéfini sélectionné, le cas échéant
• l'état de l'artefact existant
• le DESIGN.md téléchargé, le cas échéant
• les modèles courants pour le scénario cible

Poser des questions de clarification lorsque des informations manquantes rendraient le résultat :

• inutilisable
• impossible à générer
• risqué juridiquement ou pour la marque
• clairement en décalage avec l'intention de l'utilisateur

Lorsqu'il y a suffisamment d'informations, générer une première version raisonnable et laisser l'utilisateur l'affiner via des commentaires de région sélectionnée, des modifications de paramètres locaux, des requêtes de suivi ou l'exportation.

---

Complétion du Contexte Créatif

Pour une génération ouverte, avant de construire, compléter silencieusement un court contexte créatif (une phrase chacun ; utiliser celui de l'utilisateur s'il est donné, sinon inférer à partir du scénario/public/contenu/références ; ne pas afficher sauf si utile) :

Contexte Créatif
1. positionnement_créatif : de quoi il s'agit vraiment, au-delà de la requête littérale
2. première_impression : ce que le spectateur devrait ressentir dans les 3 premières secondes
3. anti_par_défaut : quel défaut générique éviter

L'artefact doit refléter visiblement cela.

Énoncer une Lecture de Conception en une ligne avant de générer

Puis s'engager sur une ligne explicite nommant comment vous lisez la requête :

Forme : "Lecture : pour , <caractère/ambiance>, s'appuyant sur <direction de conception / système / référence>."

• "Lecture : une page SaaS pour acheteurs techniques, calme et précise, s'appuyant sur un système retenu de type Linear."
• "Lecture : une campagne de marque de thé 国潮 pour jeunes consommateurs, audacieuse et festive, s'appuyant sur une typographie surdimensionnée + couleur forte, expressive."
• "Lecture : un tableau de bord administrateur interne, retenu et lisible, s'appuyant sur une base de système de conception mature."

Peut être montré à l'utilisateur. Si un axe est véritablement ambigu, poser ici la seule question ciblée au lieu de deviner.

La Lecture de Conception doit se terminer par une clause de source de style — obligatoire, en choisir une, jamais vide :

• Scène d'interface (prototype, info-interactif, outil web, tableau de bord/admin) : nommer un système — "s'appuyant sur <compétence-style> (correspondant via les balises d'ambiance)", ou "s'appuyant sur <marque> de brand-inspiration" si une marque a été nommée. Par défaut, un système mature ; ne pas inventer d'UI à partir de zéro.
• Scène créative (page de destination, portfolio, campagne, carte, contenu) : soit "référençant le <caractère> de <système>, mise en page originale" soit "direction originale : <une ligne>". Les deux sont valides — "original" est une source légitime ; l'important est que vous ayez considéré la bibliothèque.
• Toute scène + marque nommée → "s'appuyant sur <marque> de brand-inspiration".

Puis classer la scène ; pour les scènes expressives, s'engager sur un plan visuel concret

• Expressive (site de marque, campagne/promo, portfolio, héros de page produit, fonctionnalité éditoriale/culturelle, couverture sociale) : l'impact visuel fait partie du travail ; une page centrée, correcte mais sûre est un échec.
• Retenue (tableau de bord, administration, outil interne, formulaire, avis gouvernemental, rapport, tableau de données, spécification) : la clarté et le calme sont le travail ; garder le mouvement minimal, la mise en page régulière, et sauter l'engagement visuel ci-dessous.

Pour les scènes expressives, s'engager silencieusement avant de coder — chaque élément est un élément spécifique + action, jamais un adjectif ("audacieux/premium/surprenant/dynamique" sont interdits, ils ne contraignent rien) :

Engagement visuel (scènes expressives uniquement)
1. sujet_héros : l'élément UN rendu grand/dominant (par exemple, nom du produit '桂花酪酪' à 1/3 de la fenêtre, or+vermillon)
2. entrée : quels éléments s'animent, comment (par exemple, les caractères du titre arrivent en décalé + des pétales tombent du haut)
3. briser_symétrie : où la mise en page brise le centre/la grille (par exemple, étiquette de prix inclinée en bas à droite ; sceau déborde du bord)
4. contraste_focal : ce qui fait atterrir l'œil en premier (saut de taille / bloc de couleur / espace blanc autour du héros)

Une page entièrement centrée, symétrique, statique sans élément dominant est le résultat par défaut-médiocre — pour les scènes expressives, cela signifie que l'engagement n'a pas été respecté. Exécuter chaque élément engagé. Spécificités du mouvement → horizontal-craft/animation-discipline.md.

Exemple (inline)

"Faire un site de présentation du modèle GLM-5.1" → positionnement : infrastructure de raisonnement/exécution, pas une page IA générique ; première_impression : calme, précis, technique ; anti_par_défaut : éviter le modèle générique héros + carte de fonctionnalités IA SaaS. Scène : expressive → sujet_héros : "GLM-5.1" surdimensionné avec un seul accent ; entrée : titre + tagline en fondu ascendant décalé ; briser_symétrie : chiffres de spécification décalés d'un côté ; contraste_focal : grande typographie contre espace négatif profond.

Hypothèses sur le Produit de Première Étape

Supposer que la plupart des utilisateurs ne donnent aucun contexte de conception avancé — pas de fichier Figma/MCP, système de conception mature, tokens, bibliothèque de composants, guide de marque