Compétence de Conception
Design Skill est le routeur pour les travaux d'artefacts HTML liés à la conception.
Il décide :
- si la tâche est liée à la conception
- quelle compétence d'artefact doit être prioritaire
- 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
Design Skill doit rester léger.
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 réside dans cette compétence de scénario. Les règles de fabrication transversales appartiennent à horizontal-craft/.
La sélection de référence appartient à design-system-reference.md.
L'importation / extraction / persistance de DESIGN.md appartient à design-system-generation.md.
L'exportation / empaquetage / transfert 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 une spécification de système de design. L'exportation est invoquée lorsque l'utilisateur demande d'empaqueter, 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 seul flux. La majeure partie est interne et instantanée — elle ne s'arrête que lorsqu'une requête est vraiment 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 → procéder. 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 Conception (voir §Complétion du Contexte Créatif).
│
▼
1.5 VÉRIFIER LES MODÈLES (à faire par défaut, pas seulement quand demandé)
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 améliore généralement la qualité — le préférer à une conception de zéro.
• Pas de bonne correspondance → procéder 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 — garder le vrai contenu de l'utilisateur,
appliquer la compétence de scénario + la fabrication transversale, 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 · 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 / amorce ← 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 / accessibilité …)
Les sources se combinent — par exemple, des jetons de système de design + la mise en page d'un modèle est normal.
Un indice de style est un mot d'ambiance vague, pas un système nommé ("清新/简约/高级/科技感/复古/温暖/极简/
赛博" etc.) : ne PAS simplement associer librement 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 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 est sobre / non axée sur la créativité (outil, tableau de bord, administration,
formulaire, rapport, avis, page SaaS générique / entreprise) : ne PAS concevoir un style 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 veulent 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 design sur une dimension,
l'utilisateur gagne sur cette dimension — ET le dire en une ligne
("Construit <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 mince liste de contrôle finale 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 sur Système Mature
Pour les scènes d'interface / sobres (prototypes de produits, tableaux de bord, panneaux d'administration, outils web, paramètres/formulaires/onboarding/paiement, interfaces riches en données, pages génériques d'entreprise/avis), 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) vers une entrée design-systems/style-skills via ses balises mood et l'adopter 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.
Ne PAS appliquer cela aux scènes créatives / expressives :
social-card.mdcontent-page.md- pages éditoriales / littéraires
portfolio.mdlanding-page.mdet pages expressives de marque / histoire / style de vie
Pour celles-ci, concevoir à partir du propre jugement visuel de la compétence d'artefact + fabrication transversale + 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 devrait 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/amorce sélectionné, un DESIGN.md téléchargé, l'artefact actuel, les assets de marque, les pages existantes,
les systèmes de design / kits 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". La plupart du temps, c'est internalisé et instantané ; ce n'est que lorsque c'est vraiment flou qu'on pose une question.
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
- retirer les éléments qui ne méritent pas leur place
- utiliser des références avant de se fier au 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 sa part.
Règles :
- Si l'utilisateur écrit en chinois, tout le texte visible dans l'artefact (titres, corps de texte, étiquettes, appels à l'action, microcopie, navigation, placeholders, texte alternatif) doit être en chinois.
- Si l'utilisateur écrit en anglais, générer un 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 conserver 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, remplacer le texte factice du modèle par un contenu dans la langue correcte. Ne pas conserver les espaces réservés originaux en anglais du modèle si la langue du contenu n'est pas l'anglais.
- Lorsque du chinois / CJK est détecté (par cette règle ou par demande de l'utilisateur), charger également
horizontal-craft/chinese-typography.mdcomme référence partagée. Règle de fer des polices (s'applique même avant la lecture de ce fichier) : toute police non système nommée dansfont-familydoit être effectivement chargée (<link>ou@font-face), et une page contenant du chinois doit avoir un nom de police CJK dans sonfont-family— ne jamais laisser une police latine passer directement àsystem-ui, sinon le chinois s'affiche avec un repli incontrôlé. Détail de 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 vraiment ambiguë (par exemple, l'utilisateur envoie un briefing bilingue sans langue dominante claire).
Principe Fondamental
Agir par défaut, mais ne pas concevoir aveuglément.
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 sensiblement le résultat. Sinon, déduire des hypothèses raisonnables à partir :
- de la requête 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
DESIGN.mdtéléchargé, le cas échéant - des motifs courants pour le scénario cible
Poser des questions de clarification lorsque l'information manquante rendrait le résultat :
- inutilisable
- impossible à générer
- risqué sur le plan juridique ou de la marque
- clairement en décalage avec l'intention de l'utilisateur
Lorsque suffisamment d'informations existent, générer une première version raisonnable et laisser l'utilisateur l'affiner via des commentaires sur des régions sélectionnées, des modifications de paramètres locales, des demandes de suivi, ou une 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/audience/contenu/références ; ne pas afficher sauf si utile) :
Contexte Créatif
1. positionnement_créatif : ce que cela signifie 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 d'une ligne avant de générer
Puis s'engager sur une ligne explicite nommant comment la requête est comprise :
Forme : "Lecture : pour , <caractère/ambiance>, penchant <direction de conception / système / référence>."
- "Lecture : une page d'atterrissage SaaS pour des acheteurs techniques, calme et précise, penchant un système style Linear sobre."
- "Lecture : une campagne de marque de thé 国潮 pour des jeunes consommateurs, audacieuse et festive, penchant typographie surdimensionnée + couleur forte, expressive."
- "Lecture : un tableau de bord admin interne, sobre et lisible, penchant une base de système de design 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 — requis, en choisir une, jamais vide :
- Scène d'interface (prototype, info-interactif, outil web, tableau de bord/admin) : nommer un système —
"penchant <style-skill> (correspondant aux balises d'ambiance)", ou"penchant <marque> depuis brand-inspiration"si une marque a été nommée. Par défaut, s'appuyer sur un système mature ; ne pas inventer d'interface de zéro. - Scène créative (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 →
"penchant <marque> depuis brand-inspiration".
Puis classifier la scène ; pour les scènes expressives, s'engager sur un plan visuel concret
- Expressive (site de marque, campagne/promo, portfolio, hero de page produit, feature é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, 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 une action spécifique + élément, jamais un adjectif ("audacieux/premium/surprenant/dynamique" sont interdits, ils ne contraignent rien) :
Engagement visuel (scènes expressives uniquement)
1. sujet_hero : l'ÉLÉMENT rendu grand/dominant (ex. nom du produit '桂花酪酪' à 1/3 de la fenêtre, or+cinabre)
2. entrée : quels éléments s'animent, comment (ex. les caractères du titre arrivent en décalé + pétales tombent du haut)
3. briser_symétrie : où la mise en page casse le centre/grille (ex. étiquette de prix inclinée en bas à droite ; 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 hero)
Une page complètement 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é. Détails du mouvement → horizontal-craft/animation-discipline.md.
Exemple (en ligne)
"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 IA-SaaS + carte de fonctionnalité. Scène : expressive → sujet_hero : "GLM-5.1" surdimensionné avec un seul accent ; entrée : titre + slogan fondu ascendant en décalé ; briser_symétrie : chiffres de spécification décalés d'un côté ; contraste_focal : grande typographie contre un espace négatif profond.
Hypothèses du Produit de Première Étape
Supposer que la plupart des utilisateurs ne donnent pas de contexte de conception avancé — pas de fichier Figma/MCP, système de design mature, jetons, bibliothèque de composants, guide de marque
...
[le reste est tronqué pour la traduction]