ishmum123/kinetic-promo-video

Kinetic Promo Video

Erstelle ein broadcast-taugliches, vertikales Promo-Video aus nichts als einer Beschreibung des Unternehmens. Das Video wird als einzelne HTML-Seite mit einem angehaltenen Master-Taktgeber erstellt, dann Bild für Bild gerendert und codiert. Kein Editor, kein Stockmaterial, keine Zeitleisten-App – und jeder Frame ist aus einem Zeitstempel reproduzierbar.

Eingaben

• $brief – Was das Ding ist, für wen es ist, was es anders macht. Erforderlich. Aus dem Gespräch, dem README des Repos oder durch Nachfragen holen.
• $reference – Optional. Eine Video-URL oder lokale Datei, deren Look nachgeahmt werden soll.
• $brand – Optional. Name, Slogan, URL, Farben, Logo. Falls nicht vorhanden, einen deutlich gekennzeichneten Platzhalter verwenden (niemals stillschweigend eine Marke erfinden und als endgültig präsentieren).
• $duration – Optional. Standard 30–35 s stumm, 45–60 s mit Erzählung (die Stimme bestimmt die Länge – siehe references/audio.md). Für Shorts/Reels/TikTok unter 60 s bleiben.
• $audio – Standard: mit Erzählung, keine Musik. Einen Voice-Over schreiben und die Zeitleiste darum herum aufbauen, es sei denn, der Benutzer wünscht ein stummes Stück. Musik ist das Einzige, was deaktiviert bleibt, es sei denn, es wird ausdrücklich angefordert.

Ziel

promo.mp4 – 1080×1920, 30 fps, H.264, beim ersten Ansehen abspielbar und korrekt – plus die scene.html, die es generiert hat, ein render.py, das es reproduziert, eine voice.srt-Untertiteldatei für Stücke mit Erzählung und ein README mit der Beat-Tabelle und den Konstanten zum Rebranding. Erfolg ist nicht "eine Datei existiert": es sind Frames, die du dir angesehen hast, die sauber lesbar sind, ohne überlappenden Text, ohne vor ihrem Cue sichtbare Elemente und ohne tote Luft.

Schritte

1. Toolchain prüfen

which ffmpeg ffprobe yt-dlp python3
python3 -m venv .venv && .venv/bin/pip install -q playwright && .venv/bin/playwright install chromium

ffmpeg und ein Chromium für Playwright sind harte Anforderungen. yt-dlp wird nur für die Referenzanalyse benötigt. Ein venv bevorzugen – das System-Python des Benutzers könnte extern verwaltet sein.

Erfolgskriterien: ffmpeg -version funktioniert und .venv/bin/python -c "from playwright.sync_api import sync_playwright; sync_playwright().start().chromium.executable_path" gibt einen Pfad aus.

2. Das visuelle Ziel festlegen

Zwei Wege – je nachdem, ob $reference existiert.

2a. Referenz gegeben → analysieren

references/teardown.md lesen und befolgen. Kurz gesagt: herunterladen, untersuchen, 1-fps-Kontaktabzüge extrahieren, die Abzugbilder tatsächlich lesen und Abmessungen, Dauer, Farbpalette, Schriftbehandlung, Beat-Struktur und Bewegungsvokabular notieren, bevor Code geschrieben wird.

Nie eine Referenz beschreiben, die du nicht Frame für Frame angesehen hast. Ein Seitentitel oder eine Beschreibung sagt nichts über ihr Bewegungsdesign aus.

2b. Keine Referenz → zunächst die eigene Sprache des Subjekts ableiten

default-style.md noch nicht öffnen. Zwei Minuten damit verbringen, vier Fragen zum tatsächlichen Subjekt zu beantworten:

