lwg-haibao-design

Page HTML de présentation style affiche

Concevoir des pages HTML uniques de type «affiche» pour des présentations/exposés, et extraire les règles de conception à partir d'images de design fournies par l'utilisateur. Deux workflows :

• Workflow A · Extraction : l'utilisateur fournit une ou plusieurs images de design graphique → analyser les couleurs, la composition, les polices, les décorations → les enregistrer dans references/rules.md selon le modèle.
• Workflow B · Génération : l'utilisateur donne des besoins (contenu + tonalité + proportions) → évaluer et sélectionner via references/selection.md → générer un HTML autonome aux proportions spécifiées → valider selon references/checklist.md.

Règle la plus importante : ne jamais inventer de mise en page. Les versions rejetées par l'utilisateur proviennent presque toutes d'une «invention personnelle d'un style». La bibliothèque contient 24 échantillons et 9 palettes de couleurs ; ce n'est que si aucun ne convient que l'on revient à baseline.md. Si l'utilisateur cite explicitement un numéro S ou C, l'appliquer directement.

Workflow A : Fournir des images de design, extraire des règles

Deux modes d'analyse :

• Analyse complète (par défaut) : analyser tous les champs selon le modèle, et enregistrer comme entrée d'échantillon (S-numéro).
• Analyse uniquement des couleurs : lorsque l'utilisateur précise «uniquement les couleurs» ou «analyser uniquement les couleurs», ou que l'image est clairement une carte de couleurs / une palette d'inspiration (blocs de couleur, nuancier), extraire uniquement la palette et définir l'attribution des rôles de couleur comme entrée de palette (C-numéro), en ignorant composition/polices/décoration.

1. Lire les images : utiliser un outil de visualisation (comme ViewImage) pour examiner chaque image une par une ; si le texte est trop petit ou les détails peu clairs, recadrer et agrandir par zone. Pour plusieurs images, toutes les examiner d'abord avant d'extraire. Analyser uniquement le design lui-même : ignorer les filigranes, les logos de plateforme/compte, et les barres d'état, barres de navigation inférieure, etc., qui font partie d'une capture d'écran de téléphone ; si la capture est tronquée ou déformée, déduire l'intention de conception originale à partir du sujet visible.
2. Analyser chaque image : suivre les champs de references/analysis-template.md (en mode couleurs uniquement, suivre les champs «mode couleurs uniquement» de ce fichier), en produisant des points de mise en œuvre directement réutilisables :
   • Couleurs : hex des couleurs principales/secondaires/d'accent/neutres, proportions de surface, rapport clair/foncé. Utiliser d'abord python3 scripts/extract_palette.py <chemin_image> pour obtenir des valeurs précises ; si Pillow manque ou si le script échoue, utiliser des valeurs approximatives à l'œil et noter «approximatif» dans l'entrée.
   • Composition : mode de division de la mise en page, position du point focal, proportions des blancs, grille, symétrie, hiérarchie de lecture.
   • Polices : style du titre, hiérarchie des tailles (pourcentage par rapport au petit côté du canevas), graisse, alignement, espacement des lettres.
   • Décoration et texture : éléments graphiques, textures, bordures, dégradés/bruit/blocs de couleur, etc.
   • Densité de contenu et proportions adaptées : quantité d'information adaptée et rapport hauteur/largeur.
   • Scénario d'application : à quel thème, quelle tonalité, ce design convient.
3. Extraire : ajouter les résultats de l'analyse comme une entrée dans references/rules.md — l'analyse complète comme entrée d'échantillon (S-numéro), l'analyse uniquement des couleurs comme entrée de palette (C-numéro), et les enregistrer tous dans la table des index (le numéro est celui de la ligne réservée à la fin de la table des index ; après utilisation, ajouter une nouvelle ligne réservée, voir les règles dans analysis-template.md). En cas de forte similarité avec une entrée existante, fusionner ou marquer comme variante, ne pas accumuler de doublons. Enregistrer également l'image originale dans references/samples/ (image unique S-XX.jpg, variante S-XXa.jpg / S-XXb.jpg) et mettre à jour le README de ce répertoire — sans l'image, les techniques qui expliquent «pourquoi c'est beau» peuvent être perdues (S-13 avait ainsi omis trois blocs blancs sur fond blanc, maintenant ajoutés).
4. Mettre à jour le tableau de sélection : dans references/selection.md, ajouter une ligne dans le tableau des étiquettes des échantillons (tonalité / clair/foncé / matériau / densité / élément signature / proportions adaptées) et ajouter le nouvel échantillon dans la section 4 «Matrice de compatibilité C × S» selon son caractère clair/foncé, sinon le nouvel échantillon est «invisible» lors de la sélection.
5. Rapport : informer l'utilisateur de la nouvelle règle ajoutée, pour quel scénario elle convient, afin qu'il puisse l'utiliser directement la prochaine fois.

Workflow B : Donner des besoins, générer la page

