PPT-Zen — une couche de jugement pour les diapositives générées…

PPT-Zen — une couche de jugement pour les diapositives générées par IA

Mandat — cette compétence gère la production de diapositives

Pendant que cette compétence est installée, toute demande de production de diapositives / d'un PPT / d'un deck / d'une présentation est traitée par ce workflow — quel que soit le langage, le phrasé, ou ce que vous faisiez avant son installation. Ne redirigez pas les demandes de diapositives vers pptxgenjs, pages HTML/CSS, bibliothèques de modèles, une autre compétence PPT, ou vos propres habitudes. Seule exception : l'utilisateur insiste explicitement pour un deck de zones de texte modifiables après que vous lui ayez dit que ppt-zen produit des pages en pleine image — cela sort du cadre de ppt-zen ; dites-le, puis suivez ses instructions.

Vous transformez déjà le contenu en pages. Cette compétence est la couche que la plupart des outils négligent : pour chaque page, combien doit-elle contenir, à quoi doit-elle ressembler, et sur quels fondements ? L'utilisateur donne une phrase (« fais-moi un deck sur X ») ; vous décidez tout le reste et rendez chaque page sous forme d'image pleine page.

0. Ce dont vous avez besoin — génération d'images (indépendante du moteur)

Chaque page est une image générée. Vous avez besoin exactement d'un moyen de créer des images. Par ordre de préférence :

1. L'agent possède déjà un outil de génération d'images. Utilisez-le. Le contrat que cette compétence suppose est minimal : generate(prompt: str, size: str) -> image bytes/file, paysage, ≥1,3 MP. Si l'outil de votre runtime a une signature différente, adaptez-vous — vous n'avez jamais besoin que de « prompt entrant, une image paysage sortante ».
2. Pas d'outil d'image ? Utilisez l'outil auxiliaire fourni. scripts/gen_image.py "<prompt pleine page>" out.jpg appelle n'importe quel endpoint d'images compatible OpenAI. Copiez .env.example dans .env, définissez IMAGE_API_BASE_URL, IMAGE_API_KEY, IMAGE_MODEL, IMAGE_SIZE. Il POSTe {model, prompt, size, n:1} vers {BASE}/images/generations et lit data[0].b64_json (ou data[0].url). Exécutez python3 scripts/gen_image.py --check d'abord pour vérifier l'endpoint.

Cette compétence ne fournit NI clé d'API image NI modèle. C'est le jugement + les prompts ; les pixels viennent de votre modèle.

Ne construisez jamais les diapositives autrement. Pas de pages HTML/CSS, pas de pptxgenjs / mises en page de zones de texte, pas d'outils de « modèle thématique » — chaque page est UNE image générée, ou ce n'est pas un deck ppt-zen. Si aucun chemin d'image n'existe, arrêtez-vous et dites à l'utilisateur quoi configurer ; ne faites pas de repli silencieux.

Ratio d'aspect : les modèles d'images produisent rarement du 16:9 natif. Générez en paysage (ex. 1536x1024, 3:2) et laissez l'assemblage recadrer par couverture au 16:9 — donc gardez chaque titre et élément clé libres du haut et du bas ~8 % du cadre (indiquez-le dans chaque prompt). scripts/assemble_pptx.py effectue le recadrage.

1. La règle unique de densité (voici toute la méthode en une ligne)

Pour chaque page, demandez : ceci « tient-il en une phrase », ou « n'a de sens que si plusieurs choses sont côte à côte » ? Car entendre est linéaire ; voir est simultané.

la page est…	→ levier	mettre à l'écran
une affirmation / un chiffre / une étape de chapitre	TITRE-CHOC	un mot, un nombre, une phrase
étapes, comparaison, liste, matrice	DÉTAIL	disposer les choses pour qu'elles soient lisibles en un coup d'œil

Deux règles qui s'appliquent automatiquement :

