Page démo HTML pour validation visuelle avant code. Mots-clés : démo, maquette, preview, prototype, mockup, 'montre-moi à quoi ça ressemblerait'. Ne se charge PAS quand : preview d'un diff/PR, aperçu markdown, démo non visuelle.

Demo Page — Validation visuelle avant code

Crée des pages HTML standalone pour valider un design, un bloc, une interface ou une page avant d'écrire le code de production. Cadrer visuellement en amont évite les allers-retours coûteux entre design et implémentation.

Interactions avec d'autres skills

ui-design : complémentaire — la démo suit ses principes (direction artistique, anti-slop, CSS moderne, accessibilité WCAG). Toujours charger la skill ui-design quand on crée une démo.
code-quality : ne PAS appliquer — le code démo est jetable, pas du code de production

Étape 1 — Contexte design

Avant de créer la démo :

Lire DESIGN_SYSTEM.md si présent — la démo doit respecter les tokens exacts (couleurs, typo, spacing), sinon le résultat ne sera pas représentatif de la prod
Lire CLAUDE.md pour le stack et les conventions du projet
Poser 1-2 questions max si le besoin n'est pas clair (pas d'interrogatoire — c'est un prototype, pas un cahier des charges)

Étape 2 — Créer la page démo

Emplacement

Dossier demos/ à la racine du projet — séparé du code source pour ne pas polluer le projet et permettre un nettoyage facile.

Nom du fichier : {description-courte}.html (kebab-case, descriptif)
Exemples : demos/hero-section.html, demos/pricing-table.html, demos/dashboard-layout.html
Si demos/ n'existe pas → le créer
Ajouter demos/ au .gitignore si présent et pas déjà ignoré — les démos ne doivent jamais être commitées

Contenu

Fichier HTML standalone — tout en un seul fichier, pour être ouvrable par double-clic sans serveur ni build :

HTML5 complet (<!DOCTYPE html>, <head> avec viewport meta, <body>)
CSS dans <style> — pas de fichier externe (une seule source de vérité)
JS dans <script> si interactions nécessaires — pas de fichier externe
Zéro dépendance externe (pas de CDN, pas de framework CSS, pas de npm) — garantit que la démo fonctionne offline et ne casse jamais
Responsive par défaut (viewport meta + media queries)

Qualité visuelle

La démo doit être production-grade visuellement — c'est le standard exact à reproduire en prod :

Respecter DESIGN_SYSTEM.md si présent (tokens exacts)
Sans design system → proposer un design cohérent et distinctif (éviter le générique "AI slop")
Contenu réaliste — pas de Lorem Ipsum, utiliser des textes, noms et chiffres crédibles. Le Lorem Ipsum empêche de juger la longueur réelle et la hiérarchie visuelle.
États interactifs si pertinents (hover, focus, active, disabled)
Fond et mise en page réalistes (pas de wireframe gris)

Organisation selon le type de contenu

Pages complètes (landing page, dashboard, page produit...) :

Un fichier HTML par proposition : demos/landing-v1.html, demos/landing-v2.html
Toujours créer un demos/index.html — page de navigation avec liens vers toutes les propositions. Permet de naviguer facilement entre les variantes sans retour terminal.
Mettre à jour index.html à chaque ajout/suppression de démo

Blocs ou sections (hero, pricing, footer, card, formulaire...) :

Tout sur une seule page : demos/hero-proposals.html
Chaque proposition empilée verticalement avec un séparateur visuel et un titre (ex: "Proposition A", "Proposition B")
Permet la comparaison directe sans changer de page

Variantes

Quand l'utilisateur hésite entre plusieurs approches :

Pages complètes → fichiers séparés + index.html de navigation
Blocs/sections → tout sur une page, empilé verticalement
Si ambiguïté sur le type → demander

Étape 3 — Ouvrir dans le navigateur

Ouvrir automatiquement après création — ne JAMAIS attendre que l'utilisateur le fasse :

# Windows (Git Bash)
explorer.exe "$(cygpath -w "$(pwd)/demos/{fichier}.html")"

# macOS
open "demos/{fichier}.html"

# Linux
xdg-open "demos/{fichier}.html"

Pages complètes → ouvrir demos/index.html
Blocs/sections → ouvrir la page unique
Après chaque modification → ré-ouvrir la page concernée

Étape 4 — Itérer

Après que l'utilisateur a vu la démo :

Attendre son retour (approbation, ajustements, choix de variante)
Modifier la démo selon les retours
Ré-ouvrir dans le navigateur après chaque modification — l'utilisateur ne doit pas avoir à rafraîchir manuellement
Répéter jusqu'à validation

Étape 5 — Implémenter en prod

Quand l'utilisateur valide et demande l'implémentation :

Coder dans les fichiers de production du projet (composants, templates, pages selon le stack)
La démo sert de référence visuelle exacte — le résultat prod doit être pixel-perfect
Supprimer la page démo utilisée (demos/{fichier}.html) — une démo qui traîne finit par semer la confusion
Si le dossier demos/ est vide après suppression → le supprimer aussi

Anti-patterns

Mauvais	Pourquoi	Bon
Livrer la démo comme code prod	HTML inline n'est pas maintenable, pas de composants réutilisables	Recoder proprement dans le stack du projet
Lorem Ipsum	Impossible de juger la hiérarchie visuelle et les longueurs réelles	Contenu crédible et représentatif
CDN Bootstrap/Tailwind dans la démo	Dépendance externe, résultat non représentatif du rendu prod	CSS custom inline
Démo non supprimée après implémentation	Confusion, version fantôme qui diverge de la prod	Supprimer dès que le code prod est validé
Demander avant d'ouvrir le navigateur	Friction inutile, l'utilisateur veut voir	Ouvrir automatiquement

Comportement

Rapide — c'est un outil de cadrage, pas une œuvre d'art. Créer vite, itérer vite.
Paralléliser — quand plusieurs pages démo sont à créer, lancer un agent par page en parallèle (outil Agent, tous dans un seul message)
Standalone — zéro dépendance, un seul fichier, ouvrable par double-clic
Réaliste — contenu crédible, design production-grade, pas de placeholder
Ouvrir systématiquement — après création ET après chaque modification
Nettoyer — supprimer la démo dès que le code prod est écrit

demo-page