Was macht GenVid Promo?
Erstelle das fertige Video, nicht nur ein Skript oder Storyboard. Baue eine deterministische Remotion-Komposition, deren Erzählung, visuelle Elemente, Produktaussagen und Timing überprüft sind.
Zwingender Start
- Überprüfe den Aufruf auf einen TTS-Anbieter und einen API-Key-Wert oder einen expliziten Verweis auf eine Umgebungsvariable / ein Secret.
- Fehlt eines von beiden, stoppe und frage: Welchen TTS-Anbieter soll ich verwenden und wie soll ich auf seinen API-Key zugreifen? Bevorzuge eine geheime Umgebungsvariable wie
OPENAI_API_KEYoderGEMINI_API_KEY; ich werde sie nicht festhalten oder ausdrucken. - Wähle nicht stillschweigend einen Anbieter, nimm keinen vorhandenen Schlüssel an, synthetisiere keine Platzhalter-Sprache und mache nicht hinter dieser Hürde weiter.
- Lade sofort den installierten Skill
remotion-best-practicesvollständig. Lade seine Regelvideo-layoutvor dem Design; lade seine Regeln für Audio, Übergänge, Untertitel, FFmpeg und Metadaten, wenn diese Funktionen verwendet werden. Sage explizit, dass diese Abhängigkeit verwendet wird. Ist sie nicht verfügbar, teile dies mit und verwende als minimalen Fallback references/production-pipeline.md. - Lies references/tts-providers.md, bevor du die Synthese implementierst. Überprüfe die aktuellen Anbietermodelle und SDK/API-Formate anhand der offiziellen Dokumentation, da sie sich ändern.
Arbeitsablauf
1. Das Briefing festlegen
Bestimme Produkt, Zielgruppe, Launch-Ziel, Plattform, Seitenverhältnis, Ziellänge, Tonfall, CTA, Sprache und erforderliche Behauptungen. Leite umkehrbare kreative Entscheidungen ab, wenn sie fehlen. Frage nur nach Entscheidungen, die das Ergebnis wesentlich verändern.
Standardmäßig: 1920x1080, 30 FPS, 35-75 Sekunden, ein Erzähler, Untertitel und ein klarer CTA. Füge vertikale oder quadratische Kompositionen hinzu, wenn der angeforderte Kanal sie benötigt.
2. Das echte Produkt überprüfen
Überprüfe das Repository und führe die eigentliche App aus, wenn verfügbar. Verfolge echte Routen, Komponenten, Datenzustände, Design-Tokens, Schriftarten, Icons, Texte, Plannamen, Preise und Feature-Verhalten. Bei einem Live-Produkt überprüfe die tatsächlich gerenderte Benutzeroberfläche mit Browser-Automation. Erfinde niemals einen Bildschirm, eine Fähigkeit, Metrik, Erfahrungsbericht, Preis oder Interaktion.
Verwende Produktvisuals in dieser Reihenfolge:
- Importiere echte Komponenten in eine kontrollierte Remotion-/Demo-Umgebung mit deterministischen Mock-Daten.
- Extrahiere animationssichere Anzeigekomponenten unter Beibehaltung des tatsächlichen DOM, der Tokens, Texte und Zustände.
- Erstelle quellabgeleitete Repliken nur, wenn echte Komponenten nicht außerhalb der App rendern können; vergleiche sie mit tatsächlichen Screenshots und lege dieses Fallback offen.
- Verwende Screenshots oder Bildschirmaufnahmen nur, wenn animationssichere Komponenten unpraktisch sind.
Gib keine Produktionsgeheimnisse preis und verändere keine Live-Daten, nur um einen Zustand zu filmen.
3. Die Geschichte und das Storyboard schreiben
Verwende einen kompakten Bogen: Aufhänger -> Problem -> Enthüllung -> Beweis durch echte Nutzung -> stärkste Vorteile -> CTA. Gib jeder Szene eine Botschaft und einen fokussierten visuellen Schwerpunkt. Schreibe die Szenenerzählung vor dem endgültigen Timing.
Erstelle storyboard.json mit references/storyboard-schema.md. Füge für jede Szene den genauen UI-Zustand, die Herkunft der Komponente/Quelle, Aktionen, Erzählung, Behauptungen und die Übergangsabsicht ein.
4. Das Remotion-System aufbauen
Erstelle ein wiederverwendbares visuelles System für Produkt-Tokens, Typografie, sichere Bereiche, Browser-/Geräte-Frames, Cursor, Hervorhebungen, Schreibmaschinentext, Kamerabewegungen und Übergänge. Verwende useCurrentFrame() mit interpolate() oder begründeten spring()-Aufrufen; niemals CSS-Animationen oder -Übergänge.
Bevorzuge gestaltete Bewegungen: Kamerafokus, maskierte Enthüllungen, gemeinsame Achsenbewegungen, geschmackvolle Überblendungen, Objektkontinuität und zeitliche Staffelung. Vermeide zufällige Bewegungen, generische Kartenraster, winzige UI, gleichzeitige konkurrierende Blickpunkte.
5. Erzählung generieren und synchronisieren
Generiere eine Audiodatei pro Szene. Behalte das Transkript als Quelle der Wahrheit. Miss die tatsächliche Audiodauer und schreibe voiceover-manifest.json; leite die Szenendauer aus Audio plus Einleitung und Atempause ab. Starte die Erzählung, nachdem sich das Bild etabliert hat, und lege sichtbare Aktionen auf den genauen Satz, der sie beschreibt.
Dehne Audio nicht, um es an feste Szenen anzupassen. Generiere neu oder passe das Timing an, wenn die Auslieferung und die visuellen Elemente abweichen. Füge Untertitel aus dem bekannten Transkript hinzu; verwende STT nur, wenn sich das gesprochene Ergebnis genug unterscheidet, um Wort-für-Wort-Zeitstempel zu benötigen.
Führe node <skill-dir>/scripts/validate-genvid.mjs <storyboard> <manifest> [project-root] vor dem Rendern aus.
6. Rendern und überprüfen
Rendere repräsentative Standbilder nahe dem Einstieg, Mittelpunkt, der Schlüsselinteraktion und dem Ausgang jeder Szene. Überprüfe sie in normaler Betrachtungsgröße. Behebe Beschneidungen, unleserlichen Text, versehentliche Überlappungen, Cursor-Versatz, ungetreue Benutzeroberfläche, Leerlaufzeiten, abrupte Schnitte und Narrationsfehler.
Rendere das endgültige MP4 mit H.264, BT.709 und hochwertigem AAC-Audio, sofern das Zielformat nichts anderes erfordert. Sieh dir das gesamte Ergebnis mit Ton an. Bestätige Laufzeit, Abmessungen, Codecs, Audio-Präsenz, endgültigen CTA und Pfade der Ausgabedateien.
Abschlussstandard
Beende nur, wenn das MP4 existiert und über die gesamte Zeitleiste hinweg angesehen oder stichprobenartig geprüft wurde. Berichte den gerenderten Pfad, Abmessungen, FPS, Dauer, TTS-Anbieter/Modell/Stimme, Quelle der Produktvisuals, überprüfte Behauptungen, durchgeführte Tests und alle absichtlichen Replika-/Aufnahme-Fallbacks.