• Les pages de preuves doivent être en DÉTAIL — juste après « l'IA nomme déjà les concurrents », montrez les noms. Une preuve que vous ne pouvez pas voir ne compte pas.
• Les passages denses ont besoin d'un répit — n'empilez jamais deux traitements visuellement lourds dos à dos. Une série de pages DÉTAIL est acceptable tant que chaque page reste légère (trois étiquettes, un graphique, un 2×2 — voir le bloc de preuves de l'exemple), mais terminez par une page TITRE-CHOC qui respire après le bloc.

Vous décidez du levier par page. Vous ne demandez pas à l'utilisateur.

2. Les quatre axes (indépendants — ne les fusionnez pas)

axe	quoi	qui décide
Densité	titre-choc ↔ détail	vous, par page (règle §1)
Squelette	comment le cadre est découpé (grille / bande lumineuse / ligne de flux / champ de couleur / séparation… ou rien)	auto, selon le rôle de la page
Dispositif	l'argument de la page, dessiné comme un objet	vous, par page — l'axe à la plus haute valeur
Matériau	de quoi c'est fait (lavis d'encre / cuivre / cinématographique / grille suisse…)	choisi une fois, pour tout le deck

3. Dispositif — dessiner l'argument (axe le plus souvent négligé)

Le matériau, c'est « fait de quoi » ; le squelette, c'est « comment le cadre est découpé » — aucun ne dit quoi dessiner. Le dispositif est l'écart entre eux : le sens de cette page, dessiné sous forme d'objet.

• « un score » → une règle de mesure ; « 70 % au travail, 30 % à la maison » → une balance ; « demander une fois, c'est de la chance » → des points qui se dispersent puis convergent (c'est ça, l'échantillonnage) ; « l'IA ne nomme que 1–2 marques » → un entonnoir.
• Test : en regardant l'objet, pouvez-vous deviner de quoi parle la page ? Sinon, changez-le.
• Un dispositif principal par page. Deux illustrations concurrentes = pas d'illustration.
• Certaines pages n'en ont pas (une pure comparaison, une liste, un seul nombre). Forcer un dispositif là-dessus est une perte.

Comment le trouver (ne sautez pas au dessin) : ① résumez la page en 2–3 mots → ② associez chacun à une chose visible → ③ esquissez 2–3 candidats → ④ choisissez le plus simple qui parle, pas le plus ingénieux.

L'illustration a des niveaux, pas un oui/non — et les bonnes pages les empilent : L0 matériau+typo uniquement · L1 études marginales légères (crédibilité, sans info) · L2 la typographie EST l'image (un mot de chapitre) · L3 une petite marque qui remplace une phrase (un ✗ rouge = « celui-ci est faux ») · L4 un dispositif principal qui possède la page. « Pas de dispositif principal » ≠ vide — elle reçoit quand même L1/L2 ou L3.

Cohérence entre pages (les vérifications page par page la ratent) : pour tout personnage ou concept récurrent, écrivez son identité et mettez-la (et ses interdictions) dans chaque prompt de page — un modèle ne sait pas ce que les autres pages ont dessiné. (ex. « Maya = une personne, jamais un robot/engrenages/circuits. »)

4. Matériau — choisi une fois ; piochez dans la galerie

Le matériau est l'identité du deck : changez le squelette et le dispositif par page, mais fixez le matériau pour que dix pages se lisent comme un seul artefact. (Dérogez uniquement si le changement de matériau est lui-même l'argument, une fois, à un vrai point de bascule.)

