Was macht Launch-Video?
Verwandle ein echtes Produkt in eine klare visuelle Geschichte: Was schmerzt, was sich ändert, wie es funktioniert und was als Nächstes zu tun ist. Nutze HyperFrames als Engine. Behalte das ausgewählte Modell des Benutzers als Manager bei. Ersetze nicht die Engine und erstelle keinen Video-Editor, keine Vorlagenbibliothek und kein Animationsframework.
1. Briefing-Grundlage schaffen
Lies zuerst das vom Benutzer bereitgestellte Briefing, Produkt, Assets und bestehende Projekt. Setze vorhandene Arbeit fort. Frage nur nach fehlenden Fakten, die das Video ändern würden; wiederhole keine bereits beantworteten Fragen. Ein Produktname allein ist kein ausreichender Beleg für Feature-Behauptungen. Bei spärlichen Eingaben kläre die Zielgruppe, den nützlichen Versprechen und die abschließende Aktion, bevor du das Storyboard schreibst.
Für eine bereitgestellte URL: Überprüfe das tatsächliche Produkt und die offiziellen Markenquellen. Verwende HyperFrames-Capture, wo angemessen; befolge die festgelegten Capture-Fehlerregeln in upstream.md. Erfinde niemals eine Ersatzseite, wenn das Capture fehlschlägt. Für ein „Zeige-es-wie-es-ist“-Video verwende den tatsächlichen Bildschirm als Grundlage. Behalte den exakten bereitgestellten Text bei, es sei denn, eine Bearbeitung ist autorisiert. Halte Behauptungen, Quellen, Asset-Rechte und alle Annahmen in einer kurzen BRIEF.md im Videoprojekt fest. Nimm niemals privates Material ohne Autorisierung in eine öffentliche Demo auf.
Verwende die Farben, Typografie, Dichte und tatsächliche UI des Produkts. Wähle eine spezifische visuelle Richtung mit sinnvoller Bewegung, lesbarer Typografie und bewusstem Tempo. Lies die vorausgehenden kreativen und Bewegungsreferenzen selektiv. Die Referenzstudie veranschaulicht Techniken, keinen verbindlichen Hausstil. Ein fiktives Beispiel muss explizit gekennzeichnet werden; verwandle es nicht in ein implizites echtes Kundenresultat.
2. Projekt vorbereiten
Lies upstream.md und überprüfe die gepinnte Quelle und CLI, bevor du dich darauf verlässt. Verwende den vorausgehenden HTML-Kompositionsvertrag, die Diagnostik und das Rendering. Lies nur die benötigten Domain-Referenzen; kopiere nicht den gesamten Quellbaum in das Auslieferungsobjekt oder aktualisiere stillschweigend auf die neueste Version.
Erstelle ein dediziertes Videoprojekt. Definiere project.json mit project-format.md. Stimme Ausgabemaße, Bildrate, Dauer und Audio-Auswahl im Storyboard ab. Für X überprüfe die aktuellen offiziellen Upload-Anforderungen, bevor du den Export auswählst. Standardmäßig ein kurzer, für stummgeschaltete Geräte optimierter Film; kaufe keine Medien und rufe keinen kostenpflichtigen Sprachdienst ohne Autorisierung auf. Fehlende Assets erfordern einen lokalen, lizenzierten Ersatz, der mit dem Briefing übereinstimmt, oder eine konkrete Frage, niemals einen defekten Platzhalter.
3. Designen, zeigen und Genehmigung einholen
Schreibe ein schlankes Skript: eine klare Idee pro Szene, echte Produktbelege, einen nützlichen Mehrwert. Erstelle für jede Szene einen vollständigen, statischen, gestalteten HTML-Frame mit dem tatsächlichen vorgeschlagenen Text, Layout, Palette und Assets. Textbeschreibungen und Wireframe-Boxen allein sind nicht das Überprüfungsartefakt. Behalte ein durchgehendes Produktbeispiel im Film bei. Zeige wichtige UI in lesbarer Größe und lasse Zeit, jede Aktion zu verstehen.
Jeder Frame muss ein eigenständiger, statischer HTML-Code mit Inline-CSS sein. Verwende lokale, deklarierte Bild-/Schrift-Assets; siehe das Format-Referenz. Überprüfe die Frames in voller Ausgabegröße und in Feed-Skalierung. Füge die exakte Überschrift, optionale Erzählung, Dauer und beabsichtigte Bewegung in project.json ein und führe dann Folgendes aus:
python3 <SKILL_DIR>/scripts/launch_video.py storyboard <PROJECT_DIR>
Öffne das resultierende storyboard.html für den Benutzer. Überprüfe jeden Frame selbst zuerst. Bitte um Genehmigung der angezeigten Version oder szenenspezifischer Änderungen. Warte auf explizite Benutzergenehmigung vor der vollständigen Animation oder dem Rendering. Stille, ein generisches früheres „Ja“, die Akzeptanz der Bauidee und der automatische Modus genehmigen kein ungesehenes Storyboard. Ein neutraler technischer Render-Test ist vor dieser Sperre erlaubt.
Erst nachdem der Benutzer die angezeigte Version genehmigt hat, zeichne seine tatsächliche Entscheidung auf:
python3 <SKILL_DIR>/scripts/launch_video.py record-approval <PROJECT_DIR> \
--version <ANGEZEIGTE_SHA256> --approver <BENUTZERNAME> --decision '<TATSÄCHLICHER_GENEHMIGUNGSTEXT>'
python3 <SKILL_DIR>/scripts/launch_video.py check-approval <PROJECT_DIR>
Die Quittung bindet das Manifest, die Frame-Bytes, Assets und das generierte Storyboard. Sie zeichnet eine menschliche Entscheidung auf; sie authentifiziert nicht den Sprecher oder interpretiert, ob willkürlicher Text eine Genehmigung bedeutet. Fälsche niemals eine Quittung. Halte Genehmigungsaufzeichnungen standardmäßig privat.
4. Genehmigtes Storyboard animieren
Verwende die gepinnten HyperFrames-Animationregeln und -Blaupausen. Verwende die genehmigten, gestalteten Frames als Kompositionsbasis. Jede Szene sollte eine tatsächliche Aktion und ein Ergebnis zeigen; Bewegung muss die Geschichte unterstützen. Verwende suchsichere Zeitachsen. Lese die relevante vorausgehende Regel, bevor du eine Technik implementierst. Stimme Position, Skalierung, Richtung und Deckkraft über einen kontinuierlichen Übergang ab. Vermeide Bewegung, die das Produkt verdeckt oder schnell aufblitzt.
Erstelle index.html und eine Unterkomposition pro genehmigter Szene, wie im Format-Referenz angegeben. Halte IDs/Reihenfolge, exakten Text, Timing, Maße und Asset-Identität dem genehmigten Board treu. Der Helfer überprüft Struktur, Text und Timing; überprüfe visuelle Elemente und Assets selbst. Er kann semantische Treue nicht allein aus der Quelle nachweisen. Bearbeite keine genehmigten Frames, um Abweichungen zu verbergen.
Eine angeforderte Änderung von Geschichte, Text, Asset, Layout, Dauer oder Audio erfordert ein überarbeitetes Storyboard und erneute Genehmigung. Behalte die vorherige Version bei. Bewegungsreparaturen, die bereits genehmigte Absichten umsetzen, können fortgesetzt werden, dann führe die betroffenen Prüfungen erneut aus. Wenn du mit Agenten arbeitest, gib jedem eine genaue Szene und nicht überlappende Dateibesitzer; der Manager besitzt Komposition und QA.
5. Inspizieren, rendern und ausliefern
Verwende die gepinnte CLI aus dem Projektverzeichnis für lint, check, keyframes . --json und snapshot --at <szenenmittelpunkte-und-übergangsgrenzen>. Überprüfe jede Szene, den Anfang/das Ende und beide Seiten jedes Schnitts. Öffne preview --background und sieh die vollständige Bewegung bei normaler Geschwindigkeit an. Überprüfe Lesbarkeit, Timing, Überlappungen, Clipping, Asset-Ladung, Übergangskontinuität und Verständnis bei stummgeschaltetem Ton. Für Audio überprüfe auch Rechte, Synchronisation, Clipping und das Ende. Bestehende statische Prüfungen beweisen keine visuelle Qualität.
Nach Genehmigung und visueller Vorab-QA rendere über den Helfer:
python3 <SKILL_DIR>/scripts/launch_video.py render <PROJECT_DIR> --output output/video.mp4
Dies ruft HyperFrames 0.8.37 und ffprobe auf, überprüft den Export auf die genehmigten Maße/Bildrate/Dauer/Audio und schreibt eine .qa.json-Quittung. Ihr visueller QA-Status bleibt ausstehend: Überprüfe die tatsächliche MP4, extrahiere repräsentative Frames und sieh die vollständige Wiedergabe an, bevor du auslieferst. Berichte Beweise getrennt von Beurteilungen. Markiere das Ergebnis nicht als fertig, nur weil die Kodierung erfolgreich war.
Bei Fehlschlag lies den Fehler, behebe seine konkrete Ursache und wiederhole die betroffene Prüfung. Behalte vorhandene Videos bei; wähle nach Überprüfung eines teilweise fehlgeschlagenen Renderings einen neuen Ausgabepfad. Wechsle niemals die Engine, verwende keine alten Ausgaben als neues Ergebnis und verstecke keine fehlende Fähigkeit. Wenn blockiert, gib an, was übrig bleibt, und liefere die bereits überprüfbare Arbeit aus.
Liefere die MP4, das gestaltete Storyboard, Szenen-IDs für Überarbeitungen, Maße/Dauer/Audio, reproduzierbare Befehle und ehrliche QA-Notizen aus. Veröffentliche nur auf Anfrage. Versprich nicht „viral“, einmalige Qualität oder ungemessene Zeit/Token-Ersparnisse.