Web Slides

Verwandle eine Sammlung von Material / eine Gliederung / Stichpunkte Schritt für Schritt in eine live präsentierbare „filmische HTML-Präsentation“. Ausgabe = Vite + React + TS Projekt, per Klick / Pfeiltasten vorwärts navigieren, jeder Schritt belegt den gesamten Bildschirm. Mit P öffnest du ein separates Referentenfenster für die Sprechnotizen (Live-Vorschau + Timer, zwei Fenster gekoppelt; beim Teilen des Bildschirms reicht es, nur das Haupt-Slide-Fenster zu teilen, um die Notizen vor dem Publikum zu verbergen). Mit N öffnest du eine Overlay-Notizleiste für Probenzwecke.

Unterschied zu [web-video-presentation]: Jenes Skill erstellt „Webseiten, die wie Videos aussehen“ – mit Sprechnotizen, synthetisiertem Audio und Bildschirmaufnahme. Dieses Skill erstellt ausschließlich live präsentierbare Slides: keine Sprechnotizen, kein Audio, keine Bildschirmaufnahme; der Text jedes Schritts wird zu Referentennotizen (Presenter Notes), die dem Vortragenden als Stichwortgeber dienen und niemals auf dem Bild erscheinen. Die übrige visuelle Methodik, das Themensystem und das Prinzip der schrittweisen Enthüllung bleiben vollständig erhalten.

Anwendungsszenarien

„Ich habe Material / eine Gliederung – hilf mir, Slides / eine Präsentation daraus zu machen“
Technischer Vortrag / Keynote / Produktdemo / Pitch Deck / Lehrmaterial
Projekt-Rückblick im Vorstellungsgespräch (Project Retro) – live vor den Slides vortragen, mit P das Referentenfenster für die Stichpunkte öffnen
Eine dynamische Präsentation im 16:9-Querformat, große Schrift, viel Weißraum, mit Animationen auf jeder Folie – „wie PowerPoint, aber nicht wie PowerPoint“
Einen Artikel / eine Notiz in eine interaktive Schritt-für-Schritt-Erklärung verwandeln

Dieses Skill basiert auf Methodik und kollaborativem Workflow. Das Gerüst-Template bietet Tokens und Primitive, aber jede ästhetische Entscheidung (Farbpalette, Typografie, Animationsstil) sollte für dein Thema neu entworfen werden – nicht blind übernehmen.

Zwei Dichte-Profile: Video-Stil / Deck-Stil

Dieselbe Engine kann zwei Tempi abspielen. Phase 1 legt eines fest (oben in outline.md notieren, im Checkpoint Plan mit dem Benutzer bestätigen):

	🎬 Video-Stil (Standard / dünn besiedelt)	🎤 Deck-Stil (begrenzte Seiten / hohe Dichte)
Szene	Bildschirm-Erklärung, durchgehendes Sprechen, viele Takte	Live / Beamer-Präsentation, begrenzte Seiten, um eine Seite herum sprechen (häufig bei Interview-Retros)
Eine Folie	= ein Step (gesamter Bildschirm)	= ein Chapter (eine stabile, dichte Seite)
Step-Bedeutung	Zum nächsten Gedanken wechseln (Szenenwechsel)	Schrittweiser Aufbau auf derselben Folie (Elemente bleiben auf dem Bildschirm und erscheinen nacheinander, kein Szenenwechsel)
Info pro Bildschirm	1 Hero + 1~3 Elemente + viel Weißraum	Diagramm / Tabelle / Schema + einige Stichpunkte + Daten können zusammen auf einer Seite sein
Umfang	Viele Kapitel × wenige Schritte	Weniger Kapitel (≈ Zielseitenzahl) × 2~5 Builds pro Kapitel
Thema	Beliebig	Bevorzugt strukturelle / redaktionelle Themen (newsroom / monochrome-print / blueprint / swiss-ikb / vintage-editorial)

Beide ändern die Engine nicht (Chapter/Step, 16:9-Bühne, Token, MaskReveal alle universell), der Unterschied liegt nur in der Kapitelstruktur. Der Deck-Stil lockert „Ein Gedanke pro Bildschirm / viel Weißraum / volles Hero“, aber „Kein KI-Geschmack“ + Token + echte Hierarchie + muss visuelle Demo haben + Duale Quelle bleibt bestehen – das ist die Wurzel von „sieht nicht schlecht aus“. Detaillierte Kapitelstruktur siehe CHAPTER-CRAFT.md „Zwei Dichte-Profile“.

