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; bei Unsicherheit dort nachschlagen statt zu raten. Ein lauffähiges Referenzbeispiel liegt unter 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):

Titel-/Intro-Slide
Kontext/Problem
Kernteil (mehrere Slides, ein Gedanke pro Slide)
Beleg/Details (Daten, Vergleich, Architektur, Zeitplan — je nach Thema)
Zusammenfassung/Call-to-Action
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 <ordner> (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 <ziel> <ordner>.
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.

8 KiB Raw Blame History Unescape Escape