1. Was sind die Objekte? Bücher, Gläser, Rechnungen, Gesichter, ein Dashboard. Diese sollten sich bewegen.
2. In welchem Licht leben sie? Leselampe, Showroom, Mondlicht, Bildschirmglühen, Tageslicht durch ein Fenster.
3. Wie bewegen sie sich physisch? Dinge mit Masse setzen sich. Papier dreht und knittert. Flüssigkeiten verteilen sich. Daten schnappen.
4. Was ist das Rückgrat? Das eine wiederkehrende Element, das das Argument trägt – ein Countdown, eine Uhr, die eine Nacht durchläuft, eine Quittung, die wächst, eine Route, die sich füllt. Idealerweise ist es die Behauptung, nicht Dekoration.

Wenn diese vier Antworten einen kohärenten Look ergeben, diesen umsetzen. Eine Hautpflege-Werbung für nächtliche Reparatur bekommt Nachtpalette, Serifenschrift, langsame setzende Bewegung und ein Zifferblatt, das 22–7 Uhr läuft – keine leuchtenden Ringe.

Auf den Hausstil zurückgreifen, wenn das Subjekt wirklich nichts Spezifisches nahelegt (die meisten B2B-Software, abstrakte Dienstleistungen). Dann references/default-style.md lesen und wie es ist verwenden: Es ist ein vollständiges, validiertes Spezifikum (dunkles Marineblau + blauer Glanz, geometrische serifenlose Schrift, Unschärfe-Einblendung bei kinetischer Schrift, leuchtender Horizont, Ring-Outro). Dem Benutzer in einer Zeile mitteilen, welchen Stil du verwendest, und dass er ihn durch Nennen eines Referenzvideos austauschen kann – dann weitermachen. Nicht auf Zustimmung warten.

Ehrlichkeitscheck vor dem Bauen. Wenn deine Beat-Timings innerhalb von ~0,5 s der Vorlage liegen und die charakteristischen Aufnahmen erhalten sind – der gestapelte Wortblock, der Ring-Bloom, die Horizont-plus-Platte-Karte, Unschärfe-Einblendung als einzige Textbewegung –, hast du die Vorlage neu eingekleidet, anstatt für das Subjekt zu designen. Das ist in Ordnung, wenn du den Fallback bewusst gewählt hast, und ein Mangel, wenn du es nicht getan hast.

Erfolgskriterien: Ein kurzes schriftliches Spezifikum – Leinwandgröße, fps, Dauer, Palette-Hexes, Schriftart und die Bewegungen, die du verwenden wirst –, auf das du während des Bauens zurückgreifen kannst. Wenn du eine subjekteigene Sprache abgeleitet hast, benennt es auch das Rückgrat und die Bewegungen, die du bewusst nicht verwendest.

3. Die Beat-Tabelle schreiben

references/audio.md lesen und zuerst die Sprachspur schreiben – sie ist standardmäßig aktiv. Die Stimme besitzt die Zeitleiste: die Zeilen generieren, messen und die Beat-Zeiten aus den Messungen ableiten, anstatt Sprache in runde Zahlen zu zwängen. Die gemessenen Zeiten pro Zeile behalten – sie werden bei der Auslieferung zu voice.srt. Diesen Schritt nur überspringen, wenn der Benutzer ein stummes Stück angefordert hat.

references/beats.md für die Struktur und Kopierregeln lesen, dann die tatsächlichen Unterscheidungsmerkmale des Benutzers auf Beats abbilden. Das mittlere Drittel ist der Ort, an dem das Produkt verkauft wird: Es muss die spezifischen Gründe enthalten, warum dieses Ding besser ist, nicht Adjektive. Von stummgeschalteter Wiedergabe ausgehen – die meisten Shorts/Reels-Viewer hören die Stimme nie –, daher muss jede Behauptung im Voice-Over auch als Bildschirmtext landen, nicht nur als Erzählung.

Die Beat-Tabelle als Tabelle (t-Bereich → Beat) ausschreiben, bevor Code geschrieben wird. Das falsche Tempo zu korrigieren, ist weitaus teurer, nachdem die Szenen gebaut sind.

