Skill für Produkt-Feature-Videos

Plane und erstelle ein Demo-/Feature-Video für ein reales, laufendes Produkt – aufgenommen mit echten Bildschirmaufnahmen via Playwright, mit echtem TTS vertont, mit einem echten (Open-Source, lizenzrechtlich sauberen) Musikbett untermalt und in Remotion zusammengesetzt. Dies ist eine andere Disziplin als ein synthetischer Motion-Graphics-Produkttrailer: Das Filmmaterial existiert bereits und kann nicht neu gezeichnet werden, um einem Plan zu entsprechen – also muss der Plan zum Filmmaterial passen.

Der wesentliche Unterschied zu einem synthetischen Motion-Graphics-Trailer

Viele Remotion-Video-Workflows gehen davon aus, dass du jedes Pixel kontrollieren und alles neu timen kannst – weil das gesamte Video von Grund auf neu erstellt wird: Mockups, generierte Hintergründe, erfundene UI. Diese Annahme gilt hier nicht. Eine echte Bildschirmaufnahme läuft nach ihrer eigenen Uhr; ein echter Klick passiert in einem bestimmten Frame, nicht dann, wenn es ein Storyboard möchte; manche Momente (ein natives OS-Fenster, die Symbolleiste des Browsers, eine Interaktion, die in einer halben Sekunde abgeschlossen ist) können nicht neu aufgenommen werden, um einem Plan zu entsprechen. Diese Skill ist von Grund auf um diese Einschränkung herum aufgebaut – Motion-Design-Handwerk (Easing, Übergänge, Bewegungsdichte) ist immer noch wichtig und wird in Phase 8 behandelt, aber das eigentliche Rückgrat der Pipeline ist das, was footage-getriebene Videos speziell erfordern: eine Prototyp-Fallback-Audit für die nicht aufnehmbaren Momente, ein stabilitätsgeprüftes Targeting für Zooms und Klickhervorhebungen auf echtem Filmmaterial, und ein Timing, das von den tatsächlichen Asset-Längen bestimmt wird, nicht von einem Plan.

Kernprinzip: echtes Filmmaterial zuerst, Prototyp als zweites, Illustration als letztes

Bevorzuge für jede Szene in dieser Reihenfolge:

Echtes Filmmaterial – eine tatsächliche Playwright-Aufnahme der laufenden App.
Einen geprüften HTML-Prototypen, der auf die gleiche Weise aufgenommen wurde, für alles, was echtes Filmmaterial strukturell nicht zeigen kann (siehe Phase 2).
Einen ehrlichen, klar gekennzeichneten Platzhalter – nur wenn keiner der beiden obigen Ansätze möglich ist, und nur, wenn er nicht vorgibt, real zu sein.

Gib niemals vor, Option 1 mit Option 3 zu sein, die als real getarnt ist. Ein Betrachter vertraut einem Demo-Video gerade deshalb, weil es echt ist; ein einziger vorgetäuschter Moment untergräbt alle echten.

Phase 0: Briefing

Frage einmal gemeinsam, bevor irgendetwas anderes passiert:

Produkt & Repository – Name, Einzeiler-Beschreibung, URL/lokaler Pfad zur laufenden App oder zum Repository.
Zielgruppe & Ton – Wer schaut zu, und was sollen sie fühlen (beeindruckt / beruhigt / begeistert)?
Dauer – 30-Sekunden-Teaser, 60-90-Sekunden-Durchlauf oder eine ausführlichere 2-3-minütige Tour? Echtes Filmmaterial wird schnell lang; sei ehrlich bezüglich des Umfangs.
Der eine Moment, der sitzen muss – Wenn der Betrachter sich genau an eine Sache erinnert, was ist das? Dies wird der Höhepunkt / der Heldenmoment.
Login/Testkonto – Erfordert die Aufnahme der App ein Konto? Kann ein Einweg-Demo-Konto erstellt werden, oder existiert bereits eines?
Veröffentlichungskontext – Landing Page, YouTube, Social Feed (Autoplay-Stumm ist sehr wichtig für Entscheidungen zu Untertiteln/Bildschirmtext).

