Humanize PPT – Präsentationssystem für KI-generierte Folien

Humanize PPT

Nutze dieses Skill, wenn ein Benutzer Rohmaterial, Notizen, Sprachtranskripte, Dokumente oder Links in eine präsentationsreife Gliederung und mediale Entscheidungen pro Seite umwandeln möchte, bevor die eigentliche Darstellung an einen nachgelagerten Skill delegiert wird. Alte PPT/PPTX-Dateien werden nicht direkt gelesen: extrahiere zuerst ihren Text (siehe scripts/pptx_qa.py's dump/inspect-Ausgabe) und gib diesen Text dann als --source ein. Ein Deck, das Humanize PPT bereits gerendert hat, durchläuft stattdessen --qa-from <rendered.pptx> – die Präsentationsprüfung, nicht den Brief-Modus.

Positionierung

Humanize PPT ist ein Präsentationssystem, geboren für den Vortrag: ein Outline-Direktor (AST Audience-State-Transfer – jeder Seitenwechsel bewegt das Publikum vorwärts), ein Per-Seite Visual-Enhancement-Direktor (echtes Bild / SVG-Diagramm / Remotion-Video), ein Production-Brief-Orchestrator, ein Presentation-Checkup-Runner (演讲体检; früher die QA-Schleife, CLI-Flag immer noch --qa-from), und eine Presenter-Mode-Übergabe. Die Motivation: HTML-PPT-Template-Skills sind großartig im Konzeptanzeigen, aber sie blähen eine einfache Idee zu einem Dutzend hübscher Seiten auf, während ein echter 90-minütiger Vortrag ~30 Seiten hat – die hübsche Hülle überholt die Inhaltsdichte. Humanize schließt diese Lücke: es bewahrt die Schönheit (nativ vom nachgelagerten Template-Skill gerendert) und macht sie präsentabel – eine Zeile, die man aufstehen und vortragen kann. Nachgelagerte Template-Skills besitzen „rendert schön“; Humanize besitzt „es ist ein Vortrag, und jemand hat ihn geprüft.“

Die Präsentationsprüfung in einem Satz: sie bewertet nicht die Schönheit, sie bewertet die Gliederung. Sie vergleicht jede gerenderte Seite mit ihrer Gliederungsseite, zieht die Seiten heraus, die man nur ansehen, aber nicht vortragen kann, und wiederholt dies, bis jede Seite eine ist, die der Redner aufstehen und präsentieren kann. Eine fehlgeschlagene Seite, in klaren Worten: eine Seite, die nur ein paar Worte enthält und ihren Punkt nie zu Ende bringt, oder eine Seite, die den versprochenen Audience-State-Transfer nicht erfüllt (der Zuhörer verlässt diese Seite im gleichen Zustand, in dem er eingetreten ist). Eine solche Seite sollte nicht existieren; die Prüfung extrahiert sie und generiert Korrekturanweisungen.

Humanize ist weitgehend kompatibel mit nachgelagerten Renderern, die einfaches Markdown + JSON verarbeiten können. Verifizierte Routen sind: Chinesisches HTML → guizang-ppt-skill; Englisches HTML → frontend-slides / beautiful-html-templates; natives editierbares PowerPoint → ppt-master. Andere nachgelagerte Renderer bleiben per Plug-In anschließbar; die Unterstützungsstufen leben in registry/renderer_registry.json und bewegen sich nur auf echte Ausgabe hin.

Es wird vor nachgelagerten PPT/HTML-Folien-Skills und um die Post-Render-Präsentationsprüfung herum ausgeführt. Es besitzt den AST-Vertrag, die mediale Entscheidung pro Seite (braucht diese Seite ein Foto, ein Systemdiagramm, einen 10-Sekunden-Prozessclip, nichts?), das Production-Brief, das der nächste Agent konsumiert, und den Prüfungsdurchlauf auf gerendertem HTML/PPTX. Es besitzt nicht das gerenderte Deck selbst.

Es gibt zwei menschliche Prüfungsgates vor dem Rendern: die Outline-Vorschau und das Stil-Gate des Renderers. HTML-Routen verwenden Humanizes ≥4 echte Cover --style-gallery. PPT Master besitzt bereits eine obligatorische dreistufige Confirm-UI mit nativen visuellen Vorschauen, also delegiert --renderer ppt-master --style-gallery an dieses Gate und schreibt style_gallery_plan.json + commands/style-gallery/ppt-master-confirm-ui.md, anstatt den Katalog zu duplizieren.

Der Benutzer ruft Humanize PPT einmal für das Brief auf, übergibt das Brief an einen nachgelagerten Skill für das native Rendern, ruft dann Humanize erneut mit --qa-from <rendered.html|native.pptx> auf, um die 3-Iterationen-Präsentationsprüfung auszuführen. Jede Iteration schreibt qa_report.md, fix_prompt.md und qa_iteration.json. Nach 3 Runden mit verbleibenden Fehlern wechselt der Status zu needs-human.

Humanize PPT kopiert niemals ein Template eines nachgelagerten Skills, injiziert niemals benutzerdefinierte Abschnitte darin und verarbeitet niemals gerendertes HTML oder PPTX nach. Korrekturen kehren zur nachgelagerten Autorenquelle zurück. Siehe references/guizang-production-brief-orchestrator.md und adapters/ppt-master-bridge-notes.md.

Für die öffentliche Positionierung beschreibe Humanize PPT als einen Brief-Orchestrator, der mit nativen nachgelagerten Renderern zusammenarbeitet. Stelle es nicht als Renderer selbst dar und präsentiere es nicht als „Router“, der den besten visuellen Stil für den Benutzer auswählt – diese Entscheidung lebt im Brief, den eigenen Templates des nachgelagerten Skills und der Überprüfung durch den Menschen. Wenn ein Benutzer nur eine hübsche Template-Seite möchte, ist das ein Job für einen Rendering-Skill, nicht für Humanize: nenne die Wahl, kein Verbot.

AST-Theorie

AST bedeutet Audience-State-Transfer.

• Audience: Wer zuhört, was sie wissen, was sie ablehnen und warum sie weiter zuhören würden.
• State: Der Zustand des Publikums vor und nach dem Deck, plus die Kernspannung, die den Übergang blockiert.
• Transfer: Der Folie-für-Folie-Pfad, der das Publikum vom Ausgangszustand zum gewünschten Zustand bewegt.

Kernsatz:

PPT ist kein Informationscontainer. PPT ist ein Audience-State-Transfer-Artefakt.

Erforderlicher Ausgabevertrag

Für jeden Humanize-PPT-Lauf erstelle:

1. deck_brief.md — Publikum, Ziel, Spannung, Erfolgskriterien.
2. ast_outline.md — AST-Karte und narrativer Bogen.
3. slide_plan.json — Folie-für-Folie-Plan, mit pro-Seite media: {image, diagram, video}-Entscheidung und layout_hint.
4. speaker_intent.md — Was der Redner auf jeder Folie tun soll. Nachgelagerte Skills konsumieren dies als Quelle für ihre nativen Sprechernotizen und die Presenter-Shell.
5. asset_manifest.md — Humanizes materiale Entscheidungen pro Seite: welche Seite welche Art von Asset (Bild / Diagramm / Video) benötigt und zu welchem Zweck.
6. video_slots.json — optionaler Remotion / HyperFrames / nativer Video-Einfügeplan.
7. style_brief.md — Visuelles Prinzip für die nachgelagerte Produktion.
8. renderer_registry.json — Renderer-Fähigkeits-Snapshot für diesen Lauf.
9. router_plan.json — Ausgewählter primärer Renderer und gestaffelter Routenplan.
10. commands/*.md — Begrenzte Anweisungen für jeden nachgelagerten Fachagenten.
11. run_manifest.json — Endgültiges Dateiinventar, Routenstatus und QA-Status.
12. <renderer>-production-prompt.md — Der nachgelagerte Einstiegspunkt. Zusätzlich zu den HTML-Routen gibt ppt-master ppt-master-production-prompt.md + eigenständiges ppt-master-source.md und wegwerfbare Kopien in outputs/ppt-master-handoff/ aus.
13. outputs/qa/qa_report.md — QA-Erstbewertung (Brief-Modus) oder QA-Ergebnisse pro Iteration (QA-Modus).

Der QA-Modus (Post-Render) erzeugt zusätzlich pro Iteration:

14. outputs/qa/fix_prompt.md — Für den nachgelagerten Skill ausführbare Korrekturanweisungen.
15. outputs/qa/qa_iteration.json — Rundenummer, Status (iterate / pass / needs-human), ungelöste Befunde, Historie.

Der Style-Gallery-Modus (--style-gallery, Pre-Outline-Gate) erzeugt stattdessen und stoppt:

16. HTML-Routen: style_gallery.html plus ≥4 Cover-Einträge. PPT Master: kein simuliertes HTML-Galerie; die Stilauswahl bleibt in seiner nativen Confirm-UI.
17. style_gallery_plan.json — Cover-Kandidaten für HTML oder mode: downstream-confirm-ui für PPT Master.
18. commands/style-gallery/<id>.md — Cover-Befehl für HTML oder ppt-master-confirm-ui.md für das native Gate.

Empfohlener OPC-Workflow (v0.6.4)

O — Outline + Per-Seite Media-Richtung
  Humanize PPT: Rohmaterial → AST-Outline + mediale Entscheidung pro Seite
  (deck_brief.md, ast_outline.md, slide_plan.json, speaker_intent.md,
   asset_manifest.md, video_slots.json, style_brief.md)

P — Nativer Renderer-Aufruf (100% nachgelagert)
  zh  → guizang-ppt-skill        (Stil A oder B, nativ; empfohlen)
  en  → frontend-slides / beautiful-html-templates (nativ; empfohlen)
  pptx → ppt-master (nativ DrawingML; explizit --renderer ppt-master)
  andere HTML-PPT-Skills → per Plug-In anschließbar, gleicher Brief-Vertrag
  Humanize erzeugt den Produktions-Prompt und stoppt. Der nachgelagerte
  Skill rendert das Deck. Humanize kopiert KEINE Templates, injiziert
  KEINE SLIDES_HERE / [必填]-Ersetzungen, fügt KEINE postMessage-Brücken
  zum gerenderten HTML hinzu.

Q — Präsentationsprüfung (演讲体检) am gerenderten Artefakt
  Humanize --qa-from <rendered.html|native.pptx> liest die Ausgabe von P,
  vergleicht Seiten mit der Gliederung, scannt auf Fehlermodi
  (references/qa-failure-modes.md), schreibt qa_report.md und
  fix_prompt.md, verfolgt die Iteration in qa_iteration.json.
  Begrenzung: 3 Runden. Nach Erreichen der Grenze mit verbleibenden Befunden
  wechselt Status zu needs-human.

C — Abschluss / Kontrolle
  Nachgelagerte Skill-native Sprechernotizen + Presenter-Shell + Bereitstellung
  (Humanize besitzt diese in v0.6.4 nicht – das Brief teilt dem nächsten
   Agenten mit, sie im eigenen Format des nachgelagerten Skills zu erstellen)

Regeln

v0.6.4-Invarianten (dies sind die harten Regeln; wenn du eine brichst, bist du außerhalb der v0.6.4-Grenze)

1. Humanize ist reiner Brief. Es schreibt den Renderer-Produktionsvertrag und stoppt. Es öffnet, kopiert oder verarbeitet nicht nachgelagerte Templates oder endgültige HTML/PPTX-Dateien nach.
2. Nachgelagerte Renderer sind 100% nativ. Der nächste Agent folgt dem eigenen SKILL.md des nachgelagerten Skills. Das Brief teilt dem nächsten Agenten mit, welchen Skill er laden, welchen Stil (A/B) er verwenden, welche Layouts er auswählen und welche QA-Gates bestehen muss – aber es enthält keine Template-Interna.
3. Die Präsentationsprüfung ist auf 3 Iterationen begrenzt. Runde 4 mit verbleibenden Fehlbefunden ist needs-human. Die Schleife dreht sich nicht endlos; sie gibt die Entscheidung an einen Menschen zurück.
4. Sprechernotizen und Presenter-Shell – Humanize erzeugt eine Basis-presenter-shell.html; der nachgelagerte Skill besitzt die vollständige Bühne. Humanize besitzt die semantische Quelle (speaker_intent.md) und schreibt jetzt auch outputs/presenter/presenter-shell.html direkt aus slide_plan.json + speaker_intent.md (auch eigenständig nutzbar, bevor das nachgelagerte Deck existiert). Der nachgelagerte Skill erzeugt die nativen Sprechernotizen und die vollständigere Presenter-Konsole. Humanize injiziert keine postMessage-Brücken oder ?slide=-URL-Parameter in das gerenderte HTML.
5. Der Produktions-Prompt ist der nachgelagerte Einstiegspunkt. Er benennt jedes Support-Artefakt, das der Renderer lesen muss. PPT Master liest zusätzlich ppt-master-source.md, das die Humanize-Seitengeschichte und die Notiz-Absicht einfriert, ohne PPT Masters visuelle Verträge zu duplizieren.

Arbeitsregeln

6. Lasse Folien-Renderer Rohmaterial nicht direkt konsumieren, wenn Humanize PPT zuerst den AST-Vertrag erstellen kann.
7. Behalte den nachgelagerten Skill als Eigentümer der gesamten Bühnenansicht; Humanizes presenter-shell.html ist eine funktionale Basis, kein Ersatz für native Konsolen.
8. Übernehme KI-Schreibreinigungsprinzipien von Humanizer-Tools, reduziere Humanize PPT aber nicht auf Textpolitur.
9. Bevorzuge einen kleinen verifizierten Workflow gegenüber einem breiten, unverifizierten Versprechen.
10. Für öffentliche Skill-Veröffentlichungen: Erstelle/Pushe das Repo, installiere von GitHub lokal, führe ein sicheres vollständiges Beispiel aus, verifiziere das Brief + die Präsentationsprüfung am verifizierten bekannten gutem Checkpoint (examples/03-codex-guizang-native-ink-classic/), und poliere erst dann die README-Details.
11. Für die Agent-Teams-Entwicklung: Erstelle router_plan.json, run_manifest.json, begrenzte commands/*.md und den rendererspezifischen Produktions-Prompt, bevor echte nachgelagerte Skills verdrahtet werden.
12. Für WorkBuddy/CodeBuddy-Team-Upload-Pakete: Verpacke keine Demo- oder gerenderten HTML-Ausgaben als Team-ZIP. Das Upload-ZIP muss eine Team-Plugin-Struktur wie trading-team widerspiegeln: root-level .codebuddy-plugin/plugin.json, agents/, skills/, rules/ und setting.json (plus optional avatars/, .workbuddy-plugin/, README.md, settings.json). Das rules/-Verzeichnis sollte eine Szenario-Regeldatei wie rules/<plugin-name>_rules.md mit Frontmatter (description, alwaysApply, enabled, updatedAt, provider) und einem <system_reminder>-Block enthalten, der verfügbare Agents, Skills, SOP und Nutzungsanforderungen beschreibt. Verifiziere mit unzip -l, dass das Root nicht index.html/assets/screenshots/source ist und nicht ordnergepackt ist, es sei denn, der Ziel-Uploader erfordert explizit ein Wrapper-Verzeichnis.
13. Behandle HyperFrames/Remotion-Videos nicht als einzelnen eingebetteten Player, der PPT-Inhalte ersetzt. Für Humanize-PPT-Ausgaben sind Video-Tools Materialproduzenten: Übergänge, Erklärclips, Vorher/Nachher-Vergleiche, Gesprächsmaterial-Einfügungen, Social Previews und Fallback-Standbilder, die spezifische Folienanforderungen erfüllen. Die media.video-Entscheidung pro Seite (siehe slide_plan.json-Schema) teilt dem nachgelagerten Skill mit, welche Seiten einen Remotion-Clip wünschen, zu welchem Zweck und in welcher Dauer.

Betriebliche Referenzen

• references/guizang-production-brief-orchestrator.md — Kanonische Brief-Spezifikation: was <renderer>-production-prompt.md enthalten und nicht enthalten muss.
• references/qa-failure-modes.md (+ englisches Spiegel references/qa-failure-modes.en.md) — Fehlermodus-Katalog für die Präsentationsprüfung; code-seitige Wahrheitsquelle ist FAILURE_MODES in scripts/humanize_ppt_v2.py.
• references/style-gallery-spec.md — Das --style-gallery-Cover-Stil-Gate.
• references/renderer-guidance.md — Empfohlene Pfade pro Renderer und die Regeln für bekannte gute Checkpoints.
• references/renderer-verification.md — Verifizierungsnachweise pro Renderer hinter den Frontmatter-Einzelzeilen.
• adapters/ppt-master-bridge-notes.md — Native PPTX-Routengrenze und OOXML-Prüfungsvertrag.
• SPEC.md — Technische Engine-Spezifikation: CLI-Oberfläche, Datenfluss, Ausgabevertrag, Style-Galerie, Prüfung, Medienmodell, Renderer-Registrierung.
• Vollständig kommentierter Index aller Referenzen, Adapter, Versionshinweise und Hilfsskripte: docs/index.md.

Lokale Demo

Der empfohlene stabile Einstiegspunkt ist scripts/humanize_ppt.py (versionierte Skripte bleiben als Kompatibilitäts-Shims). Vollständige CLI-Beispiele – Brief-Modus, Präsentationsprüfung, natives PPTX, Outline-Vorschau, Legacy-Einstiegspunkte – leben in docs/local-demo.md.

--out-Warnung: Richte --out auf ein dediziertes Run-Verzeichnis. Der Brief-Modus baut es bei jedem Lauf von Grund auf neu auf, löscht es aber nur automatisch, wenn es fehlt, leer ist oder bereits ein vorheriger Humanize-PPT-Lauf (run_manifest.json / style_gallery_plan.json / outline-preview.md / preview-confirmed.json in seinem Root) – andernfalls lehnt es ab und fragt nach --force.