antilsabh789-pixel/kabaddi-pro

Compétence Design

La compétence Design est le routeur pour le travail sur les 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 demande 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 Design 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 réside dans la compétence de ce scénario. Les règles de savoir-faire transversales appartiennent à horizontal-craft/. La sélection des références appartient à design-system-reference.md. L'importation / extraction / persistance de DESIGN.md appartient à design-system-generation.md. L'exportation / 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 diaporama, un paquet ou une spécification de système de design. L'exportation est invoquée lorsque l'utilisateur demande à empaqueter, télécharger, convertir ou remettre l'artefact actuel.

Le flux (lisez-le 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 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 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 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 design (voir §Complétion du contexte créatif).
   │
   ▼
1.5 VÉRIFIER LES MODÈLES (faites-le par défaut, pas seulement lorsqu'on vous le demande)
   Parcourir `design-templates/INDEX.md` par support + scénario pour trouver 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é — préférez-le à une conception de zéro.
     • Pas de bonne correspondance → procéder directement avec la compétence de scénario. Ne forcez jamais un modèle qui ne correspond pas.
   Un modèle est une structure/ossature de départ, pas une page à cloner — gardez le contenu réel de l'utilisateur, appliquez la compétence de scénario + le savoir-faire horizontal, ne copiez pas 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 des blocs)
   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 auxquelles l'utilisateur n'a pas fait référence
     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 nécessaires : typographie / icônes / couleur / accessibilité…)
   Les sources se combinent — par ex., les blocs du système de design + une mise en page de modèle sont normaux.
   Un indice de style est un mot d'ambiance vague, pas un système nommé («清新/简约/高级/科技感/复古/温暖/极简/
   赛博» etc.) : ne PAS simplement associer librement un aspect — le faire correspondre à la bibliothèque. Lire
   `design-systems/style-skills` index (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 de l'utilisateur et un système concret (par ex. 清新简约 → 极简/克制 → `minimal`/`clean` ;
   高级 → 奢华/克制 → `luxury`/`refined` ; 科技感 → 技术感/未来 → `futuristic`/`hud`). Ne concevoir
   à partir de zéro que 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, avis, 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 un système mature) pour que le
   résultat soit professionnel et cohérent. (Les scènes expressives qui veulent un aspect distinct sautent cette étape
   et optent pour l'audace 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 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 vider toutes les règles à chaque fois.

Repli sur un 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/paiement, interfaces à forte densité de données, pages d'entreprise/génériques/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 de design-systems/style-skills via ses balises mood et l'adopter comme base UI. La maturité de l'interface est l'objectif ; un vrai système apporte structure, discipline de composant, 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 propre jugement visuel 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'aspect 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 actifs de marque, les pages existantes, les systèmes de design / kits UI, ou les 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

Ceci détermine « ce qu'il faut comprendre avant de faire quoi que ce soit ». Dans la plupart des cas, c'est intériorisé 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 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 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 si l'utilisateur demande explicitement autre chose.

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, espaces réservés, texte alternatif) doit être en chinois.
• Si l'utilisateur écrit en anglais, générer du contenu en anglais.
• Si l'utilisateur écrit dans une langue mixte, suivre la langue dominante de la demande pour le contenu principal, et préserver le modèle mixte là où c'est naturel (par ex., noms de produits, termes techniques).
• Cette règle s'applique à tous les scénarios : pages d'atterrissage, portfolios, diaporamas, 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 du contenu dans la bonne langue. 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 le contenu chinois / CJK est détecté (par cette règle ou par demande de l'utilisateur), charger également horizontal-craft/chinese-typography.md comme référence partagée. Règle absolue de police (s'applique même avant de lire 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 sur system-ui, sinon le chinois s'affiche dans un fallback non contrôlé. Détail de sélection/chargement de police : horizontal-craft/fonts.md.

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

---

Principe fondamental

Par défaut, passer à l'action, 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 matériellement le résultat. Sinon, déduire des hypothèses raisonnables à partir de :

• la demande 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 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
• risqué juridiquement ou pour la marque
• clairement désaligné avec l'intention de l'utilisateur

Lorsqu'il y a suffisamment d'informations, générez une première version raisonnable et laissez l'utilisateur l'affiner via des commentaires de 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/audience/contenu/références ; ne pas montrer à moins que ce soit 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_defaut :              quel défaut générique éviter

L'artefact doit refléter visiblement ceci.

Énoncer une ligne de Lecture de Design avant de générer

Ensuite, s'engager sur une ligne explicite nommant comment vous lisez la demande :

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

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

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

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

• Scène d'interface (prototype, info-interactive, outil web, tableau de bord/administration) : nommer un système — « s'appuyant sur <compétence de style> (correspondance depuis les balises d'ambiance) », ou « s'appuyant sur de brand-inspiration » si une marque a été nommée. Par défaut, s'appuyer sur un système mature ; ne pas inventer l'UI 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 : ». Les deux sont valides — « originale » est une source légitime ; le but est que vous ayez envisagé la bibliothèque.
• Toute scène + marque nommée → « s'appuyant sur de brand-inspiration ».

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

• Expressive (site de marque, campagne/promotion, portfolio, héros de page d'atterrissage de 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 un élément + action spécifiques, 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 ex., nom du produit '桂花酪酪' à 1/3 de la fenêtre, or+cinabre)
2. entrée :       quels éléments s'animent, comment       (par ex., caractères du titre décalés + pétales tombant du haut)
3. briser_symétrie : où la mise en page casse le centre/la grille      (par ex., étiquette de prix inclinée en bas à droite ; sceau débordant 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é honoré. 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_defaut : é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 + accroche décalés en fondu ; briser_symétrie : chiffres de spécification décalés d'un côté ; contraste_focal : grande typographie sur un espace négatif profond.

Hypothèses du produit de première étape

Supposer que la plupart des utilisateurs ne fournissent aucun contexte de design avancé — pas un fichier Figma/MCP, un système de design mature, des blocs, une bibliothèque de composants, une charte graphique

…

[tronqué pour la traduction]