Humanize PPT

Que fait Humanize PPT ?

Utilisez cette compétence lorsque l'utilisateur souhaite transformer du matériau brut, des notes, des transcriptions vocales, des documents ou des liens en un plan prêt à présenter et en décisions média par page avant de déléguer le rendu à une compétence en aval. Les anciens fichiers PPT/PPTX ne sont pas lus directement : extrayez d'abord leur texte (voir la sortie dump/inspect de scripts/pptx_qa.py), puis passez ce texte comme --source. Un deck déjà rendu par Humanize PPT passe par --qa-from <rendered.pptx> à la place — le checkup de présentation, pas le mode brief.

Positionnement

Humanize PPT est un système de présentation, conçu pour le discours : un Directeur de Plan (AST audience-state-transfer — chaque changement de diapositive fait avancer le public), un Directeur d'Amélioration Visuelle par Page (image réelle / diagramme SVG / vidéo Remotion), un Orchestrateur de Brief de Production, un Exécuteur de Checkup de Présentation (演讲体检 ; anciennement la boucle QA, le drapeau CLI reste --qa-from), et un Passage en Mode Présentateur. La motivation : les compétences de modèles HTML-PPT excellent pour l'affichage de concepts mais transforment une idée simple en une douzaine de belles pages, alors qu'un vrai discours de 90 minutes en compte ~30 — la belle coquille dépasse la densité du contenu. Humanize comble cet écart : il conserve la beauté (rendue nativement par la compétence de modèle en aval) et la rend présentable — un fil conducteur que l'on peut défendre debout. Les compétences de modèles en aval possèdent « rend magnifiquement » ; Humanize possède « c'est un discours, et quelqu'un l'a vérifié ».

Le checkup de présentation en une phrase : il ne note pas la beauté, il note le plan. Il compare chaque page rendue à sa page de plan, extrait les pages qui ne peuvent être que regardées mais pas prononcées, et continue jusqu'à ce que chaque page soit présentable par l'orateur. Une page échouée, en termes clairs : une page qui ne contient que quelques mots et ne termine jamais son idée, ou une page qui ne réalise pas le transfert d'état d'audience promis (l'auditeur sort de cette page dans le même état qu'il y est entré). Une telle page ne devrait pas exister ; le checkup l'extrait et génère des instructions de correction.

Humanize est largement compatible avec les rendus en aval capables de consommer du markdown simple + JSON. Les routes vérifiées sont : Chinois HTML → guizang-ppt-skill ; Anglais HTML → frontend-slides / beautiful-html-templates ; PowerPoint modifiable natif → ppt-master. D'autres rendus restent branchables à chaud ; les niveaux de support se trouvent dans registry/renderer_registry.json et évoluent uniquement sur la base de sorties réelles.

Il s'exécute avant les compétences de diapositives PPT / HTML en aval et autour du checkup de présentation après rendu. Il possède le contrat AST, la décision média par page (cette page a-t-elle besoin d'une photo, d'un diagramme système, d'un clip de processus de 10 secondes, de rien ?), le brief de production que l'agent suivant consomme, et le passage de checkup sur le HTML/PPTX rendu. Il ne possède pas le deck rendu lui-même.

Il existe deux points de révision humaine avant le rendu : la prévisualisation du plan et la porte de style du rendu. Les routes HTML utilisent la --style-gallery de Humanize avec ≥4 couvertures réelles. PPT Master possède déjà une interface de confirmation obligatoire en trois étapes avec des prévisualisations visuelles natives, donc --renderer ppt-master --style-gallery délègue à cette porte et écrit style_gallery_plan.json + commands/style-gallery/ppt-master-confirm-ui.md plutôt que de dupliquer le catalogue.