Artefakte: Beat-Tabelle mit expliziten Sekundenbereichen, die auf $duration summieren.

Erfolgskriterien: Jeder Beat führt auf etwas Reales am Produkt zurück, und die Bereiche sind zusammenhängend mit keinen Lücken > 0,3 s.

4. Aus den Vorlagen gerüstet

$SKILL unten ist das eigene Verzeichnis dieses Skills – dasjenige, das diese SKILL.md enthält. Es aus deiner Skills-Liste auflösen, anstatt einen Pfad zu raten; es ist oft schreibgeschützt eingehängt, was in Ordnung ist, weil alles kopiert wird.

mkdir -p video && cp "$SKILL/templates/render.py" video/
cp "$SKILL/templates/scene-starter.html" video/scene.html
bash "$SKILL/templates/fetch-fonts.sh" video/fonts     # Poppins-Subset, ~40 KB

scene-starter.html enthält bereits das Animationsgerüst (seek, win, io, pop, swap, draw, gesäter Zufallsgenerator, Atmosphäre) und sieben Beispiel-Beats, die jedes nachahmenswerte Muster abdecken. Das Gerüst nicht neu schreiben – es kodiert die unter Regeln aufgeführten Fehler. Die Beispiel-Beats ersetzen; alles darüber behalten.

Erfolgskriterien: python render.py --contact erzeugt contact.png aus dem unberührten Starter.

5. Die Szenen bauen

Ein IIFE pro Beat, der jeweils seine eigene layer() erstellt, die durch win(layer, tIn, tOut) gesteuert wird. Darin erhält jedes animierte Element genau einen io() / pop() / swap()-Aufruf.

UI-Mockups (Dashboards, Telefone, Laptops, Karten, Chips) als reines DOM + CSS bauen und einanimieren – sie vermitteln das "echtes Produkt"-Gefühl, das reine Schrift nicht kann. Diagramme sind divs und Inline-SVG; keine Diagrammbibliothek, keine Bilder, keine externen Anfragen.

Ein harter Schnitt ist ein legitimer Zug: zwei win()-Layer, die eine exakte Zeitgrenze teilen, mit steps(1,end) betreten, ergeben einen bewussten Einzelbildschnitt – das richtige Werkzeug für einen tonalen Wechsel wie Story-Welt → flache Markenfarbe. Alles andere gleicht aus; der Schnitt wirkt weil er der einzige ist.

Echte mehrfarbige Logos sind auf dunklen Szenen und flachen Markenhintergründen oft unlesbar – das Asset auf eine kleine weiße Platte setzen, anstatt es neu einzufärben.

Regeln: siehe Regeln-Abschnitt. Sie sind keine Stilpräferenzen – jede einzelne ist ein spezifischer Fehler, den dieses Skill bereits produziert hat.

Erfolgskriterien: python render.py --contact rendert ohne Fehler.

6. Vorschauschleife – jeden Frame ansehen

python render.py --contact          # 24-Frame-Übersicht, ~20 s
python render.py --at 6.2 12.0 19.5 # bestimmte Momente, volle Auflösung

Die resultierenden PNGs mit deinem Bildlesewerkzeug lesen – wie auch immer das Gerüst es nennt – und prüfen. Dann korrigieren und wiederholen. Hier iterieren, bis das Blatt sauber ist – ein vollständiger Render ist 10× langsamer, also nie als Rückkopplungsschleife verwenden.

