rizykdarm/ClusteringAIAgentsSkills-Python

Création de sites web

Créez des sites web distinctifs et de qualité production où chaque site a un aspect DIFFÉRENT. Chaque choix — police, couleur, animation, mise en page — doit découler du sujet. Exécutez le générateur de palette (bun run shared/generate-palette.ts "mots-clés") pour créer une palette unique pour chaque projet. NE réutilisez JAMAIS la même palette d'un site à l'autre.

Ce skill couvre tout ce qui concerne les projets web. Lisez les sous-fichiers de ce répertoire selon les besoins de votre type de projet. Pour les applications web, lisez également skills/GENERAL-KNOWLEDGE-WORKER/website-building/webapp/SKILL.md.

Les principes de design universels (philosophie des couleurs, palette par défaut, sélection des polices) sont partagés avec d'autres skills via design-foundations. Les fichiers partagés de ce skill étendent ces fondations avec des implémentations spécifiques au web (variables CSS, tokens responsifs, feuilles de style de base). Vous n'avez pas besoin de charger design-foundations séparément — les versions web dans shared/ sont complètes.

Utilisez read avec le chemin complet, ex. skills/GENERAL-KNOWLEDGE-WORKER/website-building/shared/01-design-tokens.md

---

Routage par type de projet

Étape 1 : Identifiez le type de projet et chargez les directives spécifiques :

Type de projet	Action	Exemples
Sites informatifs	read skills/GENERAL-KNOWLEDGE-WORKER/website-building/informational/informational.md	Sites personnels, portfolios, éditoriaux/blogs, petites entreprises, pages d'atterrissage
Applications web	read skills/GENERAL-KNOWLEDGE-WORKER/website-building/webapp/SKILL.md	SaaS, tableaux de bord, panneaux d'administration, e-commerce, expériences de marque
Jeux dans le navigateur	read skills/GENERAL-KNOWLEDGE-WORKER/website-building/game/game.md + skills/GENERAL-KNOWLEDGE-WORKER/website-building/game/game-testing.md	Jeux 2D Canvas, Three.js/WebGL, jeux HTML5, expériences 3D interactives

Étape 2 : Lisez les fichiers partagés — lisez skills/GENERAL-KNOWLEDGE-WORKER/website-building/shared/01-design-tokens.md et skills/GENERAL-KNOWLEDGE-WORKER/website-building/shared/02-typography.md en premier (obligatoire pour TOUS les types de projet, y compris les applications web). Ils établissent les valeurs par défaut du système de design Kortix et les règles de typographie qui s'appliquent universellement. Pour les applications web et les tableaux de bord, ignorez les fichiers marqués de † ci-dessous — ils contiennent des détails d'implémentation préconfigurés dans le template fullstack.

Si l'utilisateur dit simplement « site web » ou « site » sans détail, demandez le type ou optez par défaut pour un site informatif.

---

Référence des sous-fichiers

Fichiers partagés (shared/) — Chaque projet

Fichier	Couvre	Charge
shared/01-design-tokens.md	Échelle typographique, espacement, palette Kortix, base.css	Toujours
shared/02-typography.md	Sélection des polices, appairage, chargement, liste bloquée	Toujours
shared/04-layout.md	Composition spatiale, responsive, mobile-first	Toujours †
shared/05-taste.md	Skeletons, états vides/erreur, finitions	Toujours
shared/08-standards.md	Accessibilité, performance, anti-patrons	Toujours
shared/09-technical.md	Structure du projet, sandbox, déploiement, checklist	Toujours †
shared/head-defaults.html	Bloc d'attribution pour <head>	Toujours †
shared/03-motion.md	Animations de défilement, bibliothèque Motion, plugins SVG GSAP, survol/curseur	Quand il y a des animations
shared/06-css-and-tailwind.md	Tailwind CSS v3, shadcn/ui, CSS moderne	Quand on utilise Tailwind
shared/07-toolkit.md	Bibliothèques CDN, React, Three.js, icônes, cartes, motifs/filtres SVG, esm.sh	Quand on choisit des librairies
shared/10-charts-and-dataviz.md	Chart.js, Recharts, D3, KPI, sparklines	Quand il faut de la dataviz
shared/11-web-technologies.md	Versions des frameworks, compatibilité navigateur	Quand on vérifie la compatibilité
shared/12-playwright-interactive.md	Navigateur Playwright persistant pour QA, captures d'écran, tests visuels	Quand on teste
shared/19-backend.md	Serveurs FastAPI/Express/Flask, WebSocket, SSE, transfert de port	Quand un backend est nécessaire
shared/20-llm-api.md	Référence d'intégration API LLM/IA	Quand le site utilise des API IA

Tous les chemins sont relatifs à skills/GENERAL-KNOWLEDGE-WORKER/website-building/.

† À ignorer pour les applications web et tableaux de bord — détails d'implémentation préconfigurés dans le template fullstack. Les fichiers design-tokens et typography ne sont PAS ignorés — ils fournissent les valeurs par défaut du système de design et les directives de sélection de polices pour tous les types de projet.