1. Analyser les besoins : sujet du contenu, tonalité émotionnelle (sérieux/neutre/dynamique/littéraire/frais), densité de contenu (phrase unique vs points clés vs données vs texte-image), proportions de la page spécifiées (n'importe quelle valeur), besoin éventuel de photos réelles.
2. Évaluation et sélection (ne pas sauter) : lire references/selection.md, effectuer un filtrage strict et une notation sur 5 dimensions, sélectionner les 3 premiers ; expliquer en une phrase pourquoi l'échantillon choisi est approprié (lien entre l'élément signature et la sémantique du contenu), puis passer à l'étape suivante. Ensuite, utiliser la section 4 «Matrice de compatibilité C × S» pour déterminer la palette de couleurs, remplir les 5 rôles (bg / text / mid / accent / decor) avec les valeurs hexadécimales. Après la sélection, consulter la liste des fichiers dans references/samples/README.md ; s'il y a une image originale correspondante, l'examiner (les noms des variantes sont S-XXa / S-XXb, ne pas deviner le chemin à partir de S-XX.jpg), puis commencer la mise en œuvre en comparant la forme réelle de l'élément signature. Ce n'est que si la bibliothèque est vide ou qu'aucun échantillon ne correspond qu'on utilise baseline.md.
3. Structurer le contenu : organiser le contenu de l'utilisateur en une structure de page unique de type affiche (titre principal, sous-titre, points clés, données, frise chronologique, etc.), avec une seule diapositive fermée, une hiérarchie claire, et un seul point focal.
4. Adapter les proportions : définir le canevas de la page selon les proportions spécifiées (méthode dans baseline.md section «Normes d'adaptation des proportions» et «Conventions d'unités») ; la taille des polices et l'espacement sont calculés par rapport au petit côté du canevas — déclarer .stage avec container-type:inline-size, utiliser cqw pour le mode portrait et cqh pour le mode paysage, un changement applique un zoom global.
5. Générer le HTML : la compétence html est une dépendance optionnelle d'enrichissement : si elle est installée, lire d'abord complètement son SKILL.md et references/design/frontend-design.md comme complément ; si elle n'est pas installée, passer directement, exécuter selon references/baseline.md (principes de design, hiérarchie des polices, adaptation des proportions, conventions d'unités) et references/checklist.md (12 points de validation), sans interrompre la livraison pour cette raison. Produire un fichier .html autonome : CSS/JS en ligne, nom de fichier sémantique (pas index.html), priorité mobile, pas de boutons zombies, pas d'emoji, avec favicon ; les ressources images utilisent des chemins relatifs locaux ou des URI de données, les images externes sont d'abord téléchargées localement. Avant de réviser, copier la version actuelle dans _backup/ (créer le répertoire avec mkdir -p s'il n'existe pas).
6. Validation : vérifier chaque point des 12 critères de references/checklist.md (calculer manuellement cqw / cqh → px), faire une capture d'écran du rendu si possible (texte débordant / éléments chevauchant le texte / contraste de surface). En cas d'échec, corriger, puis livrer (present_files avec files: [chemin absolu du HTML]). Dans la note de livraison, préciser la raison du choix, les paramètres modifiés et la méthode de vérification réelle.
7. Enregistrer les rejets : si l'utilisateur rejette une version, ajouter une ligne dans la section 5 de references/selection.md (échantillon/palette, mots exacts de l'utilisateur, diagnostic du problème), et éviter cette même combinaison lors des prochains choix.

Maintenance de la bibliothèque de règles

• references/rules.md : bibliothèque de règles incrémentale, actif principal de cette compétence. Chaque image fournie ajoute une entrée d'échantillon ; lors de la génération de pages, la sélection se fait prioritairement à partir de celle-ci. Avant de lire ses fragments CSS, consulter d'abord les «Conventions d'unités» en haut.
• references/selection.md : décideur de sélection. Étiquettes des échantillons sur 5 dimensions, règles de notation, matrice de compatibilité C×S (couvrant les 24 échantillons), 5 rôles de couleur, enregistrement des rejets. Tout nouvel échantillon doit synchroniser la table d'étiquettes et la matrice.
• references/checklist.md : liste de validation avant livraison. 12 critères vérifiables + 2 règles strictes.
• references/baseline.md : base commune. Solution de repli lorsque la bibliothèque de règles est vide ou ne correspond pas, contenant les principes de conception d'affiche, hiérarchie des polices, normes d'adaptation des proportions, conventions d'unités et interdictions.
• references/analysis-template.md : modèle de champs et règles de numérotation pour l'analyse des images fournies, à suivre lors de l'extraction des entrées.
• references/samples/ : archives des images originales et liste des fichiers.

Dépendances externes (optionnelles, ne bloquent pas)

1. Essentiel : scripts/extract_palette.py (dépend de Pillow). Si Pillow manque, revenir à l'évaluation visuelle des couleurs et noter «approximatif» dans l'entrée.
2. Optionnel : compétence html. Le répertoire racine de la compétence varie selon l'environnement (utilisateur local : ~/.workbuddy/skills/), utiliser Glob pour chercher **/html/SKILL.md ; si trouvé, lire successivement <html-skill>/SKILL.md et <html-skill>/references/design/frontend-design.md comme complément de conception. Le script de capture d'écran intégré (shot.py) n'existe généralement pas, ne pas insister.
3. Si la compétence html / le script de capture est introuvable : livrer et valider directement selon baseline.md + checklist.md, et préciser dans la note de livraison «aucune capture d'écran du rendu» ou la méthode de vérification alternative utilisée. Il est interdit d'interrompre le workflow B pour cause de compétence externe introuvable.