demo-page
"Création de pages démo HTML pour validation visuelle avant code. Activer quand : l'utilisateur demande une démo, maquette, preview, prototype, mockup, page de test design, ou veut valider un design/UX/UI avant de coder ; OU quand il dit 'montre-moi à quoi ça ressemblerait', 'fais-moi une preview', 'je veux voir avant de coder', 'créer une page démo', 'design preview', 'propose-moi un design'. Ne pas activer pour du code de production, des composants finaux, des modifications de fichiers existants du projet, ni quand l'utilisateur demande directement de coder une feature sans étape de validation visuelle."
Install
npx skillscat add vendeesign/codebloom/demo-page Install via the SkillsCat registry.
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
frontend-design: complémentaire — la démo suit ses principes (direction artistique, anti-slop, CSS moderne)accessibility: complémentaire — la démo respecte les bases WCAG (sémantique, contrastes, clavier)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.mdsi 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.mdpour 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.gitignoresi 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.mdsi 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)
Variantes
Quand l'utilisateur hésite entre plusieurs approches :
- Créer un fichier par variante :
demos/hero-v1.html,demos/hero-v2.html - Ou une seule page avec toggle entre les variantes (boutons en haut de page) — plus pratique pour comparer
- Si > 2 variantes → demander la préférence (fichiers séparés vs toggle)
Étape 3 — Ouvrir dans le navigateur
Ouvrir automatiquement la page après création — ne pas attendre que l'utilisateur le fasse manuellement :
# Windows (Git Bash)
explorer.exe "$(cygpath -w "$(pwd)/demos/{fichier}.html")"
# macOS
open "demos/{fichier}.html"
# Linux
xdg-open "demos/{fichier}.html"Si plusieurs variantes → ouvrir toutes les pages.
É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.
- 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
Categories
Install
npx skillscat add vendeesign/codebloom/demo-page Install via the SkillsCat registry.