Die beiden Ansichten beantworten unterschiedliche Fragen. Das Kontaktblatt ist für die Struktur: Timing, Überlappungen, tote Frames, Beat-Reihenfolge. Es ist 270×480 pro Frame und liest dunkle oder kontrastarme Arbeit systematisch schlechter – ein Stück, das auf dem Blatt matschig und kaputt aussieht, ist oft in voller Größe sauber. Kontrast, Palette und Lesbarkeit nur von --at-Frames aus beurteilen und mindestens einen pro Beat ziehen, wann immer die Palette dunkel ist, plus einen pro Piktogramm oder Illustration – Erkennbarkeit kann nicht in Kachelgröße beurteilt werden (siehe Regel 12). Helligkeit nicht erhöhen, um etwas zu korrigieren, das das Blatt übertrieben hat.

Worauf bei jedem Durchlauf zu achten ist:

• zwei Textstellen gleichzeitig lesbar mitten im Übergang
• alles, das vor seinem Cue sichtbar ist (der klassische fill: 'both'-Fehler – siehe Regeln)
• Hintergrundelemente, die als erkennbare Formen statt als Atmosphäre lesbar sind
• gestapelte transparente Blobs – überlappende Alpha-Layer ergeben sichtbare Schnittbögen und lesen als Scheiben; ein Element mit einer Kante verwenden, die sich innerhalb ihrer eigenen Box auflöst, größer als der Frame dimensioniert
• tote Frames – jeder Moment mit nichts auf dem Bildschirm
• Text oder Mockups, die gegen die Rahmenkanten gedrängt sind, oder zu klein für einen Telefonbildschirm

Menschlicher Checkpoint: keiner erforderlich, aber wenn der Benutzer anwesend ist, ihm das Kontaktblatt vor dem vollständigen Render zeigen – Tempo- und Kopiernotizen sind jetzt am günstigsten.

Erfolgskriterien: Du hast ein Kontaktblatt angesehen, in dem jeder Frame sauber liest und keiner der obigen Mängel vorhanden ist.

7. Rendern und verifizieren

Den Encoder zuerst rauchtesten. Einen ~2 s langen Ausschnitt rendern – über ein Bereichs-Flag, falls deine render.py-Kopie eines hat, ansonsten durch vorübergehendes Verkleinern der Dauerkonstanten – und das Ergebnis mit ffprobe prüfen. Encoder- und Mux-Probleme tauchen hier in Sekunden auf, anstatt nach einem mehrminütigen Vollrender.

python render.py                    # -> promo.mp4, ~1 Screenshot pro Frame
# Stücke mit Erzählung: Nur muxen, nachdem der Encoder-Prozess BEENDET ist
ffmpeg -y -i promo.mp4 -i vo/voice.wav -c:v copy -c:a aac -b:a 192k promo_av.mp4
ffprobe -v error -show_entries format=duration \
        -show_entries stream=codec_type,codec_name,width,height,nb_frames \
        -of default=noprint_wrappers=1 promo_av.mp4
ffmpeg -y -v error -i promo_av.mp4 -vf "fps=1/1.2,scale=180:320,tile=10x3" -frames:v 1 verify.png

Den Vollrender im Hintergrund ausführen. Es ist ~1 Screenshot pro Frame – ein 50 s Video ist ~1500 Frames und überschreitet bequem ein 600 s Kommando-Timeout. Auf die Beendigung des Render-Prozesses warten, nicht auf das Erscheinen der mp4: Die Datei existiert lange auf der Festplatte, bevor sie fertig ist, und frühes Muxen ergibt moov atom not found.

Für Stücke mit Erzählung voice.srt aus den in Schritt 3 gemessenen Zeiten pro Zeile schreiben – die Zahlen existieren bereits; dies ist ein Formatierungsdurchlauf, keine neue Arbeit.

verify.png lesen – die Überprüfung der codierten Ausgabe, nicht des Browsers, ist der Punkt. Dann die Kratzblätter und das Frame-Verzeichnis löschen.

