OneSlide (Ein-Folie-PowerPoint-Skill)

OneSlide

Verarbeite immer nur eine einzelne PowerPoint-Folie und strukturiere Logik, Informationen und Layout auf Beratungsreport-Niveau. Der Benutzer interagiert nur mit diesem Einstiegspunkt; intern wird zuerst das Inhaltsdesign mit Quellennachweisen abgeschlossen, und erst wenn eine PPTX benötigt wird, wird die mitgelieferte Builder-Engine aufgerufen.

Vor jeder Ausführung lesen

Vollständig lesen:

• references/input-contract.md
• references/suite-contract.md
• producer/references/single-slide-contract.md
• producer/references/provenance-contract.md
• producer/references/output-contract.md

In der Zeichnungsphase dann builder/ENGINE.md und die von der Route zurückgegebene, eindeutige Modulreferenz lesen. Nicht alle Builder-Module vorab lesen.

Erste Interaktion

Natürlich erklären, dass diesmal nur eine Folie erstellt wird, und dann basierend auf dem aktuellen Gespräch, Anhängen und bereits getroffenen Entscheidungen vorausfüllen:

• Was soll diese Folie aussagen;
• Wer wird sie sehen und was soll er/sie nach dem Ansehen verstehen oder entscheiden;
• Ein Hauptproblem, eine Hauptbeziehung und eine Kernschlussfolgerung;
• Welche Inhalte wurden vom Benutzer bereitgestellt und müssen erhalten bleiben;
• Welche Lücken werden gezielt gefüllt und markiert.

Nur dann eine blockierende Frage stellen, wenn zwei gleichermaßen plausible Seitenrichtungen die Kernschlussfolgerung oder die Hauptgrafik ändern würden. Der Benutzer darf nicht aufgefordert werden, interne Felder, Modulnummern, Koordinaten, Kartenanzahlen oder Gestaltungspräferenzen auszufüllen.

Zwei Ausgabearten

Aus den Worten des Benutzers ableiten:

• PROMPT_ONLY: Der Benutzer wünscht einen Prompt, ein Briefing, ein Übergabepaket oder Generierungsanweisungen.
• PPT_DRAFT: Der Benutzer wünscht die direkte Erstellung, Zeichnung, Generierung oder Auslieferung einer PowerPoint-Datei.

Wenn kein Medium angegeben ist, standardmäßig PROMPT_ONLY und kurz erläutern. Wechselt der Benutzer später zu PPT_DRAFT, die bereits festgelegten Quellen und Seitenrichtung wiederverwenden, ohne dass das Material erneut dargelegt werden muss.

Drei Inhaltsmodi

• SOURCE_ONLY: Die vorhandenen Informationen reichen für diese Folie aus; es werden keine neuen Fakten hinzugefügt.
• SYNTHETIC_AUGMENTATION: Es werden nur die für die Folie notwendigen Lücken gefüllt; die Fakten und die Hauptlogik des Benutzers werden nicht verändert.
• EVIDENCE_BLOCKED: Das Ziel erfordert reale Fakten, aber es fehlen Belege und diese können nicht ehrlich ergänzt werden.

Stil, Formulierung, Layout und Diagrammauswahl sind keine Faktlücken; sie können aus der Hauptbeziehung abgeleitet werden.

Arbeitsablauf

1. Begrenzung auf eine einzelne Folie festlegen

Die ursprüngliche Anfrage des Benutzers beibehalten und für die verwendeten Anhänge eine Quellenaufzeichnung mit Hash erstellen. Pro Durchlauf darf es nur geben:

1 Publikumsaufgabe
1 Hauptproblem
1 Hauptbeziehung
1 Kernschlussfolgerung
1 Hauptgrafik
0-3 unterstützende Evidenzthemen
0-1 Aktions- oder Bedingungsbereich

Wenn konkurrierende Hauptgrafiken oder mehr als drei Evidenzthemen auftreten, SINGLE_SLIDE_SCOPE_OVERLOAD zurückgeben und den stärksten Einzelfokus empfehlen. Keine notwendigen Inhalte heimlich löschen oder eine zweite Folie generieren.

