git2video — Release-Video aus echter Git-Historie
Liest die tatsächliche Git-Historie eines Repos und erstellt ein genaues, poliertes Release-Video: Sammeln → Storyboard → Validieren → Rendern → QA → Ausliefern. Läuft zu 100 % lokal (Node ≥ 22, ffmpeg, Playwright Chromium – zuerst mit doctor prüfen). Kein Netzwerk zur Renderzeit; Secrets werden aus Diff-Hunks entfernt; E-Mails erscheinen nie in der Ausgabe.
skills/git2video/scripts/doctor.mjs # Umgebung prüfen, FEHLENDE Zeilen korrigieren
scripts/collect.mjs # git -> story.json (gruppierte Commits, Breaking Changes, Statistiken, bereinigte Hunks)
scripts/validate.mjs # Tonloses Storyboard muss vor dem Rendern bestehen
scripts/render.mjs # Storyboard -> video.mp4 (+ webm/gif), layout-audit.json
scripts/qa.mjs # Skriptiertes Gate: report.json + report.md in out/qa/
references/storyboard-guide.md # Szenentypen, Datenformen, Schreibregeln – vor dem Erstellen lesen
references/faq.md # Fehlerbehebung
Workflow
1. Historie sammeln.
node skills/git2video/scripts/collect.mjs --repo <repo-verz> --out /tmp/g2v/story.json \
[--from <tag|sha|JJJJ-MM-TT>] [--to HEAD] [--max-commits 400] [--include-contributors] [--gh]
Standard: letzter Tag → HEAD; kein Tag: letzte 30 Tage. /tmp/g2v/story.json nach dem Ausführen lesen.
2. storyboard.json erstellen (du, der Agent – lies zuerst references/storyboard-guide.md). Faustregel für ein 30–45 s langes Release-Video:
Titel (3–4 s) → Highlights (5–8 s) → Diff (5–8 s) → Statistiken (4–5 s) →
Zeitleiste (optional 4–6 s) → Breaking Changes (3–5 s, nur falls vorhanden) →
Mitwirkende (3–5 s, nur mit --include-contributors) → Outro (3–4 s)
Jede Szene enthält: id, type, duration (0,8–15 s), narration (max. 2 Sätze; lesbar im Slot bei 0,35 s/Wort), source (Commit-Shas, die die Behauptungen stützen), data (typspezifisch – Formen im Leitfaden). Behauptungen müssen auf story.json zurückgehen – nichts erfinden.
3. Validieren.
node skills/git2video/scripts/validate.mjs --storyboard /tmp/g2v/storyboard.json \
--story /tmp/g2v/story.json
Jeden Fehler vor dem Rendern beheben. Das Gesamt-Dauer-Fenster für eine Demo mit --min/--max nur verbreitern, wenn der Nutzer einen kurzen Testclip angefordert hat.
4. Rendern.
node skills/git2video/scripts/render.mjs --storyboard /tmp/g2v/storyboard.json \
--out /tmp/g2v --preset 16:9 --fps 30 --theme dark [--formats mp4,webm,gif]
Presets: 16:9@1920, 9:16@1080, 1:1@1080. Themes: dark (Standard), light, neon. Renderings sind auf einem Rechner deterministisch; ~2–4 min für ein 40 s langes 30fps-Video. v0.1 ist stumm: Erzähltexte werden automatisch als Untertitel eingebrannt.
5. QA (skriptiert, nicht nach Gefühl).
node skills/git2video/scripts/qa.mjs --storyboard /tmp/g2v/storyboard.json --out /tmp/g2v
Ausgabe out/qa/report.md lesen. BESTANDEN → ausliefern. FEHLGESCHLAGEN → report.json-Details ansehen, Storyboard korrigieren, neu rendern, QA erneut ausführen. Maximal 3 Korrekturschleifen. Danach ehrlich berichten, was immer noch fehlschlägt und warum.
6. Ausliefern. Dem Nutzer mitteilen: den absoluten Pfad von video.mp4 (+webm/gif), das QA-Ergebnis in einer Zeile, etwaige Reste aus der dritten Schleife und anbieten: anderes Preset (vertikal), Theme-Varianten (light/neon) oder ein GIF für die README-Einbettung (--formats gif).
Strenge Regeln
- Nie Commits, Statistiken oder Diffs erfinden: Jede Szene nennt in
sourceechte Shas aus story.json. Wenn die Historie einen Szenentyp nicht unterstützt, die Szene weglassen. - Nie E-Mail-Adressen von Mitwirkenden in die Ausgabe aufnehmen; Namen nur mit --include-contributors.
- Dateien unter skills/git2video/templates/ oder scripts/ während des Renderns nicht bearbeiten; die deterministische Engine + QA gehen von ihnen aus. Änderungen an Szenen/Themes/Assets nur als separate, deklarierte Arbeit.
- Weniger, präzise Szenen bevorzugen statt Füllmaterial; Erzähltexte auf max. 2 Sätze begrenzen.