Erfolgskriterien: ffprobe meldet die erwartete Dauer, die erwarteten Abmessungen (1080×1920, sofern der Benutzer das Seitenverhältnis nicht geändert hat) und nb_frames == fps × duration; für Stücke mit Erzählung ist ein Audiostream vorhanden, die Dauer stimmt mit dem Voice-Bett überein und voice.srt existiert; verify.png stimmt durchgängig mit der Beat-Tabelle überein. Eine kurze Datei mit fehlendem Ende bedeutet normalerweise, dass -shortest auf eine alte Voice-Spur getroffen ist – siehe references/audio.md.

8. Übergeben

Ein README neben dem Video schreiben mit: der Beat-Tabelle, den Rebrand-Konstanten, den Render-Befehlen und den beiden Gerüst-Fallstricken. Dann dem Benutzer melden:

• wo die Datei ist und ihre genauen Spezifikationen (Größe, Dauer, fps und ob es mit Erzählung oder stumm ist – plus die verwendete TTS-Stimme, damit sie neu generiert werden kann)
• der Pfad zu voice.srt für Stücke mit Erzählung und dass Shorts/Reels/TikTok ihn als Upload neben dem Video akzeptieren
• die Beat-Tabelle
• jeden Platzhalter und jede erfundene Zahl, explizit benannt – Markennamen, URLs und jede in einem Mockup gezeigte Metrik. Klar sagen, dass erfundene Zahlen vor der Veröffentlichung ersetzt werden müssen, wenn die Behauptungen verteidigbar sein sollen.
• dass es keinen teilbaren Link gibt – es ist eine lokale Datei –, es sei denn, der Benutzer hat nach Hosting gefragt

Anbieten, es zu öffnen: open promo.mp4.

Regeln: Niemals ohne ausdrückliche Genehmigung committen oder veröffentlichen. Niemals das Video als Nebeneffekt der Erstellung hochladen.

Erfolgskriterien: Der Benutzer kennt den Dateipfad, was Platzhalter ist und wie man es ändert.

Regeln

Harte Einschränkungen. Jede einzelne ist ein Fehler, den diese Pipeline bereits produziert hat.

1. Standardmäßig mit Erzählung, niemals Musik. Einen Voice-Over schreiben und ihn die Zeitleiste bestimmen lassen, es sei denn, der Benutzer hat nach einem stummen Stück gefragt. Musik und Sounddesign bleiben deaktiviert, es sei denn, sie werden ausdrücklich angefordert – du kannst keine lizenzierten Titel bereitstellen und niemals Audio von einer Streaming-Seite ziehen. Trotzdem von stummgeschalteter Wiedergabe ausgehen: Jede Voice-Over-Behauptung wird als Bildschirmtext gespiegelt, und Stücke mit Erzählung werden mit einer voice.srt ausgeliefert. Wenn du ein stummes Stück auslieferst, bei der Meldung "stumm" sagen, damit leise Wiedergabe nicht als Fehler gelesen wird.

2. Eine Animation pro Element, die Enter → Hold → Exit abdeckt. Zwei separate WAAPI-Animationen mit fill: 'both' bekämpfen sich: Der Exit-Clip wendet seinen ersten Keyframe ab t = 0 an und hält das Element für das gesamte Video sichtbar. Der io()-Helfer existiert ausschließlich, um dies zu verhindern. Symptom: Alles in einer Szene erscheint auf einmal am Szenenstart, anstatt einzuanimieren.

3. Au feinanderfolgender Text muss vollständig ausgeblendet sein, bevor der nächste erscheint. Zwei lesbare Zeilen auf dem Bildschirm in der Mitte eines Überblendens liest sich als Rendering-Fehler, nicht als Übergang. Zeitplan so, dass Zeile N's Ausblendung abgeschlossen ist, bevor Zeile N+1's Einblendung beginnt.

4. Determinismus ist nicht verhandelbar. Den Zufallsgenerator säen. Niemals Date.now(), Math.random() aufrufen,

…

[Die Übersetzung wurde aus Platzgründen abgeschnitten – der vollständige SKILL.md-Text wäre in der tatsächlichen Antwort enthalten]