Diaporamas Web
Transformer un ensemble de matériaux / un plan / des points clés en un « diaporama HTML cinématographique » prêt à être projeté en direct. Le résultat = un projet Vite + React + TS. Cliquez ou utilisez les touches fléchées pour avancer, chaque étape occupe un écran entier. Appuyez sur P pour ouvrir une fenêtre dédiée à l'orateur avec les notes de présentation (aperçu en temps réel + minuteur, les deux fenêtres sont synchronisées ; partagez uniquement la fenêtre principale du diaporama pour cacher les notes au public). Appuyez sur N pour afficher/masquer la superposition de notes pour les répétitions.
Différence avec [web-video-presentation] : cette compétence crée des « pages web qui ressemblent à des vidéos » – avec un script d'enregistrement vocal, un son synthétisé et un enregistrement d'écran. Cette compétence crée uniquement des diapositives pour une projection en direct : pas de script d'enregistrement vocal, pas de son, pas d'enregistrement d'écran ; le texte de chaque étape devient des notes de présentateur pour aider l'orateur, et n'apparaît jamais à l'écran. Le reste de la méthodologie visuelle, le système de thèmes et le principe de révélation progressive sont entièrement conservés.
Scénarios d'utilisation
- « J'ai du matériel / un plan, transforme-le en diapositives / présentation »
- Conférence technique / keynote / démonstration produit / pitch deck / cours
- Revue de projet en entretien – présentez en direct vos diapositives, appuyez sur P pour ouvrir la fenêtre de l'orateur et voir vos notes
- Vous voulez un format 16:9, grand écran, beaucoup d'espace blanc, des animations dynamiques « comme un PPT mais qui n'en a pas l'air »
- Transformer un article / des notes en une explication interactive étape par étape
Cette compétence se concentre sur la méthodologie et le flux de collaboration. Le modèle d'ossature fournit des tokens et des primitives, mais chaque décision esthétique (palette de couleurs, typographie, style d'animation) doit être redéfinie en fonction de votre sujet – ne recopiez pas.
Deux profils de densité : style vidéo / style deck de présentation
Le même moteur peut exécuter les deux rythmes. Choisissez-en un dans la Phase 1 (écrivez-le en haut de outline.md, confirmez avec l'utilisateur dans le Checkpoint Plan) :
| 🎬 Style vidéo (par défaut / aéré) | 🎤 Style deck de présentation (pages limitées / haute densité) | |
|---|---|---|
| Scénario | Commentaire enregistré, beaucoup de temps de parole, nombreux battements | Présentation en direct / projection, nombre de pages limité, on reste sur une page (courant pour les revues de projet en entretien) |
| Une diapositive | = une étape (prise de contrôle totale de l'écran) | = un chapitre (une page stable et dense) |
| Sémantique de l'étape | Passage à l'idée suivante (changement de scène) | Construction progressive sur la même diapositive (les éléments restent à l'écran et apparaissent un par un, pas de changement de scène) |
| Information par écran | 1 héros + 1~3 éléments + beaucoup d'espace blanc | Graphique / tableau / schéma + plusieurs points clés + données sur le même écran |
| Échelle | Beaucoup de chapitres × peu d'étapes | Peu de chapitres (≈ nombre de pages cible) × 2~5 constructions par chapitre |
| Thème | Quelconque | Priorité aux thèmes structurels / éditoriaux (newsroom / monochrome-print / blueprint / swiss-ikb / vintage-editorial) |
Les deux ne modifient pas le moteur (chapitre/étape, scène 16:9, tokens, MaskReveal sont universels), la différence réside uniquement dans la manière d'écrire les chapitres. Le mode deck assouplit « une idée par écran / beaucoup d'espace blanc / tout héros », mais « éviter le style IA » + tokens + hiérarchie réelle + doit avoir une démo visuelle + double source reste la même base – c'est ce qui garantit que ce n'est « pas moche ». Voir CHAPTER-CRAFT.md « Deux profils de densité » pour la rédaction détaillée de chaque chapitre.
En cas de doute → 🎬 Style vidéo.
Aperçu du flux de travail
Phase 1 Planification du contenu
1.1 Identifier l'entrée utilisateur
1.2 Produire outline.md
(découpage des chapitres + contenu de chaque étape + notes optionnelles pour chaque étape + pool d'informations)
▼
[Checkpoint Plan] ← Doit s'arrêter. Aligner 4 choses à la fois :
outline / thème / matériel / mode de développement
▼
Phase 2 Développement web
2.1 Mise en place de l'ossature (selon le thème choisi)
2.2 Chapitre 1 = thread principal + version complète (ancrage obligatoire)
▼
[Nœud dur] Validation utilisateur du Chapitre 1 ← Ne peut pas être sauté
▼
2.3 Chapitres 2 à N (selon le mode choisi : A chapitre par chapitre / B séquentiel / C parallèle)
▼
[Checkpoint Done] ← Diapositives terminées, serveur de développement en cours
▼
Phase 3 Projection / Exportation
Pas de phase « synthèse audio » et « enregistrement d'écran » – ce sont des diapositives, pas des vidéos.
Convention de répertoire de travail (l'agent crée/modifie dans le répertoire courant de l'utilisateur) :
mes-diapositives/
├── material.md # Conserve le matériau brut original de l'utilisateur – NE PAS SUPPRIMER ! Source d'information visuelle pendant le développement
├── outline.md # Obligatoire : plan de développement (découpage des chapitres + contenu de chaque étape + pool d'informations + notes optionnelles)
└── presentation/ # Projet Vite + React + TS généré par l'ossature
└── src/chapters/<NN>-<id>/
├── <Chapitre>.tsx # Implémentation visuelle
├── <Chapitre>.css
└── notes.ts # ★ Source unique de vérité pour le nombre d'étapes + notes de présentateur
Point clé :
notes.tsest la source unique de vérité pour le nombre d'étapes. Le nombre maximum deif (step === N)rencontrés dans le.tsxdu chapitre + 1 doit être égal ànotes.length. Cela garantit que le code du chapitre, la barre de progression et le stepper ne dérivent jamais. Le contenu des notes (les chaînes dans le tableau) est envoyé uniquement à la fenêtre de l'orateur (touche P) et à la superposition de notes (touche N), n'apparaît jamais sur l'écran du diaporama, et peut être laissé vide"".
Protocole d'auto-vérification rigide (tout au long de cette compétence)
Pour les deux livrables ci-dessous, une fois terminé, vous devez auto-vérifier → corriger → puis signaler / avancer :
| Livrable | Source de la liste de contrôle |
|---|---|
outline.md | Auto-vérification OUTLINE-FORMAT.md |
| Implémentation d'un chapitre terminée | Auto-vérification d'achèvement CHAPTER-CRAFT.md |
Méthode d'exécution (par ordre décroissant de capacité, privilégiez la méthode la plus isolée) :
- Agent Teams (optimal) : Ouvrez un agent reviewer indépendant, donnez-lui « le chemin du fichier produit + la liste de contrôle correspondante + le contexte clé », demandez-lui de vérifier point par point et de rapporter strictement les conclusions (quels points sont passés / quels points ont échoué + preuves + suggestions de réécriture).
- subAgent (sous-optimal) : Si vous n'avez pas la capacité Teams mais pouvez ouvrir un subagent, utilisez le subagent avec le même processus.
- Auto-vérification (solution de repli) : Si l'agent actuel n'a aucune des capacités ci-dessus, vérifiez vous-même point par point et rigoureusement – ne vous contentez pas d'un survol visuel pour valider.
Règle impérative : Après avoir obtenu les conclusions, corrigez d'abord les échecs dans le livrable, puis signalez à l'utilisateur « C'est terminé + conclusions de l'auto-vérification + ce qui a été corrigé ». Signaler directement les conclusions brutes sans corriger = violation.
Guide de lecture des fichiers par phase
Lisez différents fichiers à différentes phases. Dans les longues sessions, l'agent oublie facilement les principes, en particulier l'étape Phase 2.4 « Implémenter un chapitre » qui se répète N fois – à chaque fois, revenez sur les contraintes fondamentales.
| Phase | À lire obligatoirement (à chaque fois) | À lire une fois / Consulter au besoin |
|---|---|---|
| Phase 1.1-1.2 Planification du contenu | references/OUTLINE-FORMAT.md + material.md (matériau brut de l'utilisateur, le cas échéant) | —— |
| Checkpoint Plan Choisir le thème | —— | themes/*/theme.json (lire dynamiquement tous, lister + recommandation bestFor + descriptionZh) ; references/THEMES.md (quand l'utilisateur veut en savoir plus sur le système de thèmes) |
| Phase 2.1 Mise en place de l'ossature | —— | SKILL.md section actuelle (à lire une fois) |
| Phase 2.4 Implémenter un chapitre (×N fois, appelé par 2.2 / 2.3) | references/CHAPTER-CRAFT.md point d'entrée unique – exigences de démonstration visuelle / révélation progressive / sélection du contenu / double source (outline+material) / esthétique de projection / éviter le style IA / contraintes minimales de code (y compris la contrainte impérative de notes.ts) / référence de durée / auto-vérification d'achèvement + themes/<id>/theme.json du thème actuel + section outline.md du chapitre actuel + section material.md correspondant au chapitre actuel + liste du matériel | references/EXAMPLES/ (indices de structure, pas des modèles à copier) ; references/THEMES.md (contrat complet des tokens) |
| Phase 3 Projection / Exportation | references/PRESENTING.md (projection plein écran, navigation clavier, appuyer sur N pour voir les notes, exporter en PDF / capture d'écran) | —— |
| Choisir / Créer / Modifier un thème | —— | references/THEMES.md |
Lors de l'écriture d'un chapitre, lisez uniquement
CHAPTER-CRAFT.md. Les dix principes / l'auto-interrogation de démarrage / l'arbre de décision / les anti-patrons du style IA / l'auto-vérification d'achèvement sont tous intégrés dans ce point d'entrée unique.EXAMPLES/n'est pas obligatoire – concevez d'abord librement en fonction du contenu, ne le consultez qu'en cas de blocage (cherchez la « forme » par l'ancrage, ne recopiez pas).
Phase 1 – Planification du contenu
1.1 Identifier l'entrée utilisateur
| Ce que l'utilisateur donne | Ce qu'il faut faire |
|---|---|
| Matériau brut (article / notes / ensemble de points clés / données) | Produire outline.md (1.2), conserver le matériau original comme material.md, passer au Checkpoint Plan |
| Un plan / une structure déjà écrits | Convertir au format outline.md (1.2), passer au Checkpoint Plan |
| Rien, dit juste « Fais-moi des diapositives sur le thème X » | Demander : Donnez d'abord un peu de matériel ou des points clés. La compétence n'imagine pas le contenu à la place de l'utilisateur |
1.2 Produire outline.md
Suivez les règles de references/OUTLINE-FORMAT.md : découper en chapitres → découper en étapes → extraire le pool d'informations du premier paragraphe de chaque chapitre → écrire le contenu de l'écran pour chaque étape (+ note de présentateur optionnelle).
Décidez d'abord du profil de densité (🎬 style vidéo / 🎤 style deck, voir « Deux profils de densité » ci-dessus) – il détermine directement comment les chapitres sont découpés : en mode deck, le nombre de chapitres ≈ le nombre de pages cible, avec 2 à 5 constructions par chapitre.
Conservez material.md – ne le supprimez pas – c'est la source de détail pour écrire le pool d'informations de outline et les visuels des chapitres (principe de double source).
Les limites de outline (point clé) :
| outline doit écrire | outline ne doit pas écrire |
|---|---|
| Découpage des chapitres / nombre d'étapes par chapitre / estimation du temps | Types d'animations spécifiques (blur clear / wipe / ressort) |
| Contenu de l'écran par étape (héros / données / slogan / éléments de liste) | Moyens d'implémentation CSS (filter / SVG / clip-path) |
| Pool d'informations au niveau du chapitre : chiffres / citations / exemples / tags extraits du matériau | Valeurs numériques de la durée / du micro-rythme |
| Notes de présentateur par étape (optionnel : ce que vous prévoyez de dire à cette étape) | Micro-rythmes comme les micro-animations continues / le décalage |
| Préfixe de nom de relation entre les étapes (optionnel : « contraste/opposition » / « liste progressive » / « citation choc ») | —— |
Raison pour laquelle outline n'écrit pas les animations : Écrire des animations fixes = l'agent du chapitre se dégrade en traducteur ; laisser des blancs permet à l'agent du chapitre de concevoir librement selon l'« arbre de décision piloté par le contenu » de
CHAPTER-CRAFT.md, pour un véritable rendu visuel.
Après avoir écrit, vous devez d'abord procéder à l'auto-vérification avant d'entrer dans le Checkpoint Plan : Suivez le « Protocole d'auto-vérification rigide » ci-dessus pour outline.md (priorité Agent Teams → subAgent → auto-vérification), corrigez selon les conclusions, puis avancez.
Checkpoint Plan – Aligner 4 choses à la fois (nœud dur)
Après avoir écrit outline.md, vous devez vous arrêter. L'utilisateur confirme 4 choses en même temps à ce nœud.
Travail préparatoire de l'agent à ce stade
- Lire tous les
themes/*/theme.jsonpour obtenirnameZh/descriptionZh/bestFor/mood– ne pas coder en dur la liste - En fonction du type de contenu / des mots-clés / du ton de outline, choisir activement 2~3 thèmes les plus adaptés (correspondant au champ
bestFor) - Parcourir la section « Liste du matériel » à la fin de
outline.md
Modèle de résumé (squelette, l'agent remplit en fonction de la situation)
Le plan de contenu est terminé, fichiers produits :
📄 material.md {si l'utilisateur a fourni le matériau original, conservez-le}
📄 outline.md {N} chapitres / {M} étapes + pool d'informations par chapitre + liste du matériel à la fin
Aperçu des chapitres :
1. <id> <Titre du chapitre> <S> étapes ~<T>s
2. ...
Ensuite, nous alignons 4 choses à la fois :
1. Faut-il modifier le plan de développement (outline.md) ? Points clés :
- Le profil de densité est-il correct (🎬 style vidéo : étapes aérées / 🎤 style deck : haute densité avec pages limitées) ?
- Le découpage des chapitres et le nombre d'étapes sont-ils raisonnables (~5~12 étapes par chapitre est une plage courante) ?
- Le contenu de l'écran par étape est-il clair ?
- Le « pool d'informations » en tête de chaque chapitre contient-il suffisamment de détails du matériau pour nourrir les visuels ?
- La liste du matériel à la fin est-elle complète ?
2. Quel thème choisir ? Mes recommandations :
★ <Recommandation 1 : nameZh (id)> — parce que <correspondance bestFor> ; <résumé descriptionZh>
★ <Recommandation 2 / Recommandation 3>
Autres options : <thèmes restants, nameZh + une phrase>
Vous pouvez aussi me demander de créer un nouveau thème (voir references/THEMES.md).
3. Comment préparer le vrai matériel ? Aperçu approximatif des images nécessaires pour ces diapositives : <liste approximative>
a) Je choisis parmi <chemin du matériel existant> b) Vous fournissez vous-même c) Tout en placeholders
4. Quel mode de développement choisir ?
**Le Chapitre 1, quel que soit le mode, doit être fait sur le thread principal et validé par l'utilisateur** (ancrage obligatoire).
La différence commence à partir du Chapitre 2 :
A) Défaut · Confirmation chapitre par chapitre (recommandé)
Chaque chapitre terminé, on s'arrête pour validation → risque contrôlable / rythme le plus stable
B) Développement séquentiel après le Chapitre 1 (non parallèle)
Les chapitres 2 à N sont faits séquentiellement sur le thread principal, puis validation unique à la fin → vitesse moyenne / convient aux environnements où l'agent ne supporte pas le parallélisme
C) Développement parallèle après le Chapitre 1 (subagent)
Les chapitres 2 à N sont faits en parallèle avec des subagents → le plus rapide / l'utilisateur contrôle le nombre de parallélismes (combien de chapitres à la fois)
⚠️ Le style variera entre les chapitres (c'est attendu, les interdictions du thème servent de filet de sécurité)
Après réception des commentaires :
- Si outline doit être modifié : modifiez directement le fichier, une fois terminé, mentionnez-le (ou décrivez ce que l'agent a modifié)
- Le thème doit être clairement défini pour passer à la Phase 2. Si l'utilisateur dit « choisis pour moi » → prenez votre 1ère recommandation, dites à l'utilisateur ce que vous avez choisi et pourquoi, laissez une possibilité de revenir en arrière
- Mode choisi → passer à la Phase 2
Phase 2 – Développement web
2.1 Mise en place de l'ossature
bash <chemin-vers-web-slides>/scripts/scaffold.sh \
./presentation \
--theme=<id du thème choisi par l'utilisateur>
bash <chemin-vers-web-slides>/scripts/scaffold.sh --list-themes
Thème personnalisé → Créez d'abord un dossier
themes/<mon-theme>/selon le flux « Créer un nouveau thème » dereferences/THEMES.md, puis--theme=<mon-theme>.
L'ossature inclut une démo 01-example. Supprimez-la avant d'écrire le vrai contenu du premier chapitre :
rm -rf presentation/src/chapters/01-example
Et supprimez l'import et l'entrée du chapitre example dans presentation/src/registry/chapters.ts.
2.2 Chapitre 1 – Thread principal + validation obligatoire
Point clé : Le Chapitre 1 = version complète en une seule fois (rythme + visuels + vrai matériau complet). Pas de concept de « version squelette » – le premier chapitre doit être un échantillon directement validable par l'utilisateur.
Pourquoi le Chapitre 1 doit être sur le thread principal :
- C'est la première application des directives de
CHAPTER-CRAFT.mdsur le thème actuel + le sujet actuel - S'il y a des angles morts dans les directives / si les tokens de couleur ou de police sont insuffisants, le Chapitre 1 les révélera – à ce moment-là, un retour humain permet de corriger les directives / d'ajuster le thème, le coût de la correction précoce est le plus bas
- Les chapitres suivants (séquentiels ou parallèles) doivent se référer au modèle de code du Chapitre 1, donc le Chapitre 1 = ancrage stylistique du projet actuel
Après avoir terminé le Chapitre 1, vous devez vous arrêter et attendre la validation de l'utilisateur :
Le Chapitre 1 <id> est terminé, le serveur de développement tourne sur localhost:5174.
Points clés pour la validation :
□ L'ambiance visuelle est-elle correcte ? Correspond-elle aux attentes du <nameZh du thème> ?
□ Le rythme est-il bon ? Certaines étapes sont-elles trop rapides / trop lentes / avec trop peu d'informations ?
□ Les animations pilotées par le contenu sont-elles appropriées ? Ou y a-t-il des étapes avec des animations d'entrée génériques ?
□ Principe de double source : L'image d'écran a-t-elle des détails qui « ne sont pas dans les notes mais que le matériau peut fournir » ?
□ Vérification anti-style IA : Y a-t-il des dégradés violet-rose, des bordures colorées arrondies, des fausses illustrations, des emojis ?
□ Appuyez sur N pour voir les notes de présentation. La lecture à voix haute est-elle fluide ?
Dites-moi les problèmes, je les corrigerai de manière ciblée. Quand c'est bon, dites « Continue », et je passerai au Chapitre 2 et suivants selon le mode choisi.
2.3 Chapitres 2 à N – Selon le mode choisi
Règles communes à tous les modes : Chaque chapitre est développé indépendamment selon CHAPTER-CRAFT.md. Le style n'a pas besoin d'être parfaitement cohérent entre les chapitres – les tokens de couleur / police du thème assurent l'unité visuelle de base, et les animations / rythme / démonstrations visuelles sont librement conçues par le chapitre, c'est attendu.
Mode A · Défaut · Confirmation chapitre par chapitre
Chapitre 2 terminé → pause pour validation → OK → Chapitre 3 → pause → ... → Chapitre N. Validation indépendante de chaque chapitre, les problèmes sont corrigés à tout moment, risque le plus bas, rythme le plus stable. Si l'utilisateur ne choisit pas explicitement un mode, on utilise celui-ci par défaut.
Mode B · Développement séquentiel après le Chapitre 1
Chapitre 2 → Chapitre 3 → ... → Chapitre N faits séquentiellement sur le thread principal, validation unique à la fin. Vitesse moyenne, adapté aux environnements où l'agent ne supporte pas les tâches parallèles.
Mode C · Développement parallèle après le Chapitre 1 (subagent)
Utiliser des subagents pour faire les chapitres 2 à N en parallèle, le nombre maximum de parallélismes est contrôlé par l'utilisateur (« 4 chapitres à la fois » / « 2 chapitres à la fois »). Le plus rapide, mais le style variera entre les chapitres – c'est attendu, car :
- Chaque subagent ne voit pas les productions des autres subagents, impossible d'aligner mécaniquement
- Le code des chapitres est physiquement séparé (un dossier par chapitre / son propre préfixe CSS), ils ne se perturbent pas
- Les tokens du thème assurent l'unité visuelle (couleurs / polices / nombres héros / cartes / traits de séparation / motif / décoration), l'ambiance ne dévie pas
- L'incohérence de style = la respiration d'une création manuelle (multi-voix / multi-perspectives)
Le prompt du subagent parallèle doit inclure :
- Le paragraphe d'outline du chapitre actuel (avec le pool d'informations)
- Le chemin vers
references/CHAPTER-CRAFT.md(lecture obligatoire unique) - Les champs
descriptionZh/mood/bestFordutheme.jsondu thème actuel - Le code du Chapitre 1 comme référence de « style de code » (pas comme « modèle visuel à copier »)
- Règle stricte : Préfixe CSS indépendant pour chaque chapitre (
.cd-/.mg-/.pm-/ ...) ; ne pas modifierchapters.ts; chaque chapitre a sonnotes.ts(longueur = nombre d'étapes) ; à la fin, exécuternpx tsc --noEmit
Important : Quel que soit le mode choisi, l'utilisateur peut changer de mode à tout moment.
2.4 Implémenter un chapitre (à faire pour chaque chapitre)
Les instructions détaillées se trouvent dans references/CHAPTER-CRAFT.md – point d'entrée unique obligatoire, couvrant : exigences de démonstration visuelle / révélation progressive / sélection du contenu / principe de double source / esthétique de base de la démonstration visuelle / anti-style IA / lignes rouges du code / auto-vérification d'achèvement.
Points clés (détaillés dans CHAPTER-CRAFT.md) :
- Chaque chapitre doit avoir une démonstration visuelle CSS / SVG / Canvas / JS, interdiction des chapitres purement textuels
- Révélation progressive : Les listes / listes à puces doivent avoir 1 élément = 1 étape, interdiction de tout afficher en une fois
- Principe de double source : Le rythme suit outline (l'ordre ne peut pas être changé), les détails reviennent au matériau brut (pool d'informations + paragraphe material du chapitre)
- Chaque chapitre a son
notes.ts: Longueur = nombre d'étapes (source unique de vérité), le contenu sont les notes de présentateur (peut être laissé vide""), n'apparaît jamais sur l'écran - Passer en revue l'auto-vérification d'achèvement point par point, revenir en arrière et corriger si les critères ne sont pas remplis – suivre le « Protocole d'auto-vérification rigide », corriger avant de signaler la livraison de ce chapitre à l'utilisateur
2.5 Incrémenter STORAGE_KEY après une modification importante
Après avoir modifié chapters.ts (ajout / suppression / réorganisation de chapitres, ou changement de longueur de notes.ts d'un chapitre), incrémentez STORAGE_KEY dans presentation/src/hooks/useStepper.ts (par exemple web-slides-cursor-v1 → v2), pour éviter que le curseur persistant n'atterrisse sur une étape qui n'existe plus.
Phase 3 – Projection / Exportation
Le processus détaillé se trouve dans references/PRESENTING.md. Points essentiels :
- Projection en direct :
npm run dev→ Plein écran du navigateur (F11) → Cliquez ou utilisez les touches fléchées pour avancer. - Navigation clavier :
← →/ espace pour avancer ;Home/Endpour aller au début/à la fin ; touches numériques1-9pour sauter à un chapitre ; appuyez surPpour ouvrir la fenêtre de l'orateur (fenêtre indépendante : script d'enregistrement vocal + aperçu en temps réel + minuteur, les deux fenêtres sont synchronisées) ; appuyez surNpour ouvrir/fermer la superposition de notes (superposée sur la fenêtre actuelle, uniquement pour les répétitions – ⚠️ elle sera partagée avec l'écran). - La bonne façon pour que la projection ne montre pas le script d'enregistrement vocal : Appuyez sur
Ppour ouvrir la fenêtre de l'orateur → Dans le logiciel de réunion, sélectionnez « Partager une fenêtre / un onglet » et choisissez la fenêtre principale du diaporama (ne sélectionnez pas « Partager tout l'écran ») → La fenêtre de l'orateur est visible uniquement par vous, le changement de page synchronise les deux fenêtres, cela fonctionne même avec un seul écran. - Distribution hors ligne / projection stable :
npm run build→npm run preview, ou déployezdist/. - Exportation (optionnel) : Capture d'écran étape par étape en PNG, ou « Imprimer en PDF » étape par étape dans le navigateur.
À la fin de la Phase 2, informez activement l'utilisateur : Les diapositives sont terminées, le serveur de développement tourne sur localhost:5174, vous pouvez projeter en direct / partager l'écran ; appuyez sur P pour ouvrir la fenêtre de l'orateur et voir le script d'enregistrement vocal (lors du partage d'écran, partagez uniquement la fenêtre principale du diaporama, le public ne le verra pas), appuyez sur N pour la superposition de notes de répétition (sera partagée avec l'écran).
Dix principes (liste en une phrase)
Le développement complet se trouve dans references/CHAPTER-CRAFT.md – consultez-le là-bas lors de l'écriture d'un chapitre, ce qui suit n'est qu'un index.
| # | Principe | En une phrase |
|---|---|---|
| 1 | Scène fixe 16:9 | Contenu 1920×1080 + transform scale, pas de responsive |
| 2 | Compteur d'étapes global | Les chapitres sont une fonction pure de l'étape, pas de minuteur |
| 3 | Chaque étape occupe tout l'écran | if (step === N) return <FullScene /> |
| 4 | Battement logique = étape | Un battement = une étape = une idée focalisée |
| 5 | Contrôles cachés dans les coins | Barre de progression : opacité 0 par défaut ; notes cachées par défaut (appuyez sur N pour ouvrir) |
| 6 | Scène sans chrome | Pas d'en-tête / de pied de page / de numéro de page / de barre de marque |
| 7 | Animations pilotées par le contenu | Cherchez d'abord l'action inhérente, utilisez l'animation d'entrée comme filet de sécurité uniquement si vous ne trouvez rien ; utilisez les micro-animations continues avec parcimonie |
| 8 | Révélation progressive de plusieurs points | 1 élément = 1 étape, interdiction de faire apparaître N éléments en même temps avec stagger |
| 9 | Même thème sur tout le diaporama | Pas de changement de couleur de fond entre les chapitres ; couleurs / polices via tokens, les autres échelles sont libres par chapitre |
| 10 | Principe de double source | outline fixe le rythme, le matériau fixe la densité visuelle (tombe dans le pool d'informations) |
🎤 En mode deck, les principes 3 « chaque étape occupe tout l'écran » / 8 « 1 élément = 1 étape » sont assouplis en : une page = un chapitre, étape = construction progressive sur la même page (les éléments restent à l'écran et apparaissent un par un) ; les autres principes restent inchangés. Voir « Deux profils de densité » ci-dessus.
Index rapide des retours courants des utilisateurs
Lorsque vous recevez un retour, déterminez d'abord le niveau (rythme / visuel / contenu / code), puis corrigez la plus petite partie, ne refaites pas tout le chapitre :
- Rythme : Trop rapide / trop lent / trop peu d'informations → Divisez / fusionnez les étapes (modifiez simultanément la longueur de
notes.ts+ lesif (step===N)du chapitre) - Visuel : Mauvaise ambiance / style IA → Consultez « Éviter le style IA » + « Esthétique de base de la projection » dans CHAPTER-CRAFT.md
- Contenu : Image trop vide / pas assez de détails → Revenez au pool d'informations + à la section
materialdu chapitre (principe de double source) - Code : Erreur / token non appliqué → Consultez « Contraintes minimales de code » dans CHAPTER-CRAFT.md
Ressources associées
Indiquées par « Quand lire », pour éviter de tout lire en une fois :
| Fichier | Quand lire | Contenu |
|---|---|---|
references/OUTLINE-FORMAT.md | Obligatoire Phase 1.2 | Spécification des champs d'outline.md, conventions de nommage, découpage des chapitres, pool d'informations, notes par étape |
references/CHAPTER-CRAFT.md | Point d'entrée unique obligatoire pour chaque chapitre Phase 2.4 | Exigences de démonstration visuelle / révélation progressive / sélection du contenu / double source (outline+material) / esthétique de projection / éviter le style IA / contraintes minimales de code (y compris notes.ts) / référence de durée / auto-vérification d'achèvement |
references/EXAMPLES/ | Optionnel – pour voir la structure | Indices de structure de chapitre (hook / list-reveal / case-tech-review) ; pas des modèles à copier |
references/THEMES.md | Lors du choix / de la création / de la modification d'un thème | Contrat complet des tokens + liste des thèmes intégrés + processus de création |
references/PRESENTING.md | Lire uniquement en Phase 3 | Projection plein écran, navigation clavier, appuyer sur N pour voir les notes, exporter en PDF / capture d'écran |
themes/ | Consulter lors du Checkpoint Plan / Phase 1.2 | Thèmes intégrés (chacun avec theme.json + tokens.css) |
scripts/scaffold.sh | Exécuter une fois en Phase 2.1 | Mise en place d'une ossature de projet en une commande |
Cette compétence est une adaptation de
web-video-presentation(auteur ConardLi) – suppression du script d'enregistrement vocal / audio / enregistrement d'écran, conservation de toute la méthodologie visuelle et du système de thèmes, spécialisée dans la création de diapositives HTML pour une projection en direct.