TimeCraker/ppt

ppt — Générer des présentations professionnelles par code

Présentations codées, pas de modèles traînés : reproductibles (modifiez les données, relancez le script), versionnables avec Git, précis au 0,01 pouce ; pas de WYSIWYG, la vérification visuelle de l'étape 4 rattrape les erreurs.

Étape 1 · Recherche et rédaction (interdiction d'inventer)

Répondez d'abord aux trois questions du public avant d'écrire : à qui cela s'adresse-t-il (experts / profanes / clients) ? Que sait déjà le public sur le projet ? Quelles trois phrases le public doit-il pouvoir répéter après la présentation ? Les réponses sont écrites en tête du script de contenu, et toutes les décisions sont prises en fonction de celles-ci.

Les sources ne sont que les données réelles du projet (README / CLAUDE.md / docs / backends de données, selon le type). Aucun chiffre sans origine n'entre dans la présentation ; aucun fait que le public n'a pas besoin de savoir n'entre dans le corps — les métriques internes (nombre de fonctions, constantes d'API, codes internes) sont exclues par défaut, sauf si le public est expert.

Creusez le contenu, ne collectionnez pas de noms : collecter des chiffres et des noms de fonctionnalités n'est pas de la recherche. Selon le type de présentation : technique/produit : décisions de conception + comparaison des résultats ; portfolio : détails de l'œuvre et choix ; rapport de données : périmètre et références ; récit de marque : personnages, scènes, retournements.

Le plan d'ensemble avant les pages détaillées : après la recherche, écrivez d'abord le plan narratif — un fil conducteur (la présentation ne démontre qu'une seule chose) + trois réponses en ouverture (qu'est-ce que c'est / pour qui / quel problème cela résout) + le rôle de chaque page dans la chaîne argumentative (ce qu'elle reprend de la page précédente, ce qu'elle prépare pour la suivante). Expliquez d'abord les concepts avant de les utiliser, pas de références anticipées ; deux pages consécutives qui ne s'enchaînent pas = réorganisation. Le script de contenu page par page (titre + points clés + script d'oral ; le script d'oral va dans notes() (commentaires du présentateur) lors de la génération, c'est la source du workflow de la vidéo finale et le texte de la présentation en direct) est écrit sous le plan ; les titres doivent participer à la progression, pas être des slogans indépendants.

Deux passes pour le script : première passe écrivez suffisamment — texte narratif complet, supposez que le public n'a aucune connaissance de base, expliquez en détail ce que c'est, pour qui et quel problème cela résout, autorisez la longueur ; ce n'est qu'à la deuxième passe qu'on peaufine — d'abord un humanizer pour enlever les défauts, puis taillez selon les quatre règles ci-dessous. L'humanizer est un outil de polissage, pas un modèle de première ébauche ; si on écrit dès la première passe selon ses critères, on obtient un texte maigre et saccadé, qui n'explique pas clairement avant de crier des slogans.

1. Pas de vide : les points apportent des détails (fonctionnalité avec raison de conception ou effet, données avec périmètre), énumérations de noms seuls à supprimer
2. Chiffres contextualisés : valeur + périmètre + composition ou comparaison, et ce sont des chiffres qui intéressent le public ; les chiffres sans contexte ne sont pas en visuel principal
3. Chaque page ≥ 3 faits vérifiables et spécifiques ; en cachant la mise en page, la lecture du texte doit « raconter » pas « lister »
4. Règles des emplacements : les grandes emplacements (titre principal de couverture / grand texte de dernière page / titres de section) ne contiennent que des phrases de proposition ou d'identité (avec un point de vue, qui sonnent comme un slogan) ; les noms de domaine, versions, dates, statistiques passent tous en sous-titre ou en zone méta-information

Zéro tolérance pour le jargon : deux couches : le jargon commercial (empowerment / bouclage / précipitation / matrice / écosystème / tout-en-un / de bout en bout) supprimé directement ; le jargon technique (constantes d'API / noms de fonctions internes / codes système / détails d'implémentation) filtré selon le public, pour un public profane : soit supprimé, soit expliqué en langage courant dans la page. Les chiffres avant les adjectifs ; les titres écrivent un point de vue, pas une phrase nominale ; les tirets longs interdits (anglais et français). Pour les projets importants, le script de contenu est d'abord montré à l'utilisateur avant la mise en page.