2. Quellenbasislinie herstellen

Für benutzergestellte, stabil abgeleitete, berechnete, extern verifizierte und modellergänzte Informationen jeweils eine stabile source_id vergeben. Die Zahlen, Definitionen, Schlussfolgerungsstärke, Pflichtinhalte und Ausschlusspunkte des Benutzers unverändert lassen.

Benutzeranhänge sind "vom Benutzer bereitgestellte Beweise" und gelten nicht automatisch als unabhängig verifizierte Fakten. Bei Autoritätskonflikten die betroffenen Berechnungen stoppen; nicht heimlich eine Seite wählen.

3. Gezielte Ergänzung

Wenn der Inhalt nicht ausreicht, nur die für die Hauptgrafik und die deklarierten Evidenzthemen minimal notwendigen Inhalte ergänzen:

• Synthetische Daten müssen Objekt, Granularität, Zeitraum, Einheit, Nenner und Berechnungsregeln definieren;
• Summen, Anteile, Trichter, Brücken, Dopplungen und Titelkonklusionen müssen konsistent sein;
• Synthetische qualitative Inhalte als "Annahme", "Beispiel" oder "Zu bestätigen" behandeln;
• Keine Quellen, Kundenaussagen, Branchenbenchmarks, rechtlichen Schlussfolgerungen oder echten Unternehmensleistungen erfinden.

Wenn echten Organisationen echte Daten fehlen, keine fiktiven Metriken unter deren Namen schreiben. Kann zu anonymen Beispielen geändert oder mit EVIDENCE_BLOCKED zurückgegeben werden.

4. Inhaltspaket generieren

Gemäß producer/ENGINE.md ausführen und ein versioniertes Ausführungsverzeichnis ausgeben. Jeder sichtbare Fakt, Titel, Diagrammdatenpunkt, jede Einsicht und jeder Aktionseintrag muss source_ids enthalten.

Synthetische Zahlen oder Datensätze müssen auf der Folie anzeigen:

Synthetische Beispieldaten, keine echten Kundendaten

Synthetische qualitative Inhalte an benachbarter Stelle "Zu bestätigen" anzeigen oder eine Seitenlegende verwenden, die eine Zuordnung pro Eintrag ermöglicht. Sobald der Benutzer ein Szenario bestätigt hat, bleibt es eine Szenarioannahme und wird nicht zu einer Tatsache.

Ausführen:

python3 producer/scripts/validate_package.py <run-directory> --stage handoff --write-report

Auch nach bestandener Strukturvalidierung das Briefing, den Prompt, die Übergabedokumente und die Checkliste zur Inhaltsbestätigung vollständig lesen. Das Skript kann weder die Beratungslogik noch die visuelle Qualität der PPT nachweisen.

5. Nach Ausgabemodus ausliefern

PROMPT_ONLY liefert aus:

• handoff/builder-prompt.md
• handoff/builder-handoff.json
• review/content-review.md

PPT_DRAFT liest nach bestandenem Inhaltspaket builder/ENGINE.md und übergibt handoff/builder-handoff.json an den integrierten Builder. Der Builder ist verantwortlich für Modulauswahl, präzise Geometrie, PowerPoint-Objekte, Rendering und PPTX-Qualitätssicherung; er darf die Seitenziele oder Quellenfakten nicht erneut umschreiben.

Nach Auslieferung durch den Builder erneut ausführen:

python3 producer/scripts/validate_package.py <run-directory> --stage final --write-report

Wenn der Builder nicht verfügbar ist, Laufzeitabhängigkeiten fehlen oder MODULE_COVERAGE_GAP zurückgegeben wird, das verfügbare Prompt-Paket behalten und PPT_RENDERING_BLOCKED zurückgeben. Nicht heimlich einen normalen Renderer verwenden und dann vorgeben, eine Beratungs-PPT erstellt zu haben.

Der Producer darf requested_module und das vollständige, durch den Modulvalidator prüfbare module_payload nur dann gleichzeitig schreiben, wenn ein bereits produktives Modul alle Pflichtinhalte abdecken kann. Nur der Modulname ohne ausführbare Nutzlast darf nicht erzwungen werden; für gemischte Seiten die direkte Orchestrierung mit Layout-Zugangskontrolle verwenden.

