cerulean

Cerulean : présentations par scènes qui changent à chaque étape

Tu conçois et Cerulean construit. Tu écris trois fichiers : le script en JSON, les scènes programmées en JS et la peau en CSS. scripts/build.py les valide et les convertit en un HTML autonome avec le visualiseur inclus.

Chaque scène est une idée racontée en 2 à 4 étapes. À gauche se trouve une carte des étapes. À droite se trouve une illustration programmée pour cette scène : l'objet réel du sujet, avec sa propre chorégraphie, qui avance en douceur à chaque étape et a une vie propre (flotte, coule, palpite). Cela peut aussi être une capture d'écran ou une photo qui se rapproche et se légende. Que chaque scène se voie et se bouge différemment est ce qui rend une présentation Cerulean bonne.

Chaque présentation a également sa propre identité visuelle, que tu conçois pour ce sujet : le monde où elle vit (ses objets), la palette, les typographies, le rythme des fonds et une peau CSS écrite entièrement pour elle. Une présentation sur la sécurité ressemble à une console ; une sur l'histoire, à un imprimé d'époque. Deux sujets différents ne doivent pas sembler de la même collection, et en cachant le titre on doit deviner de quoi il s'agit.

Flux

1. Comprendre la commande. Tu as besoin du sujet, du contenu (notes, points, texte collé) et, s'il y en a, des images. Si seul le sujet est donné, développe-le avec des connaissances générales bien établies. N'interromps pas pour demander des images : s'il en manque, laisse leur espace réservé. Par défaut : français, de 5 à 9 scènes.

2. Lire le guide, une fois. Lis references/direction.md (l'identité visuelle), references/format.md (le JSON) et references/scenes.md (le kit, le temps et le catalogue des animations par type d'idée). assets/example.js contient 7 scènes complètes : lis-le seulement si tu doutes de la façon de résoudre quelque chose.

3. Concevoir l'identité avec le processus de direction.md : le monde du sujet (où il vit et 6 à 10 objets reconnaissables), l'ambiance, la palette tirée de cette scène, les typographies que ce monde utiliserait, le rythme et le mouvement, chacun avec sa ligne dans why. Passe le test de généricité : en cachant le titre, devine-t-on le sujet ?

4. Écrire le script dans presentations/<sujet>.json : textes, étapes, notes et le bloc design. Crée le dossier s'il n'existe pas. Répartis « fond » et « papier » selon le rythme.

5. Écrire la peau dans presentations/<sujet>.css : la carte, la couverture, les titres, les légendes, les détails et les entrées, tels qu'ils apparaîtraient dans ce monde (ce qui peut être habillé et ce qui ne peut pas l'être, dans direction.md).

6. Planifier les scènes avant de programmer : pour chacune, quel type d'idée elle explique (idée), sa métaphore en une phrase (forme) avec un objet du monde du sujet, et ce qui change à chaque étape. Au moins 3 types d'idée, aucune métaphore répétée. Utilise l'image uniquement pour des choses réelles que la personne veut montrer (son application, un produit, un lieu).

7. Programmer les scènes dans presentations/<sujet>.js (scene("nom", (K) => {…})), avec son "draw" dans le JSON. De 20 à 60 lignes par scène. Dessine l'artefact du monde, en plan par défaut (voir scenes.md).

8. Générer et réviser :

   python "<dossier de cette skill>/scripts/build.py" presentations/<sujet>.json
   

   Écrit presentations/<sujet>.html. Corrige les avertissements (noms sans scène, erreurs de syntaxe, images manquantes, direction visuelle incomplète, peau rejetée, manque de variété, ressemblance avec une présentation précédente). Si tu as un navigateur, révise sans dépenser de captures :

   • Sers l'aperçu : python "<dossier de cette skill>/scripts/preview.py" presentations/<sujet>.json en arrière-plan, et ouvre http://localhost:8767.
   • Exécute JSON.stringify(CERULEAN_REPORT()) sur la page. Il indique quelles scènes ont des erreurs, des pièces en dehors du canevas ou des étapes où rien ne change, et quels textes ne se lisent pas bien avec la peau (lisibilité). Corrige et relance ; la page se recharge toute seule.
   • Fais une seule capture de la vue d'ensemble (bouton « Toutes » ou touche G) pour juger l'ensemble : que l' identité se remarque (couleurs, police, style de dessin) et que les scènes ne se ressemblent pas entre elles. Ne capture pas étape par étape : c'est ce qui consomme le plus de temps et de tokens.

9. Livrer. Donne le chemin du HTML et explique en quelques lignes comment l'utiliser :

   • → ou espace avance, ← recule.
   • F plein écran, N notes, G vue d'ensemble.
   • E mode édition : corriger les textes, glisser les images et déplacer ou redimensionner la carte et l'illustration (poignées ✥ et ⤡). « Télécharger une copie » enregistre un HTML avec les modifications.
   • Le bouton PDF l'enregistre avec une scène par page.

   S'il reste des images manquantes, termine par leur liste : scène, ce qu'elle doit montrer et le nom presentations/images/scene-<n>.png.

Règles non négociables

• N'invente pas de chiffres, de dates, de citations, de noms ni d'études. Les chiffres qui apparaissent dans une scène viennent du contenu ou de connaissances très établies, et ils figurent aussi dans le texte de l'étape.
• Ne mets pas d'image inventée ou quelconque à la place d'une image réelle manquante : laisse l'espace réservé.
• Chaque scène a sa propre illustration et sa propre chorégraphie, et change à chaque étape.
• Chaque présentation a sa propre identité, conçue pour son sujet : son monde, sa palette, ses typographies et sa peau. La palette, les typographies et l'aspect par défaut ne sont pas un choix.
• Ne modifie jamais assets/ pour une présentation particulière : le visualiseur et le kit sont communs à toutes.