Ozor Changelog-to-Video-Konverter

Was macht Ozor Changelog-to-Video-Konverter?

Wandelt Changelogs, Versionshinweise und Update-Ankündigungen in polierte, sofort einsetzbare Ozor.ai-Videoprompts um. Dieser Skill liest strukturierte Änderungslisten und erzeugt szenenweise Videoprompts, die Updates visuell ansprechend präsentieren.

Unterstützte Eingabetypen

• CHANGELOG.md — Standardformat nach Keep a Changelog
• GitHub Releases — Release-Beschreibungen mit Tags
• Versionshinweise — Aufzählungen neuer Funktionen
• Versionszusammenfassungen — „Was gibt es Neues“-Dokumente
• Commit-Zusammenfassungen — Gruppierte Commit-Nachrichten für ein Release
• Jira/Linear-Release-Notes — Exportierte Aufgabenlisten

Arbeitsablauf

Phase 1 – Changelog parsen

Lies das Changelog und extrahiere:

1. Versionsnummer — der Release-Tag (z. B. v2.4.0)
2. Veröffentlichungsdatum — wann es erschienen ist
3. Änderungskategorien — gruppiere Änderungen nach Typ:
   • Neue Funktionen — völlig neue Möglichkeiten
   • Verbesserungen — Erweiterungen bestehender Funktionen
   • Fehlerbehebungen — behobene Probleme
   • Breaking Changes — alles, was Benutzereingriffe erfordert
   • Veraltungen — auslaufende Funktionen
4. Hauptänderung — die wichtigste oder am meisten gewünschte Änderung
5. Anzahl der Änderungen — Gesamtzahl (wird für die Längenschätzung verwendet)

Phase 2 – Für das Video priorisieren

Nicht jeder Changelog-Eintrag verdient eine Szene. Wende diese Regeln an:

Immer einfügen:

• Die Hauptfunktion (größte oder meistgewünschte Änderung)
• Jede neue Funktion, die den Arbeitsablauf des Benutzers ändert
• Breaking Changes (Benutzer müssen es wissen)

Einfügen, wenn der Platz reicht:

• Bedeutende Verbesserungen (Leistung, UX)
• Stark nachgefragte Fehlerbehebungen

Im Video überspringen (in Notizen erwähnen):

• Kleinere Fehlerbehebungen
• Interne Umstrukturierungen
• Abhängigkeitsaktualisierungen
• Dokumentationsänderungen

Szenenbudget nach Änderungsanzahl (Ziel ~1 Szene pro 3 Sekunden Video):

• 1–3 Änderungen: 6–8 Szenen (Intro + 2–3 pro Änderung + Zusammenfassung + CTA)
• 4–7 Änderungen: 10–15 Szenen (Intro + 2–3 pro Top-Änderung + Zusammenfassung + CTA)
• 8+ Änderungen: 15–20 Szenen (Intro + 2–3 pro Top-Änderung + „und mehr“ + CTA)

Phase 3 – Das Video strukturieren

Verwende diese bewährte Struktur für Release-Videos:

1. Intro / Versionsabzeichen — Zeige Produktname und Versionsnummer mit einer sauberen Animation. Setze den Ton: „Was gibt es Neues in [Produkt] [Version]“
2. Hauptfunktion (2–3 Szenen) — Die größte Änderung bekommt mehrere Szenen mit der meiste Aufmerksamkeit:
   • Titel / Was es ist — Funktionsname als Überschrift mit einem einleitenden Satz.
   • Wie es funktioniert / Visual — Zeige die Funktion in Aktion: einen UI-Durchlauf, eine Animation oder ein Diagramm.
   • Auswirkung / Nutzen — Warum dies für den Benutzer wichtig ist. Zeige das Ergebnis.
3. Weitere Funktionsszenen (2–3 Szenen pro Funktion) — Jede priorisierte Änderung bekommt ihre eigene Mini-Sequenz:
   • Titel / Was es ist — Funktionsname und kurze Beschreibung.
   • Detail / Visual — Zeige visuell, was sich geändert hat: Vorher/Nachher, Demo oder Diagramm.
   • (Optional) Nutzen — Eine kurze Szene, die den Wert unterstreicht, wenn die Änderung bedeutend genug ist.
4. Zusammenfassung / „Und mehr“ — Wenn Änderungen herabgestuft wurden, füge eine Szene hinzu, die sie kurz auflistet: „Plus: [Fehlerbehebung 1], [Fehlerbehebung 2], [Verbesserung 1]“
5. CTA — „Jetzt aktualisieren“, „Noch heute ausprobieren“ oder „Lies die vollständigen Versionshinweise unter [URL]“

Phase 4 – Den Ozor-Prompt generieren

Gib einen vollständigen, kopierfertigen Prompt aus:

## Ozor Video Prompt

**Quelle:** [Produkt] [Version] Changelog
**Videotyp:** Versionshinweise / Was gibt es Neues
**Format:** 16:9 Querformat
**Geschätzte Dauer:** [X] Sekunden
**Zielgruppe:** [bestehende Benutzer / Entwickler / Team]

---

### Prompt (in Ozor einfügen)

Erstelle ein [Dauer]-sekündiges Versionshinweise-Video für [Produkt] Version [X.X].

[N] Szenen:

(1) Versionsabzeichen — [Produkt]-Logo zentriert auf [dunklem/hellem] Hintergrund. Versionsnummer „[X.X]“ erscheint mit einer dezenten Animation. Untertitel: „[Veröffentlichungsdatum] — [Slogan oder Zusammenfassung der Änderungsanzahl]“.

