Conception (acheminement)

Compétence de conception (acheminement)

La compétence de conception est le routeur pour le 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 demande avant l'acheminement (voir « Avant de générer »)
• comment appliquer les paramètres par défaut de qualité de conception intégrés
• 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 propres à chaque artefact appartiennent aux fichiers de compétence d'artefact. Le jugement métier pour un scénario donné réside dans cette compétence de scénario. Les règles transversales de savoir-faire appartiennent à horizontal-craft/. La sélection des références appartient à design-system-reference.md. L'import/export/la persistance de DESIGN.md appartient à design-system-generation.md. L'export/le package/la remise appartient à export.md.

Le livrable par défaut de la première étape est un artefact de conception, 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 package ou un cahier des charges de système de conception. L'export est invoqué lorsque l'utilisateur demande à empaqueter, télécharger, convertir ou remettre 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 demande est vraiment ambiguë. Ne transformez aucune étape en formulaire à remplir ou en fichier à lire d'abord.

DEMANDE UTILISATEUR
   │
   ▼
1. COMPRENDRE (interne, silencieux pour les demandes évidentes) — résoudre trois axes en parallèle :
     • contenu  — sujet, information, objectif
     • scénario — forme + intention  → quelle compétence de scénario (voir Acheminement)
     • style    — quel type d'indice de style, le cas échéant (voir Acheminement du style)
   Évident sur les trois → poursuivre. Un SEUL axe vraiment ambigu → poser une question ciblée.
   Pour les demandes 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 vecteur + scénario pour une correspondance avec la demande.
     • 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 de zéro.
     • Aucune bonne correspondance → poursuivre directement avec la compétence de scénario. Ne jamais forcer un modèle qui ne convient pas.
   Un modèle est une structure/squelette de départ, pas une page à cloner — conserver le contenu réel de l'utilisateur, appliquer la compétence de scénario + le savoir-faire horizontal, ne pas copier l'empreinte de mise en page exacte de la référence.
   │
   ▼
2. REMPLIR LE STYLE PAR PRIORITÉ (par dimension : couleur · typographie · mise en page · icônes · espacement)
   Pour chaque dimension, la prendre à partir 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 conception (DESIGN.md)      ← remplit les dimensions dont l'utilisateur n'a pas parlé
     3) modèle / germe                ← remplit ce qui reste (en particulier 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 / accessibilité …)
   Les sources se combinent — par exemple, les jetons du système de conception + la mise en page d'un modèle sont normaux.
   L'indice de style est un mot d'ambiance vague, pas un système nommé («清新/简约/高级/科技感/复古/温暖/极简/赛博» etc.) : ne PAS associer librement un aspect — le faire correspondre à la bibliothèque. Lire l'index de `design-systems/style-skills` (et le `index.json` de la marque) 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 exemple, 清新简约 → 极简/克制 → `minimal`/`clean` ; 高级 → 奢华/克制 → `luxury`/`refined` ; 科技感 → 技术感/未来 → `futuristic`/`hud`). Ne concevoir de zéro que si rien dans la bibliothèque ne correspond à l'ambiance.
   Aucun indice de style du tout + scène sobre / non axée sur la créativité (outil, tableau de bord, administration, formulaire, rapport, avis, page SaaS/entreprise générique) : ne PAS concevoir un style de zéro — choisir activement une base mature dans `design-systems/` (voir Repli vers un système mature) pour que le résultat soit professionnel et cohérent. (Les scènes expressives qui veulent un aspect distinct ignorent cette règle et optent pour le style audacieux conformément au §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. PORTE DE 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 un 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 riches en données, pages corporatives/avis génériques), s'appuyer sur un système mature plutôt que sur 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 de design-systems/style-skills via ses balises mood et l'adopter comme base d'interface. La maturité de l'interface est l'objectif ; un vrai système apporte structure, discipline des composants, rythme d'espacement, comportement d'état et 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 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 d'interface utilisateur. Il ne faut pas que chaque artefact ressemble à un kit d'interface générique.

---

Sources de contexte qui peuvent alimenter l'étape 2 (remplir le style) : contenu utilisateur, captures d'écran, un modèle/germe sélectionné, un DESIGN.md téléchargé, l'artefact actuel, les ressources de marque, les pages existantes, les systèmes de conception / kits d'interface utilisateur, ou les références Figma/codebase. 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 « quoi comprendre avant d'agir ». Dans la plupart des cas, c'est internalisé et instantané ; on ne pose une question qu'en cas de véritable ambiguïté.

Rôle

Cet agent est orienté conception.