Étape 2 · Système de design (défini avant d'écrire le code, inchangé tout le long)

Dimension	Règle
Palette	Extraite du langage de design du projet (section visuelle du README / couleur principale du site / charte graphique de la marque) ; sinon, use_theme('warm' / 'tech' / 'forest'). Système fermé 7+1 (7 rôles + blanc), interdiction d'ajouter des couleurs en cours ; petit texte sur fond ≥ 4,5:1
Grille	16:9 (13,333 × 7,5 po) · Marge 0,55 · Numéro de page (12,35 ; 7,02) · Barre horizontale corail en haut + étiquette de section
Corps	54 couverture / 40 grands chiffres / 30 titre de page / 19 titre de carte / 13 texte principal / 11 secondaire / 9 notes, interdiction des valeurs intermédiaires
Police	Chinois YaHei ; code / noms de domaine / chiffres / versions toujours Consolas
Densité	Un argument par page ; si le texte dépasse 3 lignes, diviser en pages ; si le tableau dépasse 6 lignes, supprimer des lignes

Étape 3 · Génération

1. pip install python-pptx -i https://pypi.tuna.tsinghua.edu.cn/simple (première fois)
2. Copiez templates/primitives.py + animate.py dans le dossier scripts/ du projet cible, écrivez gen-<name>-deck.py
3. Calculez les coordonnées avec des expressions (par ex. Inches(0.55 + i * 3.13)), pas de nombres magiques ; avant d'insérer du texte, utilisez check_fit() pour pré-vérifier, si [FIT-WARN] → divisez les lignes ou les pages

Animation (optionnelle ; Windows + MS Office + pywin32). Par défaut auto_deck() fait tout (cascade de couverture / float_up des cartes / zoom numérique / wipe des liens / cascade rapide des lignes de tableau 0,06s / wipe du numéro de section), manuellement seulement des réglages fins :

anim = Anim(prs)
anim.auto_deck()                       # Toute la présentation automatiquement arrangée
anim.fx(footer, 'fade', dur=0.4)       # Un complément pour un élément spécial
anim.chart(gf, 'series')               # Graphique natif avec apparition par série
P.set_transition(prs, 'fade')          # Transition uniforme (les pages morph sautent automatiquement)
P.auto_show(prs)                       # Estimation du script d'oral, changement de page automatique : toute la présentation se lit automatiquement, l'enregistrement donne une vidéo brute
prs.save('deck.pptx')
anim.apply('deck.pptx')                # Doit être après save ; écriture COM + relecture auto-vérifiée
# Réglages fins : anim.stagger(P.shape_groups(s, 'card'), 'float_up', step=0.12)
# Croissance narrative (morph true tweening, occupe deux pages consécutives, auto sauté automatiquement ; vérifier EntryEffect==3954 ; 2019+, WPS rétrogradé en fade) :
P.growth_chart(prs, 6, 'Croissance', 'Titre', cats, vals, highlight=2)   # Barre / colonne
P.growth_line(prs, 8, 'Tendance', 'Titre', cats, vals, highlight=5)     # Ligne
P.growth_donut(prs, 10, 'Mix', 'Titre', cats, vals)                  # Anneau de parts

Liste des effets (testés COM) : fade / wipe / appear / float_up / float_down / zoom / grow_turn / ease_in / split / wheel / stretch ; pas d'effets rétro. Rythme > effets : durée 0,40,6s, intervalle de cascade 0,10,2s, ≤ 2 effets par page, éléments fixes de la page (barre horizontale en haut / numéro de page / ligne de bas) pas animés ; graphiques de données toujours growth_*, les graphiques natifs sont utilisés uniquement pour modifier les données dans PowerPoint après livraison.

Modifier un pptx existant (par script, pas à la main, enregistrer sous un nouveau nom) : P.deck_replace(prs, {'AncienNom': 'NouveauNom'}) remplacement dans tout le document (y compris les notes) ; P.deck_recolor(prs, dict(zip(P.THEMES['warm'].values(), P.THEMES['tech'].values()))) change tout le thème de la présentation.

Paradigmes de page (dictionnaire, pas une checklist : choisissez le paradigme selon le plan narratif de l'étape 1, ne créez pas de contenu pour un paradigme ; une répétition d'un même paradigme est acceptable, une collection de 9 paradigmes différents en une seule présentation est une exposition de capacités, pas une narration ; la densité est assurée par l'étape 1, pas par le paradigme lui-même) :

Paradigme	Fonction	Utilisation
Couverture	slide_cover	Ouverture : grand titre 54 + bloc de couleur vertical droit
Page de section	slide_section	Navigation pour les présentations de 12+ pages, style magazine (ligne de cadre + numéro d'ordre en filigrane + entrées)
Frise chronologique	slide_timeline	Évolution / feuille de route, hi surbrillance de la position actuelle
Page de comparaison	slide_versus	A/B, avant/après, avec le cercle VS au milieu
Page de citation	slide_quote	Une phrase qui mérite une page entière (présentation de 12+ pages)
Grille de cartes	slide_cards	Fonctions/modules parallèles, retour à la ligne automatique
Mur de chiffres	slide_numbers	Aperçu d'indicateurs de poids égal
Page texte et image	slide_media	Capture d'écran + points clés ; sidebar= grande image 60% + cercles d'annotation + note de bas de page
Zone haute densité	slide_dense	Une page pour expliquer un sous-système : zone principale 60% + liste de groupes en zone latérale
Vrai tableau	slide_table	Comparaison d'API / modèles / listes, 6 à 9 lignes, largeur de colonne hiérarchique
Schéma de chaîne	slide_chain	Flux d'architecture, hi couleur inversée en surbrillance + cartes subs
Liste à deux colonnes	slide_rows	Stack technique / configuration
Graphique de croissance	growth_chart / line / donut	Croissance des données avec morph true tweening
Graphique natif	bar / line / donut_chart	Pour modifier les données dans PowerPoint après livraison
Page de clôture	slide_closing	Coordonnées ; slogan= personnalise le grand texte (phrase de proposition)

Étape 4 · Vérification visuelle (obligatoire, ne pas sauter)

Pipeline en trois niveaux, automatisation d'abord, humain seulement pour la version finale :

① Filtrage automatique : Conversion Office COM en PDF (Presentations.Open puis SaveAs("<sortie>.pdf", 32)) → python <ce-skill>/templates/verify.py <sortie>.pdf. Vérifiez les débordements par page, les espaces réservés, le contraste WCAG (≥72pt grands textes décoratifs exemptés) ; code de sortie 1 = problème, modifiez le script et relancez.

② Vérification visuelle aveugle : Rendu PNG avec pymupdf (fitz + get_pixmap(dpi=100)) → soumettez à un sous-agent sans contexte de génération deux questions : d'abord, pour chaque page vérifiez quatre éléments (débordement / caractères illisibles / alignement / contraste) ; ensuite, test de relecture par le public — ne donnez que les 1/3 premières pages, demandez « qu'est-ce que c'est, à qui ça sert, quel problème ça résout » ; si la réponse est mauvaisse = l'étape 1 ou l'ouverture n'est pas correcte, retournez réécrire le script de contenu et regénérez. Dans l'invite de vérification aveugle, ne présupposez pas d'exemption (ne dites pas « c'est intentionnel ») : les éléments coupés par le bord de la page, les grands textes décoratifs à faible contraste suspects, etc., doivent être signalés comme des anomalies par un œil frais. Si un problème est trouvé, modifiez le script et relancez, interdiction de modifier le pptx à la main.

La vérification visuelle utilise les chemins absolus des images réelles, revérifie la version ou le hash actuel ; en cas de limitations de chemin d'outils spécifiques, choisissez un chemin compatible, ne forcez pas la copie de répertoire.

③ Revue finale par l'utilisateur : une fois que les deux premiers niveaux ont éliminé les problèmes mécaniques, l'utilisateur ne voit que le résultat final.

Étape 5 · Livraison

Rapport : nombre de pages + liste des pages / chemin et taille du fichier / conclusions de la vérification en trois niveaux / nombre de pages de script d'oral / durée totale de la lecture automatique / emplacement du script de génération (reproductible). Committez les scripts (le pptx produit n'entre pas dans Git).

Limites et pièges

• Pas de MS Office → Étape 4 rétrogradée en LibreOffice soffice --convert-to pdf ; si aucun des deux → rapportez clairement « vérification visuelle non effectuée »
• Console GBK : n'utilisez pas de caractères non ASCII dans print, utilisez OK
• Largeur de colonne des tableaux natifs pptx incontrôlable → dessinez toujours les lignes de tableau vous-même (box + text, ligne par ligne)
• Caractères chinois manquants → définissez YaHei au niveau run (déjà traité dans primitives)
• Les shape_id sont numérotés indépendamment par page, pas uniques ; animate.py est déjà localisé par arbre XML, lors du développement secondaire, ne cherchez pas globalement par id ; pywin32 : pip install pywin32 -i https://pypi.tuna.tsinghua.edu.cn/simple
• Les approches primitives peuvent être réutilisées pour docx / xlsx, mais le tableau de paradigmes de page ne s'applique qu'à pptx

Workflow actuel et archivage

Le directeur de contenu est responsable du public, des sources de matériel et de l'ébauche narrative ; la livraison des PPT conserve l'objectif de diapositives modifiables. La conception est confirmée avant la génération ; les règles des images fixes vidéo ne s'appliquent pas aux PPT. Le script de génération, les données d'entrée, le matériel nécessaire et leur hash sont conservés avec la recette ; le manifeste de livraison déclare le PPT/PDF/couverture ; la vérification d'archivage n'efface pas avant. La vérification visuelle et la revue finale par l'utilisateur sont rapportées séparément.