(2) [Name der Hauptfunktion] — Titelbild: Funktionsname als fette Überschrift. Einleitender Satz: „[Was diese Funktion in einfacher Sprache tut]“. [Visual: Symbol oder Grafik, die die Funktion repräsentiert.]

(3) [Name der Hauptfunktion] Detail — [Zeige die Funktion in Aktion: UI-Durchlauf, Bildschirmaufnahme-Animation oder Schritt-für-Schritt-Diagramm. Füge exakten Bildschirmtext ein.]

(4) [Name der Hauptfunktion] Auswirkung — [Warum das wichtig ist: zeige das Ergebnis, Zeitersparnis oder Vorher/Nachher-Vergleich. Bildschirmtext: „[Wichtigste Nutzenaussage].“]

(5) [Funktion 2 Name] — Titelbild: „[Funktionsname]“ mit einzeiliger Beschreibung. [Visual: Symbol, UI-Element oder Metapher.]

(6) [Funktion 2 Name] Detail — [Visuelle Demonstration der Funktion: wie sie in der Anwendung aussieht, wie sie funktioniert oder ein wichtiger Screenshot-artiger Frame. Bildschirmtext einfügen.]

(7) [Funktion 3 Name] — [Funktionstitel + visuelle Anweisung. Für kleinere Funktionen reicht eine einzelne Szene, die Titel und Demo kombiniert.]

[...weiter für verbleibende Funktionen, 2–3 Szenen pro Hauptfunktion, 1 Szene für kleinere Funktionen...]

([N-1]) Und Mehr — Saubere Liste der restlichen Änderungen: „[Fehlerbehebung 1]“, „[Verbesserung 1]“, „[Fehlerbehebung 2]“. Jede erscheint mit einer Haken-Animation.

([N]) CTA — „[Jetzt aktualisieren / Heute ausprobieren]“ mit [Produkt-URL]. Logo ausgeblendet.

Stil: [sauber / modern / kühn]. Hintergrund: [dunkel / hell]. Akzentfarbe: [Markenfarbe].
Tonfall: [selbstbewusst / begeistert / professionell].
Publikum: [wer].

---

### Hinweise

- [Vorschläge für hochzuladende Assets]
- [Änderungen, die herabgestuft wurden und ein separates Video werden könnten]
- [Tipps zur Iteration]

Anpassungsregeln

Wenn das Changelog nur Fehlerbehebungen enthält:

• Rahme es als Zuverlässigkeits-/Qualitätsupdate ein
• Beginne mit „Wir haben zugehört“ oder „Bugs beseitigt“
• Gruppiere Fehler thematisch anstatt jeden einzeln aufzulisten
• Halte es kurz: maximal 3–4 Szenen

Wenn das Changelog eine Breaking Change enthält:

• Hebe sie deutlich hervor – Benutzer müssen sie sehen
• Verwende einen visuellen Warnhinweis (Farbwechsel, Symbol)
• Erkläre, was sich geändert hat UND was der Benutzer tun muss
• Platziere sie in Szene 2 (direkt nach dem Intro) für Sichtbarkeit

Wenn das Changelog mehrere Versionen umfasst:

• Kombiniere zu einem „Quartals-Update“ oder „Jahresrückblick“-Format
• Gruppiere nach Thema statt nach Versionsnummer
• Beginne mit den wirkungsvollsten Änderungen aus allen Versionen

Wenn das Changelog aus einem GitHub Release stammt:

• Extrahiere den Release-Titel als Video-Überschrift
• Verwende den Tag-Namen als Versionsabzeichen
• Parse Markdown-Formatierung für Aufzählungspunkte und Überschriften

Qualitätscheckliste

Bevor du den endgültigen Prompt präsentierst, überprüfe:

• Versionsnummer wird in Szene 1 prominent angezeigt
• Die Hauptfunktion erhält die meiste visuelle Aufmerksamkeit
• Breaking Changes sind deutlich hervorgehoben (falls vorhanden)
• Jede Szene enthält genau eine Änderung oder Idee
• Bildschirmtext ist kurz – Funktionsnamen + einzeilige Beschreibungen
• CTA sagt dem Benutzer genau, was zu tun ist
• Keine kritischen Änderungen aus der Quelle wurden ohne Erwähnung ausgelassen
• Herabgestufte Änderungen sind im Abschnitt „Hinweise“ aufgeführt

Regeln

1. Jede Änderung, die eine Szene bekommt, muss visuell beschrieben werden. „Zeige das neue Dashboard“ reicht nicht – beschreibe, wie das Dashboard aussieht, was animiert ist, welcher Text erscheint.
2. Erfinde niemals Funktionen. Jede Änderung muss aus dem Quell-Changelog stammen.
3. Priorisiere Benutzerauswirkung über technische Beeindruckbarkeit. Eine kleine UX-Korrektur, die Benutzer gewünscht haben, ist videowürdiger als eine große interne Umstrukturierung.
4. Halte es knackig. Release-Videos sollten 30–60 Sekunden lang sein. Ein 30-Sekunden-Video sollte etwa 8–10 Szenen haben; ein 60-Sekunden-Video etwa 15–18 Szenen (ungefähr 1 Szene pro 3 Sekunden). Benutzer wollen Highlights, keine Dokumentation.
5. Die Versionsnummer muss sichtbar sein. Sie erscheint in Szene 1 und optional als dauerhaftes Abzeichen.