Page démo HTML pour validation visuelle avant code. Mots-clés : démo, maquette, preview, prototype, mockup, 'montre-moi à quoi ça ressemblerait'.
From codebloomnpx claudepluginhub vendeesign/codebloom --plugin codebloomThis skill uses the workspace's default tool permissions.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Searches prompts.chat for AI prompt templates by keyword or category, retrieves by ID with variable handling, and improves prompts via AI. Use for discovering or enhancing prompts.
Compares coding agents like Claude Code and Aider on custom YAML-defined codebase tasks using git worktrees, measuring pass rate, cost, time, and consistency.
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.
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 productionAvant de créer la démo :
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 prodCLAUDE.md pour le stack et les conventions du projetDossier demos/ à la racine du projet — séparé du code source pour ne pas polluer le projet et permettre un nettoyage facile.
{description-courte}.html (kebab-case, descriptif)demos/hero-section.html, demos/pricing-table.html, demos/dashboard-layout.htmldemos/ n'existe pas → le créerdemos/ au .gitignore si présent et pas déjà ignoré — les démos ne doivent jamais être commitéesFichier HTML standalone — tout en un seul fichier, pour être ouvrable par double-clic sans serveur ni build :
<!DOCTYPE html>, <head> avec viewport meta, <body>)<style> — pas de fichier externe (une seule source de vérité)<script> si interactions nécessaires — pas de fichier externeLa démo doit être production-grade visuellement — c'est le standard exact à reproduire en prod :
DESIGN_SYSTEM.md si présent (tokens exacts)Pages complètes (landing page, dashboard, page produit...) :
demos/landing-v1.html, demos/landing-v2.htmldemos/index.html — page de navigation avec liens vers toutes les propositions. Permet de naviguer facilement entre les variantes sans retour terminal.index.html à chaque ajout/suppression de démoBlocs ou sections (hero, pricing, footer, card, formulaire...) :
demos/hero-proposals.htmlQuand l'utilisateur hésite entre plusieurs approches :
index.html de navigationOuvrir 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"
demos/index.htmlAprès que l'utilisateur a vu la démo :
Quand l'utilisateur valide et demande l'implémentation :
demos/{fichier}.html) — une démo qui traîne finit par semer la confusiondemos/ est vide après suppression → le supprimer aussi| 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 |