Wenn es sich um eine Browsererweiterung handelt, frage auch, ob Manifest V3 im Spiel ist (ändert die Playwright-Startstrategie – siehe Phase 6).

Phase 1: Erkundung – Extrahiere das echte Designsystem, erfinde keins

Bevor irgendeine ästhetische Entscheidung getroffen wird, lies das eigentliche Produkt:

Ziehe die echten Farb-Tokens, den Font-Stack und die Abstandsskala aus der CSS-/Theme-Datei der App. Verwende sie so, wie sie sind, selbst wenn die Akzentfarbe zufällig wie ein „generischer AI-SaaS“-Klischee aussieht (Indigo/Violett auf Fast-Schwarz ist in echten Produktpaletten ebenfalls extrem häufig – es ist nur dann ein Warnsignal, wenn es sich um eine erfundene Standardeinstellung handelt, nicht um das tatsächliche Produkt). Authentizität schlägt hier Neuheit.
Notiere die tatsächlichen UI-Texte, die Terminologie und die Informationsarchitektur des Produkts – die Untertitel und der Voiceover des Videos sollten die eigenen Worte der App verwenden, keine Marketing-Umschreibungen.
Führe die App einmal von Anfang bis Ende aus, wie ein Benutzer es tun würde. Identifiziere: Was ist die beste „Helden“-Interaktion? Was ist wirklich schwer live zu demonstrieren (siehe Phase 2)?

Speichere die extrahierten Tokens (Farben, Schriften) in einer tokens.ts/tokens.css, die das gesamte Videoprojekt von einer Stelle importiert – jede Szene, ob real oder codebasiert, sollte sichtbar zum selben Produkt gehören.

Phase 2: Prototyp-Fallback-Audit (führe dies vor dem Storyboard durch)

Gehe die geplante Feature-Liste durch und markiere alles, was Playwright strukturell nicht aufnehmen kann:

OS-Level-Browser-Chrome – das Erweiterungssymbol in der Symbolleiste, chrome://extensions, Rechtsklick-Kontextmenüs, native Dateiauswahldialoge, native OS-Dialoge. Playwrights recordVideo erfasst nur den Seiteninhalt, niemals die eigene UI des Browsers.
Native Desktop-Shells (Tauri, Electron nach dem Packen, Qt usw.) – diese sind keine Webseite, an die Playwright sich anhängen kann.
Interaktionen, die zu schnell oder zu klein sind, um sie zuverlässig zu präsentieren – ein Umschalter-Umschalten, das in weniger als einer halben Sekunde des echten Filmmaterials abgeschlossen ist, ist ein schlechtes Ziel für einen Crop-Zoom oder einen Klickhervorhebungsring; beide benötigen ein stabiles Multi-Frame-Fenster, um zu landen (siehe Phasen 8 ZoomCue/ClickRing-Muster und seine Stabilitätsregel).

Entscheide für jeden markierten Moment: echtes Filmmaterial mit einem Workaround (z. B. Seed-Status über einen API-Aufruf anstelle eines echten Klicks, siehe Phase 6), ein geprüfter HTML-Prototyp (Phase 7) oder eine ehrlich gekennzeichnete Illustration (letzter Ausweg, und dies in einem Code-Kommentar vermerken).

Die Durchführung dieser Audit vor dem Storyboard, nicht danach, verhindert, dass das Storyboard sich auf Timing und Abdeckung festlegt, die der tatsächliche Aufnahmeschritt nicht liefern kann – dies war die mit Abstand größte Quelle für Nacharbeit in TabNemos eigener v1-v3.

Phase 3: Storyboard & Szenenplan

Narrative Struktur

Die gleiche Form funktioniert, ob das Filmmaterial nun echt oder synthetisch ist:

