---
name: demo-page
description: "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 et indispensable — `demo-page` décide le *quoi / où / comment livrer* la démo ; `ui-design` décide *comment c'est designé*. La démo n'a pas sa propre doctrine visuelle : elle emprunte celle de `ui-design` en entier (direction artistique, anti-slop, typographie, couleur, spatial, accessibilité). **Toujours charger `ui-design` ET lire ses `reference/*.md` pertinents** (voir Étape 1).
- **`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 :
- **Charger `ui-design` ET lire ses `reference/*.md` pertinents** selon le type de démo (table « Chargement des références » du SKILL `ui-design`) — ne pas se contenter du SKILL, les guides détaillés sont là où est la qualité. Au minimum :
  - Page complète (landing, dashboard, page produit) → `typography.md` + `typography-hierarchy.md` + `spatial.md` + `color.md` (+ `typography-editorial.md` si contenu éditorial)
  - Bloc / composant / formulaire → `interaction.md` + `accessibility.md`
  - **Toujours** → `blacklist.md` (anti-slop) + `personality.md` si la démo a du contenu/microcopy
- Lire `DESIGN.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

### Direction visuelle (Step 0 condensé)

Avant d'écrire le HTML, appliquer une version courte du « Step 0 » de `ui-design` — 30 secondes, ça évite la démo générique :
- **1 phrase de visual thesis** (mood, matière, énergie — ex : « éditorial austère, papier chaud, énergie lente »)
- **Le UN truc mémorable** : la signature visuelle qui rendrait une capture reconnaissable, à exécuter sans compromis
- Lister mentalement 3 clichés que l'IA produirait pour ce brief, les bannir

### 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.md` si présent (tokens exacts)
- Sans design system → proposer un design cohérent et distinctif. **Passer la démo au crible de `reference/blacklist.md`** — les P0 (indigo Tailwind, gradient trust hero, emojis-icônes, carte + bordure gauche colorée, métriques inventées, copie filler…) sont des régressions, pas des préférences.
- 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 :

```bash
# 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 :
1. Coder dans les fichiers de production du projet (composants, templates, pages selon le stack)
2. La démo sert de **référence visuelle exacte** — le résultat prod doit être pixel-perfect
3. **Supprimer la page démo** utilisée (`demos/{fichier}.html`) — une démo qui traîne finit par semer la confusion
4. 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