L'utilisateur appelle Humanize PPT une fois pour le brief, remet le brief à une compétence en aval pour le rendu natif, puis rappelle Humanize avec --qa-from <rendered.html|native.pptx> pour exécuter le checkup de présentation en 3 itérations. Chaque itération écrit qa_report.md, fix_prompt.md et qa_iteration.json. Après 3 tours avec des échecs restants, le statut passe à needs-human.

Humanize PPT ne copie jamais le modèle d'une compétence en aval, n'injecte jamais de sections personnalisées dedans, et ne post-traite jamais le HTML ou le PPTX rendu. Les corrections retournent à la source de l'auteur en aval. Voir references/guizang-production-brief-orchestrator.md et adapters/ppt-master-bridge-notes.md.

Pour le positionnement public, décrivez Humanize PPT comme un orchestrateur de brief qui s'associe à des rendus natifs en aval. Ne le présentez pas comme un rendu lui-même, et ne le présentez pas comme un « routeur » qui choisit le meilleur style visuel pour l'utilisateur — cette décision réside dans le brief, les modèles propres de la compétence en aval et la révision humaine. Lorsqu'un utilisateur ne veut qu'une belle page de modèle, c'est un travail de compétence de rendu, pas un travail de Humanize : énoncez le choix, pas une interdiction.

Théorie AST

AST signifie Audience-State-Transfer (Transfert d'État d'Audience).

• Audience : qui écoute, ce qu'ils savent, ce qu'ils résistent, et pourquoi ils continueraient à écouter.
• État : l'état du public avant et après le deck, plus la tension centrale qui bloque la transition.
• Transfert : le chemin diapositive par diapositive qui déplace le public de l'état initial à l'état souhaité.

Phrase centrale :

PPT n'est pas un contenant d'information. PPT est un artefact de transfert d'état d'audience.

Contrat de sortie requis

Pour chaque exécution de Humanize PPT, produisez :