Unsicher → 🎬 Video-Stil.

Workflow-Überblick

Phase 1   Inhaltsplanung
   1.1  Benutzereingabe erkennen
   1.2  outline.md erstellen
        (Kapitelaufteilung + Bildschirminhalt pro Schritt + optionale Notizen pro Schritt + Informationspool)
   ▼
[Checkpoint Plan]      ← Muss anhalten. 4 Dinge auf einmal abstimmen:
                         Outline / Thema / Material / Entwicklungsmodus
   ▼
Phase 2   Webentwicklung
   2.1  Gerüst (nach gewähltem Thema)
   2.2  Kapitel 1 = Hauptthread + vollständige Version (obligatorischer Anker)
        ▼
        [Harter Knoten] Benutzer akzeptiert Kapitel 1 ← Nicht überspringbar
        ▼
   2.3  Kapitel 2~N (nach gewähltem Modus: A Kapitel für Kapitel / B sequenziell / C parallel)
   ▼
[Checkpoint Done]     ← Slides fertig, dev server läuft
   ▼
Phase 3   Präsentation / Export

Keine Phasen für „Audiosynthese“ und „Bildschirmaufnahme“ – dies sind Slides, kein Video.

Arbeitsverzeichnis-Konvention (Agent erstellt / bearbeitet im aktuellen Benutzerverzeichnis):

my-slides/
├── material.md         # Vom Benutzer bereitgestelltes Rohmaterial, falls vorhanden – nicht löschen! Infoquelle während der Entwicklung
├── outline.md          # Obligatorisch: Entwicklungsplan (Kapitelaufteilung + Inhalt pro Schritt + Informationspool + optionale Notizen)
└── presentation/       # Vom Gerüst erstelltes Vite + React + TS Projekt
    └── src/chapters/<NN>-<id>/
        ├── <Chapter>.tsx     # Visuelle Implementierung
        ├── <Chapter>.css
        └── notes.ts          # ★ Einzige Wahrheitsquelle für Schrittzahl + Referentennotizen

Wichtig: notes.ts ist die einzige Wahrheitsquelle für die Schrittzahl. Das maximale N + 1 in if (step === N) im Kapitel .tsx muss gleich notes.length sein. Dies stellt sicher, dass Kapitelcode, Fortschrittsbalken und Stepper nie abweichen. Der Notizinhalt (die Strings im Array) wird nur an das Referentenfenster (mit P) und die Notiz-Overlay (mit N) gefüttert, erscheint niemals auf dem Slide-Bildschirm und kann als "" leer bleiben.

Hartes Selbstprüfungsprotokoll (zieht sich durch das gesamte Skill)

Nach Abschluss der folgenden beiden Ergebnisse muss eine Selbstprüfung → Reparatur → erneute Meldung / Fortschritt erfolgen:

Ergebnis	Quelle der Checkliste
`outline.md`	`OUTLINE-FORMAT.md` Selbstprüfung
Einzelnes Kapitel implementiert	`CHAPTER-CRAFT.md` Fertigstellungs-Selbstprüfung

Ausführungsweise (absteigend nach Fähigkeiten, bevorzugt isolierter):

Agent Teams (Optimal): Einen unabhängigen Reviewer-Agenten starten, ihm „Pfad der Ausgabedatei + entsprechende Checkliste + wichtigen Kontext“ geben, Punkt für Punkt prüfen lassen und streng das Ergebnis melden (welche Punkte bestanden / welche nicht bestanden + Beweise + Änderungsvorschläge).
subAgent (zweitbeste): Falls keine Teams-Fähigkeit, aber subAgent möglich, denselben Prozess mit subAgent durchführen.
Selbstprüfung (Notlösung): Falls der aktuelle Agent keine der obigen Fähigkeiten hat, streng Punkt für Punkt selbst prüfen – nicht nur einmal drüber schauen und freigeben.

Eiserne Regel: Nach Erhalt des Ergebnisses zuerst die Ausgabe gemäß der nicht bestandenen Punkte korrigieren, dann dem Benutzer melden „fertig + Prüfergebnis + was geändert wurde“. Das rohe Ergebnis melden, ohne zu reparieren, gilt als Verstoß.

Phasenweise Datei-Leseanleitung

Verschiedene Phasen lesen verschiedene Dateien. In langen Sitzungen vergisst der Agent leicht die Prinzipien, insbesondere Phase 2.4 „Einzelnes Kapitel implementieren“ wird N-mal wiederholt – jedes Mal müssen die Kernbeschränkungen erneut gelesen werden.

Phase	Muss gelesen (jedes Mal)	Einmal durchlesen / bei Bedarf nachschlagen
Phase 1.1-1.2 Inhaltsplanung	`references/OUTLINE-FORMAT.md` + `material.md` (Rohmaterial des Benutzers, falls vorhanden)	——
Checkpoint Plan Thema wählen	——	`themes/*/theme.json` (alle dynamisch lesen, Liste + `bestFor` Empfehlung + `descriptionZh`); `references/THEMES.md` (wenn der Benutzer mehr über das Themensystem erfahren möchte)
Phase 2.1 Gerüst	——	SKILL.md diesen Abschnitt einmal lesen
Phase 2.4 Einzelnes Kapitel implementieren (×N mal, von 2.2 / 2.3 aufgerufen)	`references/CHAPTER-CRAFT.md` einziger Einstiegspunkt – Anforderungen an visuelle Demo / schrittweise Enthüllung / Inhaltsauswahl / Duale Quelle (outline+material) / Präsentationsästhetik / KI-Geschmack vermeiden / minimale Code-Beschränkungen (enthält `notes.ts` zwingende Einschränkung) / Zeitreferenz / Fertigstellungs-Selbstprüfung + `themes/<id>/theme.json` des aktuellen Themas + Abschnitt in outline.md für das aktuelle Kapitel + entsprechender Abschnitt in `material.md` für dieses Kapitel + Materialliste	`references/EXAMPLES/` (Strukturhinweise, keine Kopiervorlage); `references/THEMES.md` vollständiger Token-Vertrag
Phase 3 Präsentation / Export	`references/PRESENTING.md` (Vollbild-Präsentation, Tastaturnavigation, N für Notizen, PDF / Screenshots exportieren)	——
Thema wählen / erstellen / anpassen	——	`references/THEMES.md`

Beim Schreiben eines Kapitels nur CHAPTER-CRAFT.md lesen. Zehn Prinzipien / Start-Self-Prompting / Entscheidungsbaum / Anti-KI-Geschmack Anti-Patterns / Fertigstellungs-Selbstprüfung sind alle in diesem einen Einstiegspunkt integriert. EXAMPLES/ ist nicht erforderlich – zuerst frei nach Inhalt entwerfen, nur bei Blockaden nachschlagen (nach Anker nach der „Form“ suchen, nicht kopieren).

Phase 1 – Inhaltsplanung

1.1 Benutzereingabe erkennen

Was der Benutzer gibt	Was zu tun ist
Rohmaterial (Artikel / Notizen / Stichpunkte / Daten)	`outline.md` erstellen (1.2), das Rohmaterial als `material.md` behalten, Checkpoint Plan durchführen
Bereits erstellte Gliederung / Outline	In `outline.md`-Format bringen (1.2), Checkpoint Plan durchführen
Nichts, sagt nur „Mach mir Slides zum Thema X“	Nachfragen: Zuerst etwas Material oder Stichpunkte geben. Das Skill denkt sich den Inhalt nicht für den Benutzer aus

1.2 outline.md erstellen

Nach den Regeln von references/OUTLINE-FORMAT.md: Kapitel aufteilen → Schritte aufteilen → Informationspool aus dem ersten Absatz jedes Kapitels extrahieren → Bildschirminhalt pro Schritt schreiben (+ optionale Sprechnotiz-Hinweise).

Zuerst das Dichte-Profil festlegen (🎬 Video-Stil / 🎤 Deck-Stil, siehe oben „Zwei Dichte-Profile“) – es bestimmt direkt, wie die Kapitel aufgeteilt werden: Beim Deck-Stil ist die Kapitelanzahl ≈ Zielseitenzahl, mit 2~5 Builds pro Kapitel.

material.md nicht löschen – es ist die Detailquelle für den Informationspool in der Outline und für die visuelle Umsetzung der Kapitel (Dual-Quelle-Prinzip).

Grenzen der Outline (wichtig):

Outline muss enthalten	Outline sollte nicht enthalten
Kapitelaufteilung / Schrittzahl pro Kapitel / geschätzte Zeit	Spezifische Animationstypen (blur clear / wipe / spring)
Bildschirminhalt pro Schritt (Hero / Daten / Slogan / Listenelemente)	CSS-Implementierung (filter / SVG / clip-path)
Informationspool auf Kapitel-Ebene: aus dem Material extrahierte Zahlen / Zitate / Beispiele / Tags	Zeit- / Mikrorhythmus-Werte
Sprechnotiz-Hinweise pro Schritt (optional: Was du in diesem Schritt sagen möchtest)	Kontinuierliche Mikrobewegungen / asynchrone Mengen usw. Mikrorhythmus
Schritt-für-Schritt-Beziehungs-Präfixe („Kontrast-Gegenüberstellung“ / „Progressive Liste“ / „Bonmot“ usw., optionaler Hinweis)	——

Grund, warum Animationen nicht in der Outline stehen: Animationen festzulegen würde den Kapitel-Agenten zu einem Übersetzer degradieren; Freiraum lässt den Kapitel-Agenten bei der Arbeit an jedem Schritt nach dem „Inhaltsgesteuerten Entscheidungsbaum“ in CHAPTER-CRAFT.md frei entwerfen, was erst echte visuelle Wirkung erzeugt.

Nach dem Speichern muss zuerst die Selbstprüfung durchgeführt werden, bevor der Checkpoint Plan betreten wird: Führe die Selbstprüfung für outline.md gemäß dem obigen „Harten Selbstprüfungsprotokoll“ durch (bevorzugt Agent Teams → subAgent → Selbstprüfung), repariere basierend auf dem Ergebnis, dann erst weiter.

Checkpoint Plan – 4 Dinge auf einmal abstimmen (Harter Knoten)

Nachdem outline.md geschrieben ist, muss angehalten werden. Der Benutzer bestätigt an diesem Knoten gleichzeitig 4 Dinge.

Vorbereitungsarbeit des Agenten zu diesem Zeitpunkt

Alle themes/*/theme.json lesen, um nameZh / descriptionZh / bestFor / mood zu erhalten – keine hartcodierte Liste
Basierend auf dem Inhaltstyp / den Schlüsselwörtern / dem Ton der Outline aktiv 2~3 am besten passende Empfehlungen aus den Themen auswählen (passend zum bestFor-Feld)
Den Abschnitt „Materialliste“ am Ende von outline.md überfliegen

Zusammenfassungsvorlage (Skelett, Agent füllt nach Situation aus)

Inhaltsplan fertig, Ausgabedateien:
  📄 material.md    {falls der Benutzer Rohmaterial gegeben hat, behalten}
  📄 outline.md     {N} Kapitel / {M} Schritte + Informationspool pro Kapitel + Materialliste am Ende

Kapitel-Übersicht:
  1. <id>     <Kapiteltitel>    <S> Schritte ~<T>s
  2. ...

Als nächstes 4 Dinge auf einmal abstimmen:

  1. Entwicklungsplan (outline.md) ändern? Schwerpunkte:
     - Dichte-Profil richtig? (🎬 Video-Stil: viele Schritte, dünn / 🎤 Deck-Stil: begrenzte Seiten, hohe Dichte)
     - Kapitelaufteilung / Schrittzahl sinnvoll? (~5~12 Schritte pro Kapitel ist üblich)
     - Bildschirminhalt pro Schritt klar?
     - „Informationspool“ im ersten Absatz jedes Kapitels mit genügend Materialdetails zum Aufhängen von Bildern?
     - Materialliste am Ende vollständig?

  2. Welches Thema wählen? Meine Empfehlung:
     ★ <Empfehlung 1: nameZh (id)> – weil <bestFor trifft zu>; <descriptionZh Zusammenfassung>
     ★ <Empfehlung 2 / Empfehlung 3>
     Andere Optionen: <restliche Themen, nameZh + ein Satz>
     Ich kann auch ein neues Thema für dich erstellen (Details siehe references/THEMES.md).

  3. Wie echte Materialien vorbereiten? Grobe Liste der benötigten Bilder für diese Slides: <grobe Liste>
     a) Ich wähle aus <vorhandenem Materialpfad> für dich aus   b) Du stellst selbst bereit   c) Alle Platzhalter

  4. Welchen Entwicklungsmodus wählen?

     **Kapitel 1 muss in jedem Modus im Hauptthread erstellt und vom Benutzer abgenommen werden** (obligatorischer Anker).
     Der Unterschied beginnt ab Kapitel 2:

     A) Standard · Kapitel für Kapitel bestätigen (empfohlen)
        Nach jedem Kapitel anhalten und prüfen lassen → Risiko beherrschbar / stabilster Rhythmus
     B) Sequenzielle Entwicklung nach Kapitel 1 (nicht parallel)
        Kapitel 2~N im Hauptthread der Reihe nach fertigstellen, dann einheitlich prüfen lassen → mittlere Geschwindigkeit / geeignet, wenn Agent keine Parallelaufgaben unterstützt
     C) Parallele Entwicklung nach Kapitel 1 (subAgent)
        Kapitel 2~N parallel mit subAgenten erstellen → am schnellsten / Benutzer steuert Parallelitätsgrad (wie viele Kapitel auf einmal)
        ⚠️ Stilistische Unterschiede zwischen den Kapiteln sind zu erwarten (beabsichtigt, durch thematische No-Go-Zonen abgesichert)

Nach Erhalt des Feedbacks:

Outline ändern: Datei direkt bearbeiten, nach der Bearbeitung einmal pingen (oder Agent mündlich beschreiben, was zu ändern ist)
Das Thema muss eindeutig sein, bevor Phase 2 betreten wird. Benutzer sagt „Wähle du das Thema für mich“ → nimm deine 1. Empfehlung, teile dem Benutzer mit, was du gewählt hast und warum, gib ihm eine Rücktrittsoption
Modus gewählt → Phase 2 betreten

Phase 2 – Webentwicklung

2.1 Gerüst

bash <path-to-web-slides>/scripts/scaffold.sh \
  ./presentation \
  --theme=<vom Benutzer gewählte Themen-ID>

bash <path-to-web-slides>/scripts/scaffold.sh --list-themes

Benutzerdefiniertes Thema → zuerst nach dem Workflow in references/THEMES.md „Neues Thema erstellen“ ein themes/<mein-thema>/ erstellen, dann --theme=<mein-thema>.

Das Gerüst enthält eine 01-example Demo. Lösche sie, bevor du den ersten echten Inhalt schreibst:

rm -rf presentation/src/chapters/01-example

Und entferne den example-Import und das Array-Element aus presentation/src/registry/chapters.ts.

2.2 Kapitel 1 – Hauptthread + obligatorische Abnahme

Kern: Kapitel 1 = vollständige Version auf einmal (Rhythmus + visuell + echte Materialien alle vorhanden). Kein „Skelett“-Konzept – das erste Kapitel muss eine vom Benutzer direkt prüfbare Vorlage sein.

Warum Kapitel 1 im Hauptthread sein muss:

Es ist die erste Umsetzung der Anleitung von CHAPTER-CRAFT.md für das aktuelle Thema + aktuelles Material
Wenn die Anleitung blinde Flecken hat / Themenfarben / Schrift-Tokens nicht ausreichen, wird Kapitel 1 dies aufdecken – dann kann mit menschlichem Feedback die Anleitung korrigiert / das Thema angepasst werden, frühe Änderung ist am kostengünstigsten
Nachfolgende Kapitel (egal ob sequenziell / parallel) müssen sich am Code-Muster von Kapitel 1 orientieren, also Kapitel 1 = Stilanker des aktuellen Projekts

Nach Fertigstellung von Kapitel 1 muss angehalten werden, um auf die Benutzerabnahme zu warten:

Kapitel 1 <id> fertig, dev server läuft unter localhost:5174.

Abnahmeschwerpunkte:
  □ Visuelle Ausrichtung richtig? Entspricht den Erwartungen von <Theme nameZh>?
  □ Rhythmus richtig? Einige Schritte zu schnell / zu langsam / zu dünn?
  □ Inhaltsgesteuerte Animationen angemessen? Oder gibt es Schritte mit gedankenloser Eingangsanimation?
  □ Dual-Quelle-Prinzip: Gibt es Details auf dem Bildschirm, die „nicht in den Notizen stehen, aber das Material hergibt“?
  □ Anti-KI-Geschmack-Check: Gibt es lila-rosa Verläufe / runde farbige Rahmen / Fake-Illustrationen / Emojis?
  □ N drücken, um Sprechnotizen zu sehen – liest es sich gut beim Vortragen?

Bei Problemen sag Bescheid, ich korrigiere gezielt. Sag „weiter“, wenn es OK ist, ich mache Kapitel 2 und folgende im gewählten Modus.

2.3 Kapitel 2~N – nach gewähltem Modus

Gemeinsame Regeln für alle Modi: Jedes Kapitel unabhängig nach CHAPTER-CRAFT.md entwickeln. Stilistische Konsistenz zwischen den Kapiteln ist nicht zwingend – Themenfarben / Schrift-Tokens sorgen für visuelle Einheitlichkeit; Animation / Rhythmus / visuelle Demo frei nach Kapitel ist Design-Absicht.

Modus A · Standard · Kapitel für Kapitel bestätigen

Kapitel 2 fertig → anhalten und prüfen lassen → OK → Kapitel 3 → anhalten → ... → Kapitel N. Jedes Kapitel einzeln prüfen lassen, Probleme jederzeit korrigieren, geringstes Risiko, stabilster Rhythmus. Wenn der Benutzer keinen Modus explizit wählt, wird standardmäßig dieser verwendet.

Modus B · Sequentielle Entwicklung nach Kapitel 1

Kapitel 2 → Kapitel 3 → ... → Kapitel N im Hauptthread nacheinander fertigstellen, dann einheitlich am Ende prüfen lassen. Mittlere Geschwindigkeit, geeignet für Umgebungen, in denen der Agent keine parallelen Aufgaben unterstützt.

Modus C · Parallele Entwicklung nach Kapitel 1 (subAgent)

Mit subAgenten die Kapitel 2~N parallel erstellen, maximale Parallelität vom Benutzer gesteuert („einmal 4 Kapitel“ / „einmal 2 Kapitel“). Am schnellsten, aber stilistische Unterschiede zwischen den Kapiteln sind zu erwarten – das ist beabsichtigt, weil:

Jeder subAgent sieht keine Ergebnisse anderer subAgenten und kann nicht mechanisch angleichen
Kapitelcode ist physisch getrennt (ein Ordner pro Kapitel / eigenes CSS-Präfix), sie stören sich nicht gegenseitig
Thematische Tokens decken die visuelle Einheitlichkeit ab (Farbe / Schrift / Hero-Zahlen / Karten / Trennliniencharakter / Dekoration), der Charakter läuft nicht aus dem Ruder
Stilistische Unterschiede = handgemachte Atemluft (mehrere Stimmen / mehrere Perspektiven)

Das Prompt für parallele subAgenten MUSS enthalten:

Den Outline-Abschnitt des aktuellen Kapitels (mit Informationspool)
Den Pfad zu references/CHAPTER-CRAFT.md (einziges Pflicht-Lese)
descriptionZh / mood / bestFor des aktuellen theme.json
Den Code von Kapitel 1 als Referenz für den „Code-Stil“ (nicht als „visuelle Kopiervorlage“)
Harte Regeln: Jedes Kapitel eigenes CSS-Präfix (.cd- / .mg- / .pm- / ...); chapters.ts nicht ändern; jedes Kapitel hat notes.ts (Länge = Schrittanzahl); nach Fertigstellung npx tsc --noEmit ausführen

Wichtig: Unabhängig vom gewählten Modus kann der Benutzer jederzeit zwischendurch den Modus wechseln.

2.4 Einzelnes Kapitel implementieren (jedes Kapitel muss durchlaufen werden)

Detaillierte Anleitung siehe references/CHAPTER-CRAFT.md – einziger Pflicht-Lese-Einstiegspunkt, deckt ab: Anforderungen an visuelle Demo / schrittweise Enthüllung / Inhaltsauswahl / Dual-Quelle-Prinzip / grundlegende Präsentationsästhetik / Anti-KI-Geschmack / Code-Richtlinien / Fertigstellungs-Selbstprüfung.

Kernpunkte (detailliert in CHAPTER-CRAFT.md):

Jedes Kapitel muss eine CSS / SVG / Canvas / JS visuelle Demo haben, reine Textkapitel verboten
Schrittweise Enthüllung: Listen / Aufzählungen müssen 1 Element = 1 Step sein, einmalige vollständige Anzeige verboten
Dual-Quelle-Prinzip: Rhythmus folgt der Outline (Reihenfolge darf nicht durcheinander geraten), Details aus dem Rohmaterial ziehen (Informationspool + Materialabschnitt dieses Kapitels)
Jedes Kapitel hat notes.ts: Länge = Schrittanzahl (einzige Wahrheitsquelle), Inhalt sind Sprechnotizen (kann als "" leer bleiben), erscheinen nicht auf dem Bildschirm
Fertigstellungs-Selbstprüfung Punkt für Punkt durchgehen, bei Nichtbestehen zurückgehen und korrigieren – nach dem „Harten Selbstprüfungsprotokoll“ durchführen, erst nach der Korrektur dem Benutzer die Lieferung dieses Kapitels melden

2.5 STORAGE_KEY nach großen Änderungen erhöhen

Nach Änderungen an chapters.ts (Hinzufügen / Löschen / Neuordnen von Kapiteln oder Längenänderung von notes.ts eines Kapitels), erhöhe den STORAGE_KEY in presentation/src/hooks/useStepper.ts (z. B. web-slides-cursor-v1 → v2), um zu vermeiden, dass persistierte Cursor auf nicht existierende Steps zeigen.

Phase 3 – Präsentation / Export

Detaillierter Ablauf siehe references/PRESENTING.md. Wichtige Punkte:

Live-Präsentation: npm run dev → Browser Vollbild (F11) → Klick / Pfeiltasten vorwärts.
Tastaturnavigation: ← → / Leertaste vorwärts; Home / End zum Anfang / Ende springen; Zifferntasten 1-9 zum Kapitel springen; P öffnet Referentenfenster (separates Fenster: Sprechnotizen + Live-Vorschau + Timer, zwei Fenster gekoppelt); N öffnet / schließt Notiz-Overlay (über dem aktuellen Fenster, nur für Proben – ⚠️ wird mit dem Bildschirm geteilt).
Richtige Methode, damit Sprechnotizen nicht auf dem Beamer sichtbar sind: P drücken, um Referentenfenster zu öffnen → in der Konferenzsoftware „Ein Fenster / einen Tab freigeben“ auswählen und das Haupt-Slide-Fenster auswählen (nicht „Ganzen Bildschirm freigeben“) → Das Referentenfenster siehst nur du, das Umblättern ist gekoppelt, funktioniert auch mit einem einzigen Monitor.
Offline-Verteilung / stabilere Projektion: npm run build → npm run preview, oder dist/ bereitstellen.
Export (optional): Schrittweise als PNG erfassen oder im Browser Schritt für Schritt „als PDF drucken“.

Nach Phase 2 aktiv dem Benutzer mitteilen: Slides fertig, dev server läuft unter localhost:5174, live präsentierbar / projektierbar; P drücken, um Referentenfenster mit Sprechnotizen zu öffnen (beim Teilen des Bildschirms nur das Haupt-Slide-Fenster freigeben, Zuschauer sehen die Notizen nicht), N ist die Notiz-Overlay für Proben (wird mit dem Bildschirm geteilt).

Zehn Prinzipien (Ein-Satz-Liste)

Vollständige Ausführung siehe entsprechender Abschnitt in references/CHAPTER-CRAFT.md – dort beim Schreiben eines Kapitels nachschlagen, unten nur als Index.

#	Prinzip	Ein Satz
1	Feste 16:9-Bühne	Inhalt 1920×1080 + transform scale, nicht responsiv
2	Globaler Step-Zähler	Kapitel ist eine reine Funktion von Step, kein Timer
3	Jeder Schritt belegt den ganzen Bildschirm	`if (step === N) return <FullScene />`
4	Logischer Takt = Step	Ein Takt = ein Step = ein fokussierter Gedanke
5	Versteckte Ecken-Steuerelemente	Fortschrittsbalken standardmäßig opacity 0; Notizen standardmäßig versteckt (N drücken zum Öffnen)
6	Bühne ohne Chrome	Kein header / footer / Seitenzahl / Markenleiste
7	Inhaltsgesteuerte Animation	Zuerst interne Aktion suchen, nur wenn nicht gefunden, Eingangsanimation als Auffangnetz; kontinuierliche Mikrobewegungen sparsam einsetzen
8	Mehrere Punkte nacheinander enthüllen	1 Element = 1 Step, synchrones Stagger von N Elementen verboten
9	Gleiches Thema über die gesamte Präsentation	Kein flächiger Farbwechsel zwischen Kapiteln; Farbe / Schrift über Token, andere Skalen Kapitel frei
10	Dual-Quelle-Prinzip	Outline bestimmt den Takt, Material bestimmt die Bilddichte (Landung im Informationspool)

🎤 Deck-Stil: Prinzip 3 „Jeder Schritt belegt den ganzen Bildschirm“ / 8 „1 Element = 1 Step“ werden gelockert zu: Eine Seite = ein Chapter, Step = schrittweiser Build auf derselben Seite (Elemente bleiben auf dem Bildschirm und erscheinen nacheinander); restliche Prinzipien unverändert. Siehe oben „Zwei Dichte-Profile“.

Schnellreferenz zu häufigem Benutzerfeedback

Zuerst lokalisieren, auf welcher Ebene das Feedback liegt (Rhythmus / visuell / Inhalt / Code), dann die minimalste Änderung vornehmen, das ganze Kapitel nicht neu machen:

Rhythmus: Zu schnell / zu langsam / zu dünn → Schritte teilen / zusammenlegen (gleichzeitig notes.ts-Länge + Kapitel if (step===N) anpassen)
Visuell: Charakter falsch / KI-Geschmack → Zurück zu CHAPTER-CRAFT.md „KI-Geschmack vermeiden“ + „Grundlegende Präsentationsästhetik“
Inhalt: Bildschirm zu leer / nicht genug Details → Zurück zum Informationspool + material-Abschnitt dieses Kapitels (Dual-Quelle-Prinzip)
Code: Fehler / Token funktionieren nicht → Zurück zu CHAPTER-CRAFT.md „Minimale Code-Beschränkungen“

Datei	Wann lesen	Inhalt
`references/OUTLINE-FORMAT.md`	Phase 1.2 Pflicht	outline.md Feld-Spezifikation, Namenskonvention, Kapitelaufteilung, Informationspool, Sprechnotizen pro Schritt
`references/CHAPTER-CRAFT.md`	Phase 2.4 Einziger Pflicht-Lese-Einstiegspunkt pro Kapitel	Anforderungen an visuelle Demo / schrittweise Enthüllung / Inhaltsauswahl / Dual-Quelle (outline+material) / Präsentationsästhetik / KI-Geschmack vermeiden / minimale Code-Beschränkungen (enthält `notes.ts`) / Zeitreferenz / Fertigstellungs-Selbstprüfung
`references/EXAMPLES/`	Optional – Struktur ansehen	Kapitel-Strukturbeispiele (hook / list-reveal / case-tech-review); keine Kopiervorlage
`references/THEMES.md`	Bei Themenauswahl / -erstellung / -anpassung	Vollständiger Token-Vertrag + Liste der integrierten Themen + Erstellungs-Workflow
`references/PRESENTING.md`	Erst in Phase 3 lesen	Vollbild-Präsentation, Tastaturnavigation, N für Notizen, Export als PDF / Screenshots
`themes/`	Checkpoint Plan / Phase 1.2 durchblättern	Integrierte Themen (jeweils mit `theme.json` + `tokens.css`)
`scripts/scaffold.sh`	Phase 2.1 einmal ausführen	Ein-Klick-Projektgerüst

olddonkey/olddonkey-skills

Was ist olddonkey-skills?

In Ihrer bevorzugten KI fragen

Dokumentation