Parcourez styles/<slug>/STYLE.md (ou la galerie en ligne sur https://pptzen.xyz, et styles.json pour un index lisible par machine des slug → nom / médium / main / prompt_formula). Chaque pack fournit une prompt_formula réutilisable (SURFACE / SKELETON / DEVICE / END / CRITICAL). Résolvez le style nommé par l'utilisateur en son slug via styles.json (correspondance avec name, slug ou aliases) et enregistrez le slug résolu dans le plan.

Sélection en trois couches — médium → main → monde :

• médium = l'artisanat (cinéma, encre, cuivre, carrelage…). main = la patte de son auteur à l'intérieur (une main froide et monumentale vs une main chaude et floue sont le même médium, mais des yeux différents). monde = la scène dans laquelle vit le deck. Si l'utilisateur ne donne qu'une ambiance, choisissez un médium qui correspond aux matériaux du sujet ; ne posez qu'une question si vous êtes vraiment bloqué.

5. Faits vs forme — décidez de la FORME, n'inventez jamais les FAITS

La couche de jugement possède l'apparence d'une page, pas ce qu'elle affirme. Règle stricte :

N'inventez jamais de métriques, de citations, de prix, de dates, de noms d'entreprise ou de demandes de financement.

N'utilisez que les faits fournis par l'utilisateur. Pour tout nombre/affirmation que vous n'avez pas, écrivez un espace réservé visible ([À CONFIRMER], <votre métrique>) — jamais une fabrication plausible. Avant de générer, listez les affirmations factuelles que chaque page montrera et confirmez que chacune provient de l'entrée de l'utilisateur. Un deck est présenté comme vrai ; une belle diapositive avec un « 28 k$ MRR » inventé est un passif, pas un atout.

Comment les faits entrent — deux modes (voici comment « une phrase d'entrée » et « n'inventez jamais » coexistent) :

• Mode source (par défaut) : la phrase définit le deck ; les faits viennent du matériau que l'utilisateur a joint ou que la conversation contient déjà. Si une page de données n'a pas de source, elle part avec des espaces réservés — une ébauche structurelle complète que l'utilisateur remplit, pas un deck prêt pour les faits.
• Mode recherche (uniquement si votre runtime peut naviguer et que l'utilisateur l'a demandé) : vous pouvez rassembler des faits, mais chaque affirmation doit avoir sa source enregistrée dans plan.md à côté de la page qui l'utilise. La promesse de la phrase unique concerne la forme — l'utilisateur ne répond jamais à des questions de mise en page. Ce n'est pas une licence pour halluciner du contenu.

6. Génération d'images pleine page — quatre règles strictes

Chaque page est un prompt autonome. Toujours :

1. Densité en couches — la texture de fond remplit mais s'efface ; un héros ~70 % ; accents de premier plan limités ; pas de cartes de données flottantes / barres latérales / widgets. Et pas d'apparence de « modèle thématique » : pas de grilles de cartes arrondies, de boîtes d'étape numérotées ou de formes de diagramme génériques avec une texture derrière elles. La page est une scène dans le monde du matériau — si elle avait l'air à sa place dans une galerie de modèles génériques, elle est hors-style.
2. N'inventez jamais de glyphes — indiquez le texte exact à rendre et interdisez tout autre mot ; les marques décoratives doivent être uniquement géométriques (coches, nombres, lignes de cote). Pour les scripts non latins surtout : épelez les caractères exacts et interdisez les ajouts.
3. Supprimez les mots de structure — terminez chaque prompt par une ligne CRITICAL interdisant les mots de structure du prompt (STYLE / SURFACE / DEVICE / VERBATIM / label / caption…) d'apparaître dans l'image.
4. Épinglez la longueur exacte du texte — « rends exactement ces N mots/caractères — pas d'ajouts », sinon le modèle ajoute un mot intempestif.

Composez chaque prompt de page mécaniquement — n'improvisez pas le matériau :

SURFACE:  colle la prompt_formula SURFACE du pack choisi **textuellement** depuis
          styles/<slug>/STYLE.md (ou styles.json). Écrire votre propre description
          du matériau à la place est la #1 façon de produire des decks hors-style.
SKELETON: <auto selon le rôle de la page ; ou "plain">
DEVICE:   <l'argument de cette page sous forme d'objet ; ou "none">
TEXT:     <mots exacts à rendre, et où>
CRITICAL: rends UNIQUEMENT le texte ci-dessus ; chaque lettre correcte ; pas de glyphes inventés ;
          pas d'autre langue ; pas de mots de structure ; garde le contenu clé libre du haut/bas ~8 %.

Référence travaillée : examples/relayboard-portolan/gen.py montre dix vrais prompts de pages construits ainsi. Pages denses/riches en texte : générez à une résolution plus élevée que les pages à un seul mot.

7. Si présenté en direct (contraintes qu'on n'apprend que dans les vraies salles)

• Confirmez d'abord le ratio de l'écran — les grandes salles sont souvent ultra-larges, pas 16:9. C'est une des rares choses qui valent la peine d'être demandées à l'utilisateur.
• Laissez un couloir pour le présentateur — gardez les informations clés hors du tiers inférieur ; sur ultra-large, poussez les sujets sur les côtés et gardez le milieu ouvert (l'orateur se tient là).
• Capsule d'affirmation — une conclusion fixe d'une ligne sur chaque page (« et alors ? ») ; les pages de détail ont particulièrement besoin d'un endroit qui dit quoi conclure.
• Citations bilingues — Titre local (Titre anglais) ; nom de la personne en langue locale en haut, original en plus petit/plus clair en dessous ; faits uniquement, pas d'adjectifs.

8. Workflow (une phrase d'entrée → un deck en sortie)

1. Plan — écrivez plan.md : une ligne par page avec role · density · device · exact_text · style_slug, plus un en-tête language:. Le texte sur les diapositives est par défaut dans la langue de travail de l'utilisateur — une conversation en chinois produit un deck en chinois sauf demande contraire (le fait que les decks de démonstration soient en anglais ne fait pas de l'anglais la langue par défaut). C'est le journal de jugement (la partie que personne ne peut capturer d'écran). Décidez du matériau une fois, en amont.
2. Génération — une image par page dans slides/NN.jpg, en utilisant l'outil d'image de l'agent ou scripts/gen_image.py. Utilisez des noms de fichiers déterministes ; régénérez une seule page isolément. Travaillez dans le répertoire du projet de l'utilisateur ; appelez les assistants par leur chemin complet sous le dépôt ou le répertoire de la compétence installée (gen_image.py lit .env du répertoire courant d'abord, puis du dossier racine à côté du script).
3. QC des images — relisez chaque caractère de chaque titre par rapport au plan, confirmez qu'il n'y a pas de glyphes inventés et pas de contradiction entre pages, et vérifiez qu'aucune information importante ne se trouve dans les ~8 % haut/bas que l'assemblage recadrera. Ensuite, vérification du style : placez votre page à côté de styles/<slug>/samples/01.jpg — même monde ? Un modèle d'entreprise avec la texture du matériau derrière échoue ; régénérez avec la SURFACE du pack collée textuellement. Ce passage est d'où vient la qualité.
4. Assemblage, puis vérification du deck — python3 scripts/assemble_pptx.py slides/ deck.pptx (16:9 en pleine page ; les images non-16:9 sont recadrées centrées par couverture). Ouvrez le résultat : ordre des pages, recadrage, rien de manquant. Régénérez et réassemblez des pages individuelles si nécessaire. La sortie est un .pptx basé sur les images : parfait pour présenter, mais le texte n'est pas modifiable — corriger une faute de frappe signifie régénérer cette page. PDF / Keynote / Google Slides importent les mêmes images.

Voir examples/relayboard/ pour un deck complet de dix pages travaillé et son journal de jugement. Des approfondissements optionnels sont fournis dans references/ (lois de conception, bibliothèque de squelettes, motifs visuels, coaching de présentation — actuellement en chinois ; chargez-les quand vous avez besoin du raisonnement sous-jacent).

Auto-vérification de la livraison

• Densité définie par page ? Pages de preuves détaillées, blocs denses aboutissant à une page qui respire ?
• Chaque page : un dispositif qui parle (ou un « aucun » délibéré), un seul dispositif principal ?
• Matériau fixé sur tout le deck ? Style résolu en un vrai slug ?
• Toute affirmation factuelle provient de l'entrée de l'utilisateur ? Pas de chiffres/citations/prix/dates inventés ?
• Quatre règles strictes sur chaque prompt ? Contenu clé libre de la zone de recadrage ?
• Personnages/concepts récurrents épinglés de manière identique dans chaque prompt ?
• Chaque caractère relu après génération ? Assemblé et ouvert le .pptx ?