slidewalk/.opencode/skills/praesentation-erstellen/SKILL.md

---
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 <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.