1. deck_brief.md — audience, objectif, tension, critères de succès.
2. ast_outline.md — carte AST et arc narratif.
3. slide_plan.json — plan diapositive par diapositive, avec décision media: {image, diagram, video} par page et layout_hint.
4. speaker_intent.md — ce que l'orateur doit faire sur chaque diapositive. Les compétences en aval consomment cela comme source pour leurs notes d'orateur natives et leur coque de présentateur.
5. asset_manifest.md — décisions matérielles par page de Humanize : quelle page a besoin de quel type d'actif (image / diagramme / vidéo) et dans quel but.
6. video_slots.json — plan d'insertion vidéo Remotion / HyperFrames / natif optionnel.
7. style_brief.md — principe visuel pour la production en aval.
8. renderer_registry.json — instantané des capacités du rendu pour cette exécution.
9. router_plan.json — rendu primaire sélectionné et plan de route par étapes.
10. commands/*.md — instructions limitées pour chaque agent spécialiste en aval.
11. run_manifest.json — inventaire final des fichiers, statut de la route et statut QA.
12. <renderer>-production-prompt.md — le point d'entrée en aval. En plus des routes HTML, ppt-master émet ppt-master-production-prompt.md + ppt-master-source.md autonome et des copies jetables outputs/ppt-master-handoff/.
13. outputs/qa/qa_report.md — porte QA de premier passage (mode brief) ou résultats QA par itération (mode QA).

Le mode QA (post-rendu) produit en plus par itération :

14. outputs/qa/fix_prompt.md — instructions de correction exploitables par la compétence en aval.
15. outputs/qa/qa_iteration.json — numéro de tour, statut (iterate / pass / needs-human), résultats non résolus, historique.

Le mode galerie de styles (--style-gallery, porte pré-plan) produit à la place et s'arrête :

16. Routes HTML : style_gallery.html plus ≥4 entrées de couverture. PPT Master : pas de fausse galerie HTML ; la sélection de style reste dans son interface de confirmation native.
17. style_gallery_plan.json — candidats de couverture pour HTML ou mode: downstream-confirm-ui pour PPT Master.
18. commands/style-gallery/<id>.md — commande de couverture pour HTML, ou ppt-master-confirm-ui.md pour la porte native.

Workflow OPC recommandé (v0.6.4)

O — Plan + Direction Média par Page
  Humanize PPT : matériau brut → plan AST + décision média par page
  (deck_brief.md, ast_outline.md, slide_plan.json, speaker_intent.md,
   asset_manifest.md, video_slots.json, style_brief.md)

P — Invocation du Rendu Natif (100% en aval)
  zh  → guizang-ppt-skill        (Style A ou B, natif ; recommandé)
  en  → frontend-slides / beautiful-html-templates (natif ; recommandé)
  pptx → ppt-master (natif DrawingML ; explicite --renderer ppt-master)
  autres compétences HTML-PPT → branchables à chaud, même contrat de brief
  Humanize émet le prompt de production et s'arrête. La compétence
  en aval rend le deck. Humanize ne COPIE PAS les modèles, ne
  injecte PAS de remplacements SLIDES_HERE / [必填], n'ajoute PAS
  de ponts postMessage au HTML rendu.

Q — Checkup de Présentation (演讲体检) sur l'artefact rendu
  Humanize --qa-from <rendered.html|native.pptx> lit la sortie de P,
  compare les pages au plan, scanne les modes d'échec
  (references/qa-failure-modes.md), écrit qa_report.md et
  fix_prompt.md, suit l'itération dans qa_iteration.json.
  Limite : 3 tours. Après la limite avec des résultats restants, le statut
  passe à needs-human.

C — Complétion / Contrôle
  Notes d'orateur natives de la compétence en aval + coque de présentateur + déploiement
  (Humanize ne possède pas ces éléments dans v0.6.4 — le brief dit au
  prochain agent de les produire dans le format propre de la compétence en aval)

Règles

Invariants v0.6.4 (ce sont les règles strictes ; si vous en enfreignez une, vous sortez de la limite v0.6.4)

1. Humanize est uniquement un brief. Il écrit le contrat de production du rendu et s'arrête. Il n'ouvre, ne copie ni ne post-traite les modèles en aval ou le HTML/PPTX final.
2. Les rendus en aval sont 100% natifs. L'agent suivant suit le SKILL.md propre à la compétence en aval. Le brief dit à l'agent suivant quelle compétence charger, quel Style (A/B) utiliser, quelles mises en page choisir et quelles portes QA doivent passer — mais il ne transporte pas les internes du modèle.
3. Le checkup de présentation est limité à 3 itérations. Le tour 4 avec des résultats d'échec restants est needs-human. La boucle ne tourne pas indéfiniment ; elle rend la décision à un humain.
4. Notes d'orateur et coque de présentateur — Humanize produit une presenter-shell.html de base ; le rendu en aval possède la scène complète. Humanize possède la source sémantique (speaker_intent.md) et écrit maintenant aussi outputs/presenter/presenter-shell.html directement à partir de slide_plan.json + speaker_intent.md (utilisable de manière autonome, même avant l'existence du deck en aval). La compétence en aval produit les notes d'orateur natives et la console de présentateur plus complète. Humanize n'injecte pas de ponts postMessage ni de paramètres d'URL ?slide= dans le HTML rendu.
5. Le prompt de production est le point d'entrée en aval. Il nomme chaque artefact de support que le rendu doit lire. PPT Master lit en plus ppt-master-source.md, qui fige l'histoire de la page Humanize et l'intention des notes sans dupliquer les contrats visuels de PPT Master.

Règles de travail

6. Ne laissez pas les rendus de diapositives consommer directement le matériau brut lorsque Humanize PPT peut d'abord produire le contrat AST.
7. Gardez la compétence en aval comme propriétaire de la vue scène complète ; presenter-shell.html de Humanize est une base fonctionnelle, pas un remplacement des consoles natives.
8. Absorbez les principes de nettoyage de l'écriture AI des outils d'humanisation, mais ne réduisez pas Humanize PPT à un polissage de texte.
9. Préférez un petit workflow vérifié à une large promesse non vérifiée.
10. Pour les versions publiques de Skill, créez/poussez le dépôt, installez depuis GitHub localement, exécutez un exemple complet sûr, vérifiez le brief + le checkup sur le point de contrôle connu (examples/03-codex-guizang-native-ink-classic/), et seulement ensuite peaufinez les détails du README.
11. Pour le développement d'équipes d'agents, émettez router_plan.json, run_manifest.json, des commands/*.md limités, et le prompt de production par rendu avant de câbler les vraies compétences en aval.
12. Pour les packages de téléchargement d'équipe WorkBuddy/CodeBuddy, ne packagez pas de démo ou de sorties HTML rendues comme le zip d'équipe. Le zip de téléchargement doit refléter une structure de plugin d'équipe comme trading-team : à la racine .codebuddy-plugin/plugin.json, agents/, skills/, rules/, et setting.json (plus avatars/, .workbuddy-plugin/, README.md, settings.json optionnels). Le répertoire rules/ doit inclure un fichier de règles de scénario tel que rules/<plugin-name>_rules.md avec frontmatter (description, alwaysApply, enabled, updatedAt, provider) et un bloc <system_reminder> décrivant les agents, compétences, SOP et exigences d'utilisation disponibles. Vérifiez avec unzip -l que la racine n'est pas index.html/assets/screenshots/source et n'est pas enveloppée dans un dossier sauf si le téléchargeur cible l'exige explicitement.
13. Ne traitez pas les vidéos HyperFrames/Remotion comme un seul lecteur intégré qui remplace le contenu PPT. Pour les livrables Humanize PPT, les outils vidéo sont des producteurs de matériel : transitions, clips explicatifs, comparaisons avant/après, inserts de matériel de parole, aperçus sociaux et images de repli qui remplissent des besoins spécifiques de diapositive. La décision media.video par page (voir le schéma slide_plan.json) indique à la compétence en aval quelles pages veulent un clip Remotion, dans quel but et à quelle durée.

Références opérationnelles

• references/guizang-production-brief-orchestrator.md — spécification canonique du brief : ce que <renderer>-production-prompt.md doit et ne doit pas contenir.
• references/qa-failure-modes.md (+ miroir anglais references/qa-failure-modes.en.md) — catalogue des modes d'échec pour le checkup de présentation ; la source de vérité côté code est FAILURE_MODES dans scripts/humanize_ppt_v2.py.
• references/style-gallery-spec.md — la porte de style de couverture --style-gallery.
• references/renderer-guidance.md — chemins recommandés par rendu et règles du point de contrôle connu.
• references/renderer-verification.md — preuves de vérification par rendu derrière les résumés du frontmatter.
• adapters/ppt-master-bridge-notes.md — limite de la route PPTX native et contrat de checkup OOXML.
• SPEC.md — spécification technique du moteur : surface CLI, flux de données, contrat de sortie, galerie de styles, checkup, modèle média, registre des rendus.
• Index complet annoté de toutes les références, adaptateurs, notes de version et scripts d'aide : docs/index.md.

Démo locale

Le point d'entrée stable recommandé est scripts/humanize_ppt.py (les scripts versionnés restent comme des shims de compatibilité). Des exemples CLI complets — mode brief, checkup de présentation, PPTX natif, prévisualisation du plan, points d'entrée hérités — se trouvent dans docs/local-demo.md.

Avertissement --out : pointez --out vers un répertoire d'exécution dédié. Le mode brief le reconstruit de zéro à chaque exécution, mais ne l'efface automatiquement que lorsqu'il est manquant, vide, ou déjà une ancienne exécution de Humanize PPT (run_manifest.json / style_gallery_plan.json / outline-preview.md / preview-confirmed.json à sa racine) — sinon il refuse et demande --force.