ARYAN2302/liquid_researcher

Compétence Design

La compétence Design est le routeur pour le travail d'artefacts HTML liés au design.

Elle décide :

• si la tâche est liée au design
• 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 design intégrées
• comment garder le HTML généré structuré pour des modifications futures

La compétence Design doit rester légère.

Les règles de structure propres à un artefact appartiennent aux fichiers de compétence d'artefact. Le jugement métier pour un scénario vit dans cette compétence de scénario. Les règles transversales de savoir-faire appartiennent à horizontal-craft/. La sélection de référence appartient à design-system-reference.md. L'import / extraction / persistance de DESIGN.md appartient à design-system-generation.md. L'export / paquet / remise appartient à export.md.

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

Le flux (lisez ceci une fois ; cela régit tout ce qui suit)

Toute la compétence est un seul flux. La majeure partie est interne et instantanée — elle ne fait une pause que lorsqu'une requête est véritablement ambiguë. Ne transformez aucune étape en formulaire à remplir ou en 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 vraiment 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 Design (voir §Complétion du Contexte Créatif).
   │
   ▼
1.5 VÉRIFIER LES MODÈLES (par défaut, pas seulement lorsqu'on vous le demande)
   Parcourir `design-templates/INDEX.md` par porteur + scénario pour 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 élève généralement la qualité — préférez-le à une conception de zéro.
     • Aucune bonne correspondance → continuer directement avec la compétence de scénario. Ne forcez jamais un modèle qui ne correspond pas.
   Un modèle est une structure/squelette de départ, pas une page à cloner — conservez le contenu réel de l'utilisateur,
   appliquez la compétence de scénario + le savoir-faire horizontal, ne copiez pas 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 · espacements)
   Pour chaque dimension, la prendre de la source de priorité la plus élevée qui la couvre :
     1) description immédiate de l'utilisateur   ← la plus élevée ; les dimensions qu'elle touche sont verrouillées
     2) système de design (DESIGN.md)             ← remplit les dimensions dont l'utilisateur n'a pas parlé
     3) modèle / seed                            ← 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 exemple, des jetons de système de design + la 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 faites PAS une simple association libre d'un look — faites-le correspondre à la bibliothèque. Lisez
   l'index `design-systems/style-skills` (et le `index.json` de la marque) et choisissez l'entrée dont les balises `mood` /
   `formality` / `scheme` correspondent le mieux aux mots, puis utilisez-la comme base. Les balises de style sont le
   pont entre l'adjectif d'un utilisateur et un système concret (par ex. 清新简约 → minimaliste/discret → `minimal`/`clean` ;
   高级 → luxueux/discret → `luxury`/`refined` ; 科技感 → technologique/futuriste → `futuristic`/`hud`). Concevez
   seulement à partir de zéro si rien dans la bibliothèque ne correspond à l'ambiance.
   Aucun indice de style du tout + la scène est sobre / non axée sur la créativité (outil, tableau de bord, admin,
   formulaire, rapport, avis, page SaaS/corporate générique) : ne concevez PAS un style à partir de zéro —
   choisissez activement une base mature dans `design-systems/` (voir Repli vers Système Mature) pour que le
   résultat soit professionnel et cohérent. (Les scènes expressives qui veulent un look distinct ignorent cette règle
   et vont vers l'audace selon §Contexte Créatif.)
   Conflit : si la description de l'utilisateur contredit le système de design sur une dimension,
   l'utilisateur l'emporte sur cette dimension — ET dites-le en une ligne
   ("Construit en <X> comme vous l'avez demandé ; notez que cela diffère du système de design attaché —
    dites-moi si vous préférez garder la direction du système.")
   │
   ▼
3. CONSTRUIRE en utilisant le jugement de la compétence de scénario + le style rempli.
   │
   ▼
4. CONTRÔLE QUALITÉ — exécuter quality-gate.md comme une liste de contrôle 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ônes 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 toutes les règles à chaque fois.

Repli vers Système Mature

Pour les scènes d'interface / sobres (prototypes de produits, tableaux de bord, panneaux d'administration, outils web, paramètres/formulaires/intégration/paiement, interfaces axées sur les données, pages corporate/avis génériques), appuyez-vous sur un système mature plutôt que sur un goût libre — que l'utilisateur ait donné ou non un mot d'ambiance. Résolvez la scène (et tout mot d'ambiance) en une entrée design-systems/style-skills via ses balises mood et adoptez-la comme base UI. La maturité de l'interface est l'objectif ; un système réel donne une structure, une discipline de composants, un rythme d'espacement, un comportement d'état et des conventions d'interaction.

N'appliquez PAS cela aux scènes créatives / expressives :

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

Pour celles-ci, concevez à partir du jugement visuel propre de la compétence d'artefact + savoir-faire 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 un kit UI. Cela ne doit pas donner à chaque artefact l'apparence d'un kit UI générique.

---

Sources de contexte qui peuvent alimenter l'étape 2 (remplir le style) : contenu utilisateur, captures d'écran, un modèle/seed sélectionné, un DESIGN.md téléchargé, l'artefact actuel, actifs de marque, pages existantes, systèmes de design / kits UI, ou références Figma / codebase. Utilisez ce qui est présent ; lisez 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 internalisé et instantané ; on ne pose une question que si c'est vraiment ambigu.

Rôle

Cet agent est orienté design.

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

Un agent orienté design 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 des 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 design qui aide l'utilisateur à communiquer, tester, publier, présenter ou remettre quelque chose d'utile.

---

Langue du contenu

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

Règles :

• Si l'utilisateur écrit en chinois, tout le texte visible dans l'artefact (titres, corps de texte, étiquettes, CTA, microcopie, navigation, espaces réservés, texte alternatif) doit être en chinois.
• Si l'utilisateur écrit en anglais, générez un contenu en anglais.
• Si l'utilisateur écrit dans une langue mixte, suivez la langue dominante de la requête pour le contenu principal, et préservez le motif mixte là où c'est naturel (par exemple, noms de produits, termes techniques).
• Cette règle s'applique à tous les scénarios : pages d'atterrissage, portfolios, decks, pages de contenu, prototypes, outils web, et tout scénario futur.
• <html lang> doit correspondre à la langue du contenu (zh-CN, en, ja, etc.).
• Lors de l'adaptation d'un modèle prédéfini, remplacez le texte d'espace réservé du modèle par un contenu dans la langue correcte. Ne conservez pas les espaces réservés anglais originaux du modèle si la langue du contenu n'est pas l'anglais.
• Lorsqu'un contenu chinois / CJK est détecté (par cette règle ou par demande de l'utilisateur), chargez également horizontal-craft/chinese-typography.md comme référence partagée. Règle de fer pour 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 son font-family — ne laissez jamais une police latine tomber directement dans system-ui, sinon le chinois s'affiche dans un repli incontrôlé. Détail de la sélection/chargement des polices : horizontal-craft/fonts.md.

Ne demandez pas à l'utilisateur de confirmer la langue du contenu, sauf si la conversation est véritablement ambiguë (par exemple, l'utilisateur envoie un briefing bilingue sans langue dominante claire).