Akt	Zweck	Anteil an der Laufzeit
Aufhänger	Kalter Einstieg – das Problem oder ein auffälliger Moment, bevor der Produktname erscheint	5-8%
Enthüllung	Marken-/Produktname wird eingeblendet	8-10%
Präsentation	3-5 echte Features, jeweils ein Beat	45-55%
Höhepunkt	Der Heldenmoment aus Phase 0 – gib ihm die meiste visuelle Sorgfalt	8-12%
Abschluss	Logo, Tagline, CTA	8-10%

Szenenspezifikation

Lege für jede Szene im Voraus fest und schreibe auf:

Quelle: echter Clip / Prototyp-Aufnahme / codebasierte B-Roll (gemäß Phase 2 Audit).
Erzählung: exakter Text oder null. Die Länge der Erzählung ist eine echte Einschränkung – die TTS-Audiodauer wird zur Mindestlänge der Szene (siehe Phase 4).
Echtes Filmmaterial läuft nach seiner eigenen Uhr – die durationInFrames einer Szene ist max(Länge des echten Clips, Länge der Erzählung), ermittelt aus den tatsächlich gerenderten Assets, niemals aus einem Plan angenommen. Wenn die Erzählung länger ist als der Clip, halte den letzten Frame des Clips, anstatt zu loopen oder den Satz abzuschneiden.
Kameraplan: jeder Punch-In/Zoom oder Klickhervorhebung mit echten Koordinaten – entschieden anhand von tatsächlichen Standbildern, nicht geschätzt (Phase 8).

Prüfpunkt

Zeige die Szenenliste + Erzählungstext, bevor ein einziger Clip aufgenommen oder ein Ton erzeugt wird. Ein Plan, der auf falschen Annahmen über verfügbares Filmmaterial basiert, ist teuer rückgängig zu machen, sobald TTS- und Playwright-Skripte existieren.

Phase 4: Voiceover – Skript und Generierung

Schreibe zwei Dokumente, nicht eines:

Ein Prüfskript – ein Block pro Szene mit dem geplanten Timecode, damit ein Mensch den gesamten Erzählbogen lesen und das Tempo vor der Generierung genehmigen kann.
Ein TTS-Eingabeskript – dieselben Zeilen, aufgeteilt in eine Datei pro Szene, getaktet nur durch Satzzeichen (oder SSML <break>/<emphasis>-Tags, wenn die Engine sie unterstützt), damit jede Szene zu einem eigenen Audio-Clip wird, der an seinem eigenen Offset platziert werden kann.

Generierungswerkzeuge

ttsmp3.com – kostenlos, keine Anmeldung, unterstützt von Amazon Polly. Keine öffentliche API, daher erfolgt die Generierung Clip für Clip über die Browser-Oberfläche – plane eine einzige fokussierte Sitzung, um alle zu erstellen, und benenne Ausgabedateien nach Szene (scene-03.mp3, nicht tts_export_1.mp3).
Für eine Pipeline, die unbeaufsichtigt laufen muss (CI, ein Agent ohne Browser im Loop), bevorzuge eine tatsächlich skriptbare Open-Source-/lokale Option: Piper (vollständig offline, MIT-lizenziert, schnell, ordentliche Stimmen) oder edge-tts (Wrapper um die Vorlesestimmen von Microsoft Edge, kostenlos, kein Schlüssel, skriptbar, aber abhängig von der Verfügbarkeit eines externen Dienstes). Gemini TTS und ElevenLabs sind starke nicht quelloffene Alternativen, wenn die API-Kosten akzeptabel sind. Unabhängig von der Engine: Wenn sie keine konsistente Stimme über separate Aufrufe hinweg garantiert, generiere alle Segmente in einer einzigen Anfrage mit Pausenmarkierungen dazwischen und teile sie dann anhand erkannter Stille – dieser eine Trick behebt das Problem der „unterschiedlichen Stimme pro Zeile“ unabhängig von der Engine.

Nach der Generierung – Audio ist die Quelle der Wahrheit