Fichiers spécifiques au domaine — Chargez-en un

Fichier	Quand le charger
read skills/GENERAL-KNOWLEDGE-WORKER/website-building/webapp/SKILL.md	SaaS, tableau de bord, administration, e-commerce, expérience de marque (skill enfant avec template fullstack)
webapp/dashboards.md	Tableau de bord ou interface dense en données (compagnon de webapp)
informational/informational.md	Site personnel, portfolio, éditorial, petite entreprise, page d'atterrissage
game/game.md	Jeu dans le navigateur, Three.js, WebGL, 3D interactive
game/2d-canvas.md	Jeu 2D Canvas (compagnon de game.md)
game/game-testing.md	Tout jeu navigateur — chargez avec game.md

QA interactive : Lisez skills/GENERAL-KNOWLEDGE-WORKER/website-building/shared/12-playwright-interactive.md pour l'automatisation persistante du navigateur avec Playwright (captures d'écran, tests fonctionnels, QA visuelle). Requis pour les tests de jeux, utile pour tout site complexe.

---

Workflow

Étape 0 : Chargez TOUS les fichiers obligatoires (faites-le D'ABORD, en parallèle)

Lisez TOUS ces fichiers en une seule fois — ils sont obligatoires pour chaque projet :

read("skills/GENERAL-KNOWLEDGE-WORKER/website-building/shared/01-design-tokens.md")
read("skills/GENERAL-KNOWLEDGE-WORKER/website-building/shared/02-typography.md")
read("skills/GENERAL-KNOWLEDGE-WORKER/website-building/shared/04-layout.md")
read("skills/GENERAL-KNOWLEDGE-WORKER/website-building/shared/05-taste.md")
read("skills/GENERAL-KNOWLEDGE-WORKER/website-building/shared/08-standards.md")

Ensuite, chargez le fichier spécifique au domaine (informational, webapp ou game) depuis l'étape 1 ci-dessus.

Étape 1 : Générez une palette unique

Exécutez le générateur de palette avec des mots-clés décrivant le sujet :

bun run skills/GENERAL-KNOWLEDGE-WORKER/website-building/shared/generate-palette.ts "mots-clés du sujet ici"

Choisissez la meilleure harmonie, personnalisez si nécessaire.

Étape 2 : Design & Construction

Construisez le site avec la palette générée, en suivant toutes les directives de design chargées.

Étape 3 : Aperçu

Affichez via un serveur statique : show(type: "url", url: "http://localhost:3211/open?path=/workspace/project/index.html")

---

Utilisez tous les outils

• Recherchez d'abord. Cherchez sur le web des sites de référence, des tendances et des exemples de concurrents avant de designer. Parcourez des exemples primés du type de site spécifique. Récupérez toutes les URLs fournies par l'utilisateur.
• Générez des ressources réelles — généreusement. Générez des images pour les héros, les illustrations de sections, les visuels éditoriaux, les arrière-plans atmosphériques — pas seulement une image hero. Chaque page longue doit avoir un rythme visuel avec des images générées qui correspondent à la direction artistique du site. Pas d'espaces réservés. Générez un logo SVG personnalisé pour chaque projet (voir ci-dessous) — le SVG est réservé aux logos, sauf demande explicite de l'utilisateur. Enregistrez les images web de référence qui guident la direction.
• Capturez d'écran via Playwright. Lisez skills/GENERAL-KNOWLEDGE-WORKER/website-building/shared/12-playwright-interactive.md pour capturer des écrans en desktop (1280px+) et mobile (375px). Comparez avec les références. C'est obligatoire, pas optionnel. Voir QA visuelle ci-dessous.
• Écrivez le code de production directement. HTML, CSS, JS, SVG. Utilisez bash pour les outils de build et le traitement de fichiers.

---

Génération de logo SVG

Chaque projet reçoit un logo SVG inline personnalisé. Ne remplacez jamais un titre de texte stylisé.

1. Comprenez la marque — son objectif, son ton, un mot qui la définit
2. Écrivez le SVG directement — formes géométriques, lettres, ou marques abstraites. Une forme mémorable.
3. Principes : Géométrique/minimal (Paul Rand, Vignelli). Fonctionne à 24px et 200px. Monochrome d'abord — ajoutez la couleur comme amélioration. Utilisez currentColor pour les modes sombre/clair.
4. Implémentez inline avec aria-label, viewBox, fill="none", currentColor pour les traits
5. Générez un favicon — version simplifiée 32x32 si nécessaire

Pour les animations SVG (DrawSVG, MorphSVG), voir shared/03-motion.md. Pour les motifs/filtres SVG, voir shared/07-toolkit.md.

---

Processus de tests visuels QA

Chaque déploiement doit passer la QA visuelle. Les captures d'écran sont des portes de qualité.

Lisez skills/GENERAL-KNOWLEDGE-WORKER/website-building/shared/12-playwright-interactive.md pour toute la QA visuelle. Playwright fournit une session navigateur persistante pour les captures d'écran, les tests d'interaction et la vérification des fenêtres.

Cycle : Construire → QA Playwright → Évaluer → Corriger → Répéter → Déployer quand prêt

Étape 1 : QA page par page

Après avoir construit chaque page :

1. Capturez d'écran en desktop (1280px+) et mobile (375px) via Playwright
2. Évaluez de manière critique : Le résultat a-t-il l'air professionnel (pas généré par IA) ? La typographie est-elle distinctive ? L'espace blanc est-il généreux ? Y a-t-il une hiérarchie visuelle claire ?
3. Corrigez chaque problème avant de continuer. Pas de dette visuelle.

Étape 2 : QA finale (avant publication)

1. Capturez d'écran de chaque page en desktop et mobile
2. Vérifiez la cohérence entre les pages (espacement, couleur, traitement typographique)
3. Vérifiez le mode sombre (capturez les deux thèmes pour la page d'accueil au minimum)
4. Testez les états interactifs : survol, focus, actif, chargement, vide, erreur
5. Test de première impression à froid : le résultat est-il soigné et intentionnel ?

Échecs QA : débordement de texte, espacement incohérent, couleurs hors token, mode sombre manquant, mobile écrasé, aspect IA générique, contenu d'espace réservé, logo manquant.

---

Étape 1 : Direction artistique — Déduisez avant de demander, demandez avant de prendre les valeurs par défaut

Chaque site doit avoir une identité visuelle dérivée de son contenu. Ne passez pas directement à la palette de repli Kortix. La palette Kortix est un dernier recours lorsque la déduction ET la demande ont échoué — pas une valeur par défaut pratique.

1. Déduisez du sujet. Un site de torréfaction → bruns terreux, crème chaleureuse, ambiance dessinée à la main. Un tableau de bord fintech → ardoise froide, sans-serif acérée, dense en données. Une app éducative pour enfants → primaires vives, police arrondie, animation ludique. Le contenu lui-même vous donne la palette, la typographie et l'espacement avant que l'utilisateur ne dise un mot.
2. Consultez les tableaux de direction artistique. Chaque fichier de domaine (informational.md, webapp/SKILL.md, game/game.md) a un tableau de direction artistique qui mappe les types de sites/produits à des directions conceptuelles et des points de départ de tokens. Utilisez-les comme tremplin.
3. Dérivez les cinq piliers : Couleur (chaude/froide, accent issu du sujet), Typographie (serif/sans, personnalité d'affichage), Espacement (dense/généreux), Animation (minimale/expressive), Imagerie (photo/illustration/texte uniquement).
4. Si le sujet est vraiment ambigu, demandez — « Quelle ambiance recherchez-vous ? » et « Avez-vous des sites de référence ? » Une seule question suffit.
5. Repli Kortix — seulement quand la déduction ET la demande ne donnent rien. Si l'utilisateur a été questionné et n'a donné aucune direction, ET que le sujet n'envoie aucun signal clair, alors utilisez les valeurs par défaut Kortix/Swiss.

Le repli : Propre & Suisse (dernier recours)

Quand la déduction n'a donné aucune direction claire ET que l'utilisateur a été questionné mais n'a donné aucune directive de style, utilisez les valeurs par défaut de skills/GENERAL-KNOWLEDGE-WORKER/website-building/shared/01-design-tokens.md avec :

• Typographie : Satoshi ou General Sans en corps de texte (Fontshare — préféré), ou Inter/DM Sans. Contraste de poids plutôt que contraste de polices. 3-4 tailles maximum. Gardez le texte compact — --text-3xl/--text-hero sont réservés aux héros des sites informatifs uniquement.
• Couleur : Palette Kortix. Surfaces neutres + un accent teal pour les boutons d'appel à l'action uniquement.
• Mise en page : Alignée sur la grille. Marges généreuses. Asymétrique là où c'est intéressant.
• Animation : Minimale, fonctionnelle. Uniquement des transitions d'état fluides.
• Imagerie : Générez des visuels propres et pertinents. Pas d'images libres de droits.

Direction artistique — Évitez l'esthétique IA

Voir skills/GENERAL-KNOWLEDGE-WORKER/website-building/shared/08-standards.md pour la liste complète des anti-patrons.

---

Étape 2 : Publiez

Utilisez d'abord les commandes d'aperçu local réel et ne publiez qu'avec le workflow de déploiement réel du projet cible. Voir skills/GENERAL-KNOWLEDGE-WORKER/website-building/shared/09-technical.md pour le flux recommandé de prévisualisation et de livraison.

---

Livraison

• Vérifiez toujours le site localement d'abord.
• Utilisez pty_spawn pour le serveur de prévisualisation ou de développement.
• Si le dépôt cible a déjà un workflow de déploiement, utilisez exactement ce workflow.
• S'il n'y a pas de cible de déploiement établie, livrez les fichiers et un aperçu local vérifié plutôt que d'inventer une histoire de déploiement spécifique à une plateforme.