---

Principe fondamental

Par défaut, agissez, mais ne concevez pas aveuglément.

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

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

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

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

Lorsque suffisamment d'informations existent, générez une première version raisonnable et laissez l'utilisateur l'affiner via des commentaires sur une région sélectionnée, des modifications de paramètres locaux, des demandes de suivi, ou l'exportation.

---

Complétion du Contexte Créatif

Pour la génération ouverte, avant de construire, complétez silencieusement un court contexte créatif (une phrase chacun ; utilisez celui de l'utilisateur s'il est donné, sinon déduisez du scénario/audience/contenu/références ; ne montrez pas sauf si utile) :

Contexte Créatif
1. positionnement_créatif :  ce dont 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.

Énoncez une Lecture de Design en une ligne avant de générer

Engagez-vous ensuite sur une ligne explicite nommant comment vous lisez la requête :

Forme : « Lecture de ceci comme : pour , <caractère/ambiance>, s'appuyant sur <direction de design / système / référence>. »

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

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

La Lecture de Design doit se terminer par une clause de source de style — obligatoire, choisissez-en une, jamais vide :

• Scène d'interface (prototype, info-interactif, outil web, tableau de bord/admin) : nommez un système — « s'appuyant sur <style-skill> (correspondant aux balises de mood) », ou « s'appuyant sur <marque> de brand-inspiration » si une marque a été nommée. Par défaut, un système mature ; n'inventez pas d'UI de zéro.
• Scène créative (page d'atterrissage, 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 ; le point est que vous avez considéré la bibliothèque.
• Toute scène + marque nommée → « s'appuyant sur <marque> de brand-inspiration ».

Classez ensuite la scène ; pour les scènes expressives, engagez-vous 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.
• Sobre (tableau de bord, admin, outil interne, formulaire, avis gouvernemental, rapport, table de données, spécification) : la clarté et le calme sont le travail ; gardez le mouvement minimal, la mise en page régulière, et sautez l'engagement visuel ci-dessous.

Pour les scènes expressives, engagez-vous silencieusement avant de coder — chaque élément est un élément spécifique + une action, jamais un adjectif (« audacieux/élégant/surprenant/dynamique » sont interdits, ils ne contraignent rien) :

Engagement visuel (scènes expressives uniquement)
1. sujet_principal :   le SEUL élément rendu grand/dominant  (par ex. nom de produit '桂花酪酪' à 1/3 de la fenêtre, or+cinabre)
2. entrée :            quels éléments s'animent, comment       (par ex. les caractères du titre apparaissent en cascade + les pétales tombent du haut)
3. briser_symétrie :   où la mise en page casse le centre/grille (par ex. étiquette de prix inclinée en bas à droite ; sceau dépasse 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-平庸 — pour les scènes expressives, cela signifie que l'engagement n'a pas été honoré. Exécutez chaque élément engagé. Détails du mouvement → horizontal-craft/animation-discipline.md.

Exemple (intégré)

« Créer 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écise, technique ; anti_par_défaut : éviter le modèle générique héros IA-SaaS + carte de fonctionnalité. Scène : expressive → sujet_principal : « GLM-5.1 » surdimensionné avec un seul accent ; entrée : titre + slogan apparaissent en cascade estompée ; briser_symétrie : les numéros de spécification décalés d'un côté ; contraste_focal : grande typographie sur un espace négatif profond.

Hypothèses de produit de première étape

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

… [tronqué pour la traduction]