6. PPTX prüfen

PPT_DRAFT muss erfüllen:

• Genau eine Folie, 16:9;
• Text, Formen, Tabellen und Diagramme sind native, bearbeitbare PowerPoint-Objekte;
• Semantische Prüfung, Ganzseiten-Rendering-Check und Lesbarkeitsprüfung bestanden;
• Layout-JSON besteht Prüfungen auf: kurze Einzeiler-Tags, Waisenwörter, englische Token, Zahleneinheiten, gegenseitiger Ausschluss von zweizeiligen Titeln und Untertiteln, Titelsicherheitszone, vertikales Raumgleichgewicht, Blockübergreifende Kantenausrichtung, Leinwandauslastung und Randerlaubnis;
• Organigramme zusätzlich prüfen auf horizontale Ausrichtung gleichrangiger Knoten, vertikale Ausrichtung direkter Unterstellungslinien, Richtung funktionaler Linien und kreuzungsfreie Routen; bei Auftreten von ORG_PEER_ROW_MISALIGNMENT, ORG_DIRECT_REPORT_DOGLEG oder ORG_FUNCTIONAL_ROUTE_AMBIGUOUS nicht ausliefern;
• Wenn die aktuelle Umgebung Microsoft PowerPoint verwendet, tatsächlich öffnen und prüfen;
• Im Auslieferungsverzeichnis nur die versionierte PPTX ablegen; Quellen, Prompts, Vorschau und QA im internen Verzeichnis belassen.

Harte Grenzen

• Keine mehrseitigen Reports, versteckte Überlaufseiten oder zweite Kandidatenfolien generieren.
• Keine dekorativen Karten, Vorschläge, Metriken oder Benchmarks hinzufügen, um die Seite zu füllen.
• Keine notwendigen Inhalte löschen, auf unlesbare Schriftgröße verkleinern oder die Kernaussage ändern, um alles auf eine Seite zu quetschen.
• Keine modellergänzten Inhalte als benutzergestellt oder extern verifiziert tarnen.
• Keine lokalen Pfade, Prompthistorie, abgelehnte Lösungen, interne QA oder Erstellungsnotizen offenlegen.
• Dateigenerierung, Abschluss von Validierungsskripten oder vollständige ZIPs nicht als Produktwert oder Benutzerabnahme ausgeben.

Selbsttest des Veröffentlichungspakets

python3 scripts/validate_suite.py .
python3 -m unittest discover -s tests -v
python3 scripts/check_environment.py

Status

Je einzeln melden:

BASIC_OUTPUT_PASS | fail
TECHNICAL_CHAIN_PASS | not_tested | fail
INPUT_CONTRACT_PASS | not_tested | fail
SOURCE_BASELINE_PASS | fail
SINGLE_SLIDE_SCOPE_PASS | fail
PROVENANCE_COVERAGE_PASS | fail
SYNTHETIC_DISCLOSURE_PASS | not_applicable | fail
DATA_RECONCILIATION_PASS | not_applicable | not_tested | fail
HANDOFF_PACKAGE_PASS | fail
BUILDER_HANDOFF_READY | not_applicable | fail
RENDERED_READABILITY_PASS | not_applicable | not_tested | fail
POWERPOINT_OPEN_CHECK | not_applicable | not_tested | fail
REQUIREMENT_COVERAGE_PASS | not_tested | fail
PRODUCT_VALUE_PASS | not_tested | fail
USER_REQUIREMENT_PASS | not_tested
PUBLIC_LICENSE_READY | pass

Nur wenn das tatsächliche, vom Benutzer gesehene Ergebnis die Einzelfolien-, Quellen- und Editierbarkeitsanforderungen dieses Skills erfüllt, darf PRODUCT_VALUE_PASS gesetzt werden. Nur wenn der Benutzer das konkrete Ergebnis gesehen hat, darf USER_REQUIREMENT_PASS gesetzt werden.