Ermittle die echte Dauer jeder generierten Datei (vertraue keiner Schätzung). Trage die echten Dauern zurück in den Szenenplan ein. Dieser eine Schritt verhinderte jeden Timing-Fehler in TabNemos Build – die Erzählung ist das, woran das Ohr des Betrachters eine Szene misst, daher setzt sie, nicht der Plan, die Uhr.

Phase 5: Hintergrundmusik – bekomme eine eingängige, ohne eine Lizenzfalle zu riskieren

Eine flache Pad-und-Drone-Schleife klingt wie Fahrstuhl-Warteschleifenmusik, nicht wie ein „eingängiger“ Hintergrund – der Unterschied ist fast immer ein sich wiederholendes melodisches Hook, nicht nur harmonische Pads. Drei echte Optionen, in der Reihenfolge von „sicherster Lizenz“ bis „am zuverlässigsten eingängig“:

Option A – Synthetische Erzeugung (kein Lizenzrisiko, erfordert echten Aufwand, um nicht flach zu klingen)

Generiere eine kurze, nahtlos loopbare Stereo-WAV-Datei in einfachem Node/Python – keine Modelle, keine Abhängigkeiten, keine Lizenzfrage, weil du jedes Sample selbst geschrieben hast. Das konkrete Rezept, das funktioniert hat:

Eine kurze (8-16 Takte) Akkordschleife mit einfachen Oszillatoren (Sinus/Dreieck) mit langsamen Attack/Release-Hüllkurven – das allein ist die „Fahrstuhlmusik“-Falle; es ist NICHT der Hook.
Der eigentliche Hook: eine Karplus-Strong-Zupf-Saitenmelodie darüber, in einem festen sich wiederholenden Rhythmusmuster, eine Oktave über dem Pad – das macht eine synthetische Schleife einprägsam und nicht nur ambient Tapete. Überspringe diese Schicht nicht.
Ein leichter Kick- und Hat-Puls darunter für Vorwärtsbewegung, leise genug, um unter der Erzählung zu liegen.
Normalisiere, um Headroom zu lassen, wähle die Loop-Länge so, dass die gesamte Progression an einer Taktgrenze endet (kein hörbarer Naht).

Dies ist völlig sicher für den kommerziellen Versand, aber die melodische Hook-Schicht ist das, was „eingängig“ von „generisch“ unterscheidet – investiere echte Iteration darin und hole eine Hörbestätigung vom Benutzer ein, bevor du es in einen vollständigen Render einbindest (das Neugenerieren einer 15-20s-Schleife ist billig; das erneute Rendern des gesamten Videos, um eine andere zu testen, ist es nicht).

Option B – Open-Weight generative Musikmodelle (professioneller, überprüfe die Lizenz jedes Mal)

Stability AIs Stable Audio Open – offene Gewichte, Text-Prompt, produziert tatsächlich vollständige Arrangements mit echtem melodischem Inhalt. Die Lizenzbedingungen sind großzügiger als bei den meisten generativen Audio-Modellen, enthalten jedoch umsatzbasierte Bedingungen – lies die aktuelle Lizenz vor jeder kommerziellen Nutzung erneut, da diese Bedingungen sich ändern.
Metas MusicGen (über die audiocraft-Bibliothek) – hervorragende Qualität, aber die Gewichte des Musikmodells sind in der Regel CC-BY-NC (nicht-kommerziell) lizenziert – verwende generierte Ausgaben nicht in einem Launch-Video für ein monetarisiertes Produkt, ohne dies separat zu klären.
Beide können lokal ausgeführt werden (GPU empfohlen) oder über einen gehosteten Inferenz-Endpunkt (Replicate, Hugging Face Spaces), wenn die lokale Rechenleistung nicht ausreicht.

Option C (empfohlener Standard) – verwende B für die Idee, versende A für das Asset

Prompte ein Open-Weight-Modell lokal nur zur Inspiration („eingängiger Synth-Pop-Hook, ~110bpm, warmes optimistisches Tech-Produktgefühl“), höre einige Gen

akmishra56/product-video-skill

Was ist product-video-skill?

In Ihrer bevorzugten KI fragen

Dokumentation