Ce n'est pas un générateur d'interface 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 justifient 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 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 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 sa part.

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érer un contenu en anglais.
• Si l'utilisateur écrit dans une langue mixte, suivre la langue dominante de la demande pour le contenu principal, et conserver 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 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, 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.
• Lorsqu'un contenu chinois / CJK est détecté (par cette règle ou par la demande de l'utilisateur), charger également horizontal-craft/chinese-typography.md comme référence partagée. Règle absolue des 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 tomber directement dans system-ui, sinon le chinois s'affiche avec une police de secours non contrôlée. Détails sur la sélection/chargement des polices : horizontal-craft/fonts.md.

Ne pas demander à l'utilisateur de confirmer la langue du contenu, sauf si la conversation est vraiment ambiguë (par exemple, l'utilisateur envoie un brief bilingue sans langue dominante claire).

---

Principe fondamental

Opter par défaut pour l'action, mais ne pas concevoir à l'aveugle.

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, déduire des hypothèses raisonnables à partir :

• de la demande de l'utilisateur
• du contexte de l'espace de travail existant
• du contenu fourni
• des références fournies
• du modèle HTML prédéfini sélectionné, le cas échéant
• de l'état de l'artefact existant
• du fichier DESIGN.md téléchargé, le cas échéant
• des 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
• juridiquement ou en termes de marque risqué
• clairement mal aligné 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 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éter silencieusement un court contexte créatif (une phrase chacun ; utiliser celui de l'utilisateur s'il est donné, sinon déduire du scénario/public/contenu/références ; ne pas montrer sauf si utile) :

Contexte créatif
1. positionnement_créatif :  de quoi il s'agit vraiment, au-delà de la demande littérale
2. première_impression :      ce que le spectateur doit 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

Ensuite, s'engager sur une ligne explicite nommant la façon dont vous lisez la demande :

Forme : « Lecture : pour , <caractère/ambiance>, penchant vers <direction de conception/système/référence>. »

• « Lecture : une page d'atterrissage SaaS pour des acheteurs techniques, calme et précise, penchant vers un système sobre de type Linear. »
• « Lecture : une campagne de marque de thé 国潮 pour les jeunes consommateurs, audacieuse et festive, penchant vers typographie surdimensionnée + couleur forte, expressive. »
• « Lecture : un tableau de bord d'administration interne, sobre et lisible, penchant vers une base de système de conception mature. »

Peut être montré à l'utilisateur. Si un axe est vraiment 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/administration) : nommer un système — « penchant vers <style-skill> (correspondant aux balises d'ambiance) », ou « penchant vers <marque> de brand-inspiration » si une marque a été nommée. Par défaut, un système mature ; ne pas inventer d'interface de zéro.
• Scène créative (page d'atterrissage, portfolio, campagne, carte, contenu) : soit « référençant <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 but est que vous avez envisagé la bibliothèque.
• Toute scène + marque nommée → « penchant vers <marque> de brand-inspiration ».

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

• Expressif (site de marque, campagne/promotion, portfolio, héros de page d'atterrissage produit, fonctionnalité éditoriale/culturelle, couverture sociale) : l'impact visuel fait partie du travail ; une page centrée correcte mais prudente est un échec.
• Sobre (tableau de bord, administration, outil interne, formulaire, avis gouvernemental, rapport, tableau de données, cahier des charges) : la clarté et le calme sont l'objectif ; garder les animations minimales, 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 + une action, jamais un adjectif (« audacieux/premium/surprenant/dynamique » sont interdits, ils ne contraignent rien) :

Engagement visuel (scènes expressives uniquement)
1. sujet_hero :   le SEUL élément rendu grand/dominant (par exemple, nom du produit '桂花酪酪' à 1/3 de la fenêtre, or+cinnabar)
2. entrée :       quels éléments s'animent, comment (par exemple, les caractères du titre apparaissent 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, l'étiquette de prix inclinée en bas à droite ; le sceau dépasse du bord)
4. contraste_focal : ce qui fait que l'œil se pose 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 par défaut le résultat banal — pour une scène expressive, cela signifie que l'engagement n'a pas été tenu. Exécuter chaque élément engagé. Détails des animations → horizontal-craft/animation-discipline.md.

Exemple (en ligne)

« 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écis, technique ; anti_par_défaut : éviter le modèle générique héros SaaS-IA + carte de fonctionnalités. Scène : expressive → sujet_hero : « GLM-5.1 » surdimensionné avec un seul accent ; entrée : titre + slogan avec fondu progressif décalé ; briser_symétrie : les chiffres spécifiques décalés d'un côté ; contraste_focal : grande typographie contre un 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, de système de conception mature, de jetons, de bibliothèque de composants, de directives de marque

… [tronqué pour la traduction]