--- name: praesentation-erstellen description: Hilft interaktiv beim Aufbau einer neuen slidewalk-Präsentation aus Markdown-Slides – von Themenklärung über Gliederung bis zu den fertigen, nummerierten .md-Dateien mit Frontmatter. Funktioniert sowohl von Grund auf (Thema im Dialog klären) als auch ausgehend von einem bestehenden Markdown-/Text-Dokument, das in ein Deck umgewandelt werden soll. Themenneutral: funktioniert für jeden Vortrag, jede Zielgruppe. Nutzen, wenn ein neues Slide-Deck für slidewalk entstehen soll (nicht für das Reviewen bestehender Decks). --- # Präsentation erstellen Baut gemeinsam mit dem Nutzer ein neues slidewalk-Deck: ein Ordner mit nummerierten `.md`-Dateien, die slidewalks Konventionen folgen. Das Thema ist dabei beliebig (Business-Pitch, technischer Vortrag, Schulung, Statusupdate, …) — dieser Skill trifft keine Annahmen über den Inhalt, sondern erfragt die Struktur. Zwei Startpunkte, je nachdem was der Nutzer mitbringt: - **Modus A — von Grund auf**: Nutzer hat noch kein Ausgangsmaterial, nur ein Thema im Kopf. Struktur entsteht im Dialog (Schritt 1a). - **Modus B — aus bestehendem Dokument**: Nutzer hat schon einen Text (Report, Notizen, README, Konzeptpapier, …) und will daraus ein Deck ableiten. Struktur entsteht aus dem Dokument, nicht aus offenen Fragen (Schritt 1b). Ab Schritt 2 (Gliederung abstimmen) laufen beide Modi gleich weiter. Maßgeblich für alle Markdown-/Frontmatter-Details ist [`docs/markdown-guide.md`](../../../docs/markdown-guide.md); bei Unsicherheit dort nachschlagen statt zu raten. Ein lauffähiges Referenzbeispiel liegt unter [`examples/demo/`](../../../examples/demo/). ## Ablauf ### 1a. Rahmen klären (Modus A — von Grund auf) Bevor irgendetwas geschrieben wird, per Rückfrage klären (nicht alles auf einmal abfragen, sondern nur was für die Struktur nötig ist): - **Thema & Kernbotschaft**: Worum geht es, was soll das Publikum am Ende mitnehmen? - **Zielgruppe & Anlass**: Wer sitzt im Publikum, wie viel Vorwissen ist da, formell oder informell? - **Ungefährer Umfang**: Wie viele Slides / wie lange soll der Vortrag dauern? (Faustregel: 1–2 Minuten Sprechzeit pro Slide.) - **Zielordner**: Wo sollen die Dateien liegen? Falls nicht genannt, sinnvollen Vorschlag machen (z. B. `content/` im aktuellen Projekt) und bestätigen lassen — nicht ungefragt einen bestehenden Ordner überschreiben. - **Neu oder Erweiterung**: Entsteht ein komplett neues Deck, oder werden Slides in einen bestehenden Ordner eingeschoben? Falls Erweiterung: erst vorhandene Dateien lesen, um Nummerierungslücken und Stil zu übernehmen. ### 1b. Gliederung aus bestehendem Dokument ableiten (Modus B) Statt Thema und Kernbotschaft zu erfragen, wird das Dokument komplett gelesen und als Materialgrundlage genommen: - **Nicht mechanisch an Überschriften entlang splitten.** Eine `#`/`##` pro Slide ergibt fast immer schlechte Decks: manche Abschnitte sind zu lang für eine Slide, manche zu kurz und sollten zusammengelegt werden, und Fließtext-Absätze müssen ohnehin zu Stichpunkten verdichtet werden. Überschriften sind ein Anhaltspunkt für die grobe Reihenfolge, nicht die Schnittkante. - **Verdichten statt kopieren.** Prosa-Abschnitte in Kernaussagen/Stichpunkte übersetzen (siehe Schritt 3, Body-Konventionen); Prozesse, Vergleiche oder Zeitpläne, die im Dokument in Textform stehen, als Kandidaten für ein Mermaid-Diagramm oder eine Tabelle vormerken statt sie in Prosa zu belassen. - **Nur das übernehmen, was im Dokument steht.** Keine Fakten ergänzen oder interpretieren, die dort nicht stehen — bei Unklarheiten (z. B. ein Absatz lässt sich nicht eindeutig kürzen ohne Bedeutung zu verlieren) nachfragen statt zu raten. - **Trotzdem kurz nachfragen, was sich nicht aus dem Dokument ergibt**: ungefährer Zielumfang (ganzes Dokument in eine Kurzfassung pressen oder eher 1:1 in der Tiefe abbilden?), Zielordner, neu oder Erweiterung eines bestehenden Decks — wie in Modus A. - Das Ergebnis dieses Schritts ist eine Gliederung (Liste von Slide-Titeln plus grober Inhaltsangabe je Slide), die genau wie in Modus A in Schritt 2 zur Bestätigung vorgelegt wird — noch keine fertigen Dateien. ### 2. Gliederung vorschlagen und abstimmen Aus den Antworten (Modus A) bzw. aus dem Dokument (Modus B) eine Liste von Slide-Titeln (Gliederung) ableiten und dem Nutzer **vor** dem Schreiben der Dateien zur Bestätigung vorlegen. Typische Grobstruktur, an die Situation anpassen (in Modus B ergibt sich diese meist schon aus dem Dokument): 1. Titel-/Intro-Slide 2. Kontext/Problem 3. Kernteil (mehrere Slides, ein Gedanke pro Slide) 4. Beleg/Details (Daten, Vergleich, Architektur, Zeitplan — je nach Thema) 5. Zusammenfassung/Call-to-Action 6. Danke/Fragen Erst nach Zustimmung des Nutzers mit Schritt 3 weitermachen. Bei Unsicherheit über den Detailgrad lieber kurz nachfragen als zu viele Slides auf Verdacht zu erzeugen. ### 3. Dateien anlegen Für jede Slide der Gliederung: - **Dateiname**: Lücken-Nummerierung, drei Stellen als Standard (`010-intro.md`, `020-kontext.md`, `025-nachtrag.md`, …), damit später Slides eingeschoben werden können, ohne umzubenennen. Bei einer Erweiterung eines bestehenden Decks: bestehendes Nummernschema übernehmen. - **Frontmatter**: `title` immer setzen (informativ, auch wenn nicht automatisch im HTML sichtbar). `class` nur setzen, wenn eine Layout-Variante gebraucht wird, die auch in `web/assets/style.css` existiert oder gemeinsam mit dem Nutzer ergänzt wird — nicht auf Verdacht erfinden. `notes` nur füllen, wenn der Nutzer tatsächlich Sprechernotizen will. `skip` nur bei explizit als Entwurf markierten Slides. `incremental: true` setzen, wenn Stichpunkte einer Slide im Vortrag einzeln nacheinander aufgedeckt werden sollen (Bullet-Listen als "Fragments"; navigiert wird dann automatisch erst Fragment für Fragment, dann zum nächsten Slide) — nicht standardmäßig auf jede Liste anwenden, sondern nur wenn der Nutzer das so vorträgt. - **Body**: Stichpunkte statt Fließtext, eine Kernaussage pro Slide. Tabellen für Vergleiche/Status, Blockquotes für Zitate/Hervorhebungen, Mermaid-Codeblöcke (`graph`, `sequenceDiagram`, `gantt`, `pie`, …) für Prozesse, Architektur oder Zeitpläne statt sie in Prosa zu beschreiben. Codeblöcke mit Sprachangabe (```go, ```js, …) werden automatisch Syntax-highlighted, ohne weiteres Zutun. Bilder (`![Alt](img/datei.png)`) einfach neben die Slide-Dateien legen (auch in Unterordnern) — sie werden von Dev-Server und Export automatisch mitgeliefert, kein manuelles Kopieren nötig. Rohes HTML nur einsetzen, wenn reines Markdown eine Anforderung wirklich nicht abdeckt (z. B. `class="fragment"` auf einem einzelnen Element für ein gezieltes Fragment außerhalb einer Liste). ### 4. Ergebnis prüfen lassen Nach dem Schreiben der Dateien: - Vorschau anbieten: `slidewalk ` (Dev-Server mit Live-Reload). Bei größeren Decks auf den Übersichts-/Grid-Modus hinweisen (Taste `O` im Browser zeigt alle Slides als Miniaturansicht, Klick springt hin). - Falls gewünscht, statischen Export anbieten: `slidewalk -build `. - Kurz zusammenfassen, welche Dateien mit welcher Absicht entstanden sind, damit der Nutzer gezielt Feedback geben kann (z. B. "Slide 3 ist noch zu textlastig"). ## Leitplanken - Keine Inhalte erfinden, die der Nutzer nicht genannt hat oder die nicht aus bereitgestelltem Material (Notizen, bestehende Dokumente) stammen — bei fehlenden Fakten nachfragen statt zu raten. In Modus B gilt das besonders für das Verdichten: kürzen und in Stichpunkte übersetzen ist erlaubt und gewollt, inhaltlich umdeuten oder ergänzen nicht. - Immer die im Projekt vorhandenen Konventionen respektieren: Lücken-Nummerierung, Frontmatter-Felder aus `docs/markdown-guide.md`, vorhandene `class`-Werte in `web/assets/style.css` wiederverwenden statt neue zu erfinden. - Zielordner nicht ungefragt leeren oder überschreiben; bei Konflikten mit bestehenden Dateien nachfragen.