ConardLi/garden-skills – Bewegungs-Showreel

Bewegungs-Showreel

Eine Idee in ein Video verwandeln, das sich auf Grafiken, Text oder UI-Animationen konzentriert – mit Auslieferung einer MP4 und des vollständig reproduzierbaren Quellcodes. Die Animationsdichte und kreative Freiheit von Kurzfilmen bleibt erhalten, gleichzeitig werden Kapitel von bis zu 20 Minuten Länge unterstützt.

Prinzip: Die Seite stellt eine deterministische render(t)-Funktion bereit, Skripte machen Bildschirmaufnahmen pro Frame, und ffmpeg setzt daraus ein MP4 zusammen. Bild, Sprache, Musik und Soundeffekte teilen sich eine timeline.js. Ohne Sprachausgabe wird der Bildablauf nach Inhalt und Musikbeat organisiert; mit Sprachausgabe dient die reale Sprachzeit als Anker für die Musik- und Soundeffekt-Planung.

Wo gute Filme herkommen: Änderungsdichte, Bewegungsqualität, ein einprägsamer Moment, die Beziehung zwischen Bild und Ton – diese vier Faktoren bestimmen üblicherweise den Eindruck. Aber wie viel und welche Art von Bewegung gewählt wird, hängt von Stil und Inhalt ab, nicht jeder Film braucht Multi-Kamera-Schwenks, Federn und eine Vollausstattung an Soundeffekten. Es gibt weltweit nur wenige Grundregeln (siehe „Grundregeln“), der Rest sind Startpunkte für das Modell, keine Obergrenzen.

Video-Gefühl: Bei erklärenden Filmen, Produktdemos und narrativen Filmen sollen sich Objekte und ihre Beziehungen mit dem Inhalt weiterentwickeln, mit räumlicher Kontinuität zwischen den Einstellungen. Man darf den Sprechertext nicht in statische Titelbildkarten aufteilen, die dann mit Einblendungen, Skalierung und Hintergrundpartikeln verpackt werden. Entwickle das Storyboard zuerst mit der Frage: „Was muss der Zuschauer verstehen? Welche Veränderung findet statt? Wie hängt diese Einstellung mit der vorherigen zusammen?“ – und wähle dann die Animationen. Logos, dynamische Typografie, Loops und bewusst statische Stile folgen weiterhin ihrer eigenen Grammatik; Qualität wird nicht an durchgehender Bewegung oder erzwungenen 60 fps gemessen. Detaillierte Methoden finden sich unter references/craft.md im Abschnitt „Kontinuierliches Erzählen“.

---

Anwendungsbereich

Benutzer möchte	Dieses Skill nutzen?
Produktwerbefilm, Animations-Portfolio, UI-Animation, dynamische Typografie / Beat-Sync, Logo-Inszenierung, Intro, Loop-Animation	✅
Greenscreen-Person aus Video-Modell + Code-Szene, große Schrift, Effekte	✅ Person wird vom Benutzer bereitgestellt (references/formats.md Kategorie H)
Vom Benutzer bereitgestelltes Skript oder Aufnahme, MP4 mit Erklärung exportieren	✅ Sprachgesteuerter Modus; TTS muss das vom Benutzer bereitgestellte Original-Manuskript verwenden
Klickgesteuerte Präsentation, Live-Vortrag, interaktive Web-Demo oder Artikel in Sprechertext umwandeln	Nutze web-video-presentation
Webseite, Landingpage, interaktiver Prototyp, statische visuelle Entwürfe	❌ Nutze web-design-engineer
Realistische Personendarstellung, echte Aufnahme-Optik, Schnitt von vorhandenem Material, direkte Bildgenerierung mit Video-Modell	❌

Länge: Maximal 20 Minuten (1200 Sekunden), wobei die vom Benutzer bestätigte Länge maßgeblich ist. Kurzfilme sind weiterhin 5–60 Sekunden lang; ein langer Film wird nicht zu einem 20-minütigen, hochdichten Beat-Sync-Dauerlauf. Ab 2 Minuten Länge ist references/long-form.md zu lesen; Planung, Produktion und Review erfolgen kapitelweise. Bei Konflikten zwischen der angegebenen Länge und der tatsächlichen Länge des Skripts oder des Inhalts stoppen und die Anpassung mit dem Benutzer abstimmen; eigenmächtiges Kürzen, Beschleunigen der Sprache oder Ändern der Filmlänge ist nicht erlaubt.

Stärken und typische Fallstricke von Opus

• Stärken: In einer Datei können Canvas, SVG/DOM, WebGL, Three.js gemischt werden, sogar mit Wechsel des Mediums pro Abschnitt; Bewegungen können präzise mit Formeln berechnet werden (Closed-Form-Federn, Beat-Raster, Sub-Frame-Bewegungsunschärfe); Sound und Bild lesen denselben Zeitplan; lange autonomes „Rendern von Standbildern → Betrachten → Ändern“ ist möglich; das ästhetische Urteilsvermögen ist stark, und eine Anweisung wie „Gib dein Bestes“ kann zu erstaunlichen Ergebnissen führen.
• Typische Fallstricke: Ohne Einschränkungen neigt das Bild zu dunklen Hintergründen, zentrierten großen Schriften, Einblendungen aller Elemente gleichzeitig, Lila-Blau-Verläufen mit Leuchteffekten, statischer Kamera; die Musik tendiert zu a-Moll-Vier-Akkorden, Impact + Crash auf jedem Schlag, Glockenspiel am Ende, sodass mehrere Filme nach demselben Lied klingen. Deshalb zuerst Benchmarks finden (für Bild und Ton), Stilrichtungen und Verbotsliste klar definieren. Aber die Einschränkungen dürfen nicht in Stein gemeißelt sein: Die Stilbibliothek und die Handwerksbibliothek dieses Skills sind Ausgangspunkte; wenn das Thema es erfordert, können sie jederzeit angepasst, gemischt oder benutzerdefiniert werden.
• Schwächen: Realistische Personen, komplexe Hände/Stoffe/Haare, Dinge, die echte physikalische Präzision erfordern, fotorealistische Produkte (außer der Benutzer stellt Modelle oder Bilder bereit). In diesen Fällen wird ein stilisierter Ansatz gewählt oder die Arbeitsteilung Greenscreen-Person + Code-Szene verwendet.

---

Workflow

0  Umgebungsprüfung (einmalig)
1  Anforderungserfassung ──── Fehlende Pflichtfelder ergänzen, Anforderungen zusammenfassen → 🛑 Auf Benutzerbestätigung warten
2  brief.md ──── Benchmark → Verwendungszweck + Stil → Reel Read → Storyboard + Soundplan
3  Stil-Frames ──── Stil festgelegt: 3 Frames; Stil nicht festgelegt: 3 Richtungen mit je 1 Frame → 🛑 Auf Benutzerbestätigung warten
4  Produktion ──── Bei Sprachausgabe zuerst echte Audiodatei und Zeitstempel bereitstellen → timeline → Einstellung für Einstellung → Proxy → Final Cut
5  Musik und Mischung ──── BGM, Soundeffekte unabhängig voneinander auswählen; bei Sprachausgabe hat die Stimme Priorität
6  Abnahme ──── Technische Prüfung (Programm-gesteuert, muss vollständig bestanden werden) + Review (Bildmaterial analysieren, Probleme auflisten, dem Benutzer zur Endkontrolle vorlegen)
7  Auslieferung

Arbeitsverzeichnis: Im aktuellen Benutzerverzeichnis wird <slug>/ erstellt, alle Dateien werden darin abgelegt: brief.md, index.html, motion.js, timeline.js, score.mjs oder score.tone.js (je nach --audio-Auswahl des Scaffolds), build.sh, fonts/, assets/, audio/, qa/, out/.

Schritt 0: Umgebung

Beim ersten Mal sh <skill>/scripts/setup.sh ausführen: Es installiert Playwright und Chromium und führt dann check-env.mjs aus. Benötigt werden Node 18+ und ffmpeg; wenn etwas fehlt, den Benutzer darauf hinweisen, wie es installiert werden kann, aber keine Systemsoftware für den Benutzer installieren. Das Tool enthält Tests: cd <skill>/scripts && npm test.

Schritt 1: Anforderungserfassung (Stoppen und auf Benutzer warten)

Gezielt nach fehlenden Angaben fragen, bereits gegebene nicht wiederholen. Die folgenden Informationen müssen eindeutig sein und dürfen nicht durch feste Standardwerte ersetzt werden:

Pflichtinformation	Was muss klar sein
Kernerzählung, Produktionsinhalt	Was soll gezeigt werden, welche Inhalte müssen vorkommen
Länge	Konkrete Sekunden oder Minuten; ob kleine Abweichungen erlaubt sind; darf 1200 Sekunden nicht überschreiten
Quer- oder Hochformat	Je nach Auswahl die tatsächliche Größe bestimmen; auch die Möglichkeit für andere Formate wie 1:1 offen lassen. Auflösung und Bildrate können vorgeschlagen und in der Bestätigungszusammenfassung festgehalten werden
BGM-Quelle	KI-Synthese / Benutzerbereitstellung; Benutzer kann auch deaktivieren
Soundeffekt-Quelle	KI-Synthese / Benutzerbereitstellung; getrennt von BGM wählbar, kann auch deaktiviert werden
Sprachausgabe	Keine / KI-TTS / Vom Benutzer bereitgestellte Aufnahme

Bedingte Pflicht: Bei Wahl von TTS muss der Benutzer das Skript bereitstellen; es darf nicht selbst geschrieben, ergänzt, geändert und dann eigenmächtig synthetisiert werden. Gleichzeitig den TTS-Dienst und die erforderliche API-Konfiguration klären (vorhandene Konfiguration wiederverwenden, Zugangsdaten über Umgebungsvariablen, nicht in brief schreiben). Unterstützt werden Gemini, MiniMax und benutzerdefinierte Adapter; bei Bedarf references/narration.md lesen. Bei Wahl der Benutzeraufnahme sind die Audiodatei oder eine zugängliche Adresse erforderlich; bei Benutzer-BGM/Soundeffekten die entsprechenden Dateien. Sprache, Stimmeigenschaften usw., die aus dem Skript oder der Konfiguration ersichtlich sind, in die Zusammenfassung aufnehmen, sonst erfragen.

Optionale Informationen: Relevantes Material, Zielgruppe und Veröffentlichungsplattform, Themenstil. Wenn Zielgruppe und Plattform nicht angegeben sind, basierend auf dem Inhalt ableiten und in der Zusammenfassung erläutern. Wenn der Stil nicht angegeben ist, wird er in der Stil-Frame-Phase in drei Richtungen angeboten.

Wie mit Material umgehen: Wenn der Benutzer bereits konkrete Inhalte gegeben und die KI-Generierung autorisiert hat, auf dieser Grundlage produzieren; wenn der Benutzer nicht genügend konkrete Inhalte gegeben hat, nach den erforderlichen Materialien fragen, auch Online-Recherche zum Thema durchführen und Quellen angeben. Wenn ein Skript für die Sprachausgabe vorhanden ist, zuerst daraus Informationen extrahieren, den Benutzer keine sich wiederholenden Angaben machen lassen. Die KI kann Illustrationen, Szenen, abstrakte Grafiken und als skizzenhaft gekennzeichnete Inhalte erstellen; echte Produktfunktionen, Zahlen und Markenmaterial halten sich dennoch an die „Grundregeln“: keine erfundenen Informationen als echte Inhalte ausgeben. Anforderungen an Markenlogos oder echte Produkt-Screenshots finden sich in references/stack.md.

• Wenn der Benutzer ein Referenzvideo bereitstellt: Zuerst inspect.mjs sheet <ref> --cells 30 laufen lassen, um einen Überblick zu bekommen, inspect.mjs grid <ref> --strips zur Messung der Schnittpunkte und ihres Platzes im Beat-Raster (BPM-Kandidaten, Anzahl der Schritte pro Segment, kontinuierliche Frames jedes Übergangs), inspect.mjs heat <ref> zur Analyse, wo sich in jedem Segment etwas bewegt und wie groß die Fläche ist. Die gemessenen Werte in die Benchmark-Spalte des brief.md eintragen. Nur die Struktur und Techniken lernen, kein Material kopieren.
• Wenn der Benutzer ein Musikstück bereitstellt: Ohne Sprachausgabe zuerst audio.mjs beats <track> --out <slug>/audio/beats.json; mit Sprachausgabe unterordnen sich die Musik-Beat-Punkte dem Erzählrhythmus.
• Bei unsicheren Produkt-, Marken- oder Fachbegriffen, die im Bild erscheinen sollen, vorher recherchieren.

Nach der Ergänzung die Zusammenfassung (Thema, Länge, Seitenverhältnis, BGM/Soundeffekt-Quellen, Sprachmodus und Materialstatus) stoppen und auf Benutzerbestätigung warten, bevor das Briefing geschrieben wird. Auch wenn die erste Anfrage vollständige Informationen enthält, zuerst eine Zusammenfassung zur Bestätigung senden. Sagt der Benutzer „Gib dein Bestes“, „Überrasche mich“ oder „Mach, was du willst“, autorisiert dies nur kreative Entscheidungen, bedeutet aber nicht, dass Pflichtangaben weggelassen oder die Bestätigung übersprungen werden darf; nur wenn der Benutzer ausdrücklich sagt, dass eine bestimmte Bestätigung übersprungen werden kann, darf fortgefahren werden, wobei die Autorisierung zu dokumentieren ist.

Freier Modus: Die kreative Autonomie bleibt erhalten, nur die Grundregeln und die technische Pipeline gelten; Stil, Struktur und Techniken können selbstständig gewählt werden, auch die Stilbibliothek kann vollständig ignoriert werden. Trotzdem wird ein brief.md geschrieben und es werden drei Richtungen angeboten, wobei die obigen Regeln für zwei Bestätigungen gelten; Ausnahmen nur, wenn der Benutzer eine Bestätigung ausdrücklich erlässt.

Schritt 2: brief.md

Zuerst Benchmarks finden: Vor dem Schreiben für diesen Film (dieses Thema + diesen Zweck) 1–2 Benchmark-Werke auswählen – Filmtitel, Werbung, Spiele, Animationsarbeiten, Designrichtungen. Im brief.md festhalten: „Was lernen“ (Komposition, Rhythmus, Bildsprache, Farbharmonie, Musikstruktur) und „Was nicht lernen“ (Figuren, spezifische Kameraeinstellungen, Melodien, Logos, Schriftartdateien). Benchmarks heben die Qualität mehr als jede Regel.

Dann drei Kandidaten-Strukturen überlegen: Z. B. eine Reise, ein Vorher-Nachher-Vergleich, ein Countdown, eine Verwandlung, eine ungeschnittene lange Einstellung. Jede in 2–3 Zeilen beschreiben, eine auswählen und die Begründung angeben. Der erste Gedanke ist oft das Klischee dieses Stils.

Verwendungszweck und Stil getrennt auswählen:

• Verwendungszweck (was wird gezeigt, nach welcher Struktur wird erzählt) siehe references/formats.md, nur den entsprechenden Abschnitt lesen.
• Stil (wie sieht es aus, wie bewegt es sich, wie klingt es) zuerst references/styles/INDEX.md lesen, dann nur die 1–2 ausgewählten Stil-Dateien lesen. Der Stil kann direkt verwendet, angepasst (eine oder zwei Regeln ersetzen), gemischt werden (ein Hauptstil, ein Neben- oder Wechsel des Mediums pro Abschnitt) oder nach styles/_template.md benutzerdefiniert sein. Die Stilregeln bleiben bestehen; Geschichte, Kameraeinstellungen und Struktur stammen vom Thema des Benutzers und werden nicht aus anderen Filmen übernommen. Jede Stil-Datei hat einen Abschnitt „Erkennungsmerkmale“ und „Die klischeehafteste Version“. Je nach Thema 2–3 Merkmale auswählen (mindestens eines nicht aus der Klischee-Liste) und im brief.md festhalten, welche Klischees verworfen wurden oder warum sie beibehalten wurden. Wenn der Benutzer einen Stil wählt, soll er diesen auf den ersten Blick erkennen; zwei bis drei Merkmale reichen.
• Bei Bedarf references/craft.md (Handwerksbibliothek) konsultieren.

Das brief.md nach der Vorlage references/brief-template.md schreiben, Kernpunkte:

Reel Read:
  format: [Verwendungszweck, Typ aus formats.md]
  benchmark: [Benchmark-Werk · Was lernen · Was nicht lernen]
  structure: [Drei Kandidaten-Strukturen → welche gewählt, warum]
  style: [Stil aus styles/ (mit Anpassungspunkten) oder Mischlösung oder benutzerdefinierte Regeln]
  signals: [Welche 2–3 Erkennungsmerkmale gewählt, warum; welche Klischees verworfen]
  takeaway: [Ein Satz oder ein Bild, das der Zuschauer behalten soll]
  hook: [Was passiert in der ersten Sekunde]
  signature: [Merkmal: in welcher Sekunde, welche Technik]
  palette / type / motion / camera / texture: [Spezifische Werte gemäß gewähltem Stil]
  sound: [Stumm / Synthese (Sound-Benchmark, Groove, Harmonie, Instrumentierung, Kurve, siehe sound.md Abschnitt 2) / Benutzertrack (BPM, Drop)]
  audio-sources: [BGM und Soundeffekte jeweils KI / Benutzer / Aus]
  narration: [Keine / Benutzer-Skript per TTS / Benutzeraufnahme; bei Sprachausgabe Pfad zur Satz-Zeitachse, Stimme priorisiert]
  forbidden: [Verbotsliste für diesen Film]

Anschließend das Storyboard schreiben: Ohne Sprachausgabe Beat-Raster + Storyboard beibehalten. Mit Sprachausgabe die Satzsegmente mit Kameraeinstellungen und Ereignissen verknüpfen, schreiben: Einstellung / Satz-ID | Was erklärt wird | Anfangs-/Endzustand des Objekts | Vererbte Objekte und Raum | Schlüsselereignisse und ihre Zeitbasis | Bild und Ton. Eine Einstellung kann mehrere Sätze abdecken, ein Satz kann mehrere Aktionen enthalten; der Sprechertext wird nicht als Schnittbefehl behandelt, und es wird nicht gefordert, jeden Satz vollständig auf dem Bildschirm darzustellen. Die tatsächlichen Intervalle werden nach der Audio-Vorbereitung zurückgeschrieben; die geschätzte Zeit basierend auf der Wortzahl dient nicht als endgültige Ausrichtungsgrundlage. Bei langen Filmen zusätzlich eine Kapiteltabelle, die Kapitellängen und kapitelübergreifende Konsistenzregeln schreiben.

Wenn der Benutzer nur „Gib dein Bestes“ gesagt hat, muss dies in die oben genannten konkreten Einschränkungen übersetzt werden, sonst ist das Ergebnis Zufall.

Schritt 3: Stil-Frames (Zweiter Stopp für Benutzerbestätigung)

Projekt erstellen: sh <skill>/scripts/scaffold.sh <slug> [--audio synth|tone|layer|file|none] (synth = Stufe 1-Synthese; kopiert nur die ausgewählte Score-Datei; file verwendet die bereits vorbereitete finale Tonspur). Die Standardwerte des Scaffold-Engines dienen nur der technischen Initialisierung und ersetzen nicht die Anforderungserfassung. Der Starter dient nur dazu, zu überprüfen, ob die Pipeline funktioniert; Bilder und Texte müssen ersetzt werden.

A. Benutzer hat den Stil bereits festgelegt (oder ein klares Referenzmaterial gegeben): Die Sekundenangaben in den folgenden Befehlen sind nur Beispiele; tatsächlich werden die effektiven Zeiten des Openings, des Merkmals und des Endes des Films verwendet; Kurz- und Langfilme sollten nicht blind 14,5 Sekunden übernehmen.

1. Mit echtem Code den Hook-Frame, den Merkmal-Frame und den End-Frame erstellen, mit endgültigen Farben, Schriftarten und Texten.
2. render.mjs <slug> --still 0.6,7.2,14.5 --sheet, zuerst selbst ansehen, offensichtliche Probleme korrigieren, dann dem Benutzer vorlegen. Abhängig von der Bewegungsrichtung zusätzlich ein kontinuierliches Proxy-Video gemäß den Anforderungen dieses Abschnitts ausgeben (--start --duration).
3. Eine Zusammenfassung des Reel Read, eine Storyboard-Übersicht und die Stil-Frames an den Benutzer senden und fragen: „Ist die Richtung richtig?“. Bei TTS-Projekten gleichzeitig die Segmentierung des Benutzer-Skripts und ein kurzes Hörbeispiel der Stimme (nur mit dem vom Benutzer bereitgestellten Text) beifügen, um die klangliche Richtung gemeinsam zu bestätigen; es wird kein zusätzlicher obligatorischer Stopp eingeführt.

B. Benutzer hat keinen Stil festgelegt (einschließlich freier Modus): 3 deutlich unterschiedliche Richtungen anbieten, Regeln siehe styles/INDEX.md:

• A passt zum Thema / zur Marke, B verwendet eine andere Bildsprache (aus einer anderen Gruppe), C ist mutig (benutzerdefiniert, gemischt oder strukturell sehr gewagt, mindestens eine Richtung ist nicht aus der Bibliothek).
• Für jede Richtung einen Mini-Reel Read schreiben (Stil, Benchmark, Merkmal, Musikrichtung, 3–5 Zeilen) und mit echtem Code einen repräsentativen Keyframe rendern. Die Seiten der drei Richtungen werden im selben Projekt abgelegt und mit ?dir=a|b|c umgeschaltet. B, C dienen nur diesem einen Keyframe, müssen nicht als vollständiger Film abspielbar sein.
• render.mjs <slug> --directions a,b,c --at 14.5,2,0 rendert alle drei auf einmal und erstellt ein beschriftetes qa/directions.png, das an den Benutzer gesendet wird, mit der Frage: „Welche Richtung, oder wie mischen?“. Bei TTS-Projekten gleichzeitig die Segmentierung des Benutzer-Skripts und ein kurzes Hörbeispiel der Stimme beifügen, um die klangliche Richtung gemeinsam zu bestätigen.

In beiden Fällen tatsächlich auf die Antwort des Benutzers warten, bevor mit der Produktion fortgefahren wird. Wenn der Benutzer im Voraus klar gesagt hat, dass eine Bestätigung nicht erforderlich ist, selbst eine auswählen, die Begründung angeben, selbst prüfen und dann fortfahren; bei der Auslieferung die nicht gewählten Richtungen ebenfalls dem Benutzer geben (bei B qa/directions.png beifügen, bei A pro Richtung einen Satz zu den anderen beiden möglichen Richtungen schreiben), damit der Benutzer später noch wechseln kann.

Bei Richtungen, die von kontinuierlicher Bewegung abhängen, zusätzlich zu den Standbildern ein 6–10 Sekunden langes repräsentatives Bewegungsmuster anfertigen (bei Filmen unter 6 Sekunden den gesamten Film), das mindestens eine Zustandsänderung und deren Vorbereitung und Nachwirkung abdeckt; vorher selbst kontinuierliche Frames auf Sprünge überprüfen. Das Muster wird zusammen mit den Stil-Frames bestätigt; es wird kein dritter obligatorischer Stopp eingeführt. Wenn die Sprachausgabe noch nicht generiert wurde, klar als Bewegungsvorschau kennzeichnen und nicht behaupten, sie sei bereits präzise mit der Sprache synchronisiert.

Schritt 4: Produktion

Vor der Produktion references/stack.md lesen (Seitenvertrag, Deterministisch, Fallstricke der verschiedenen Technologien). Wenn vorgefertigte Lösungen benötigt werden, references/recipes.md konsultieren.

Bei Sprachausgabe zuerst die Sprachzeitachse festlegen: Gemäß references/narration.md das Benutzer-Skript synthetisieren oder die Benutzeraufnahme importieren, die tatsächliche Länge und die Satz-Zeitstempel ermitteln, dann das Bildmaterial planen. Bei Benutzeraufnahmen müssen Text und Zeiten über verfügbare Transkriptionstools oder vom Benutzer bereitgestellte SRT/JSON-Dateien ermittelt werden; ohne zuverlässige Zeitstempel darf keine fertige Satz-für-Satz-Synchronisation behauptet werden. Bei Längenkonflikten zuerst den Benutzer bestätigen lassen, nicht stillschweigend auffüllen, beschneiden oder die Geschwindigkeit ändern. Die tatsächlichen Intervalle in die Einstellungstabelle eintragen, dabei Sprachpausen und Betonungen beibehalten, nicht gewaltsam an Musiktakte anpassen. Ab 2 Minuten nach references/long-form.md kapitelweise produzieren, Kapitel-Caches beibehalten.

Satzsegmente geben nur den Synchronisationsbereich vor; Kameraeinstellungen und Objektbewegungen können kontinuierlich über Satzgrenzen hinweggehen. Wenn für wichtige Änderungen eine wortgenaue Synchronisation erforderlich ist, echte Wortzeiten oder manuell annotierte Ankerpunkte verwenden und über narration.js abfragen, sodass Bild und Soundeffekte auf dasselbe Ereignis verweisen; bei nur Satz-Zeiten die Synchronisation auf Satzebene belassen, keine erfundenen Wort-für-Wort-Zeitpunkte verwenden. Während der Produktion preview.mjs für die Vorschau mit Ton (Scrubben und Frame-für-Frame-Prüfung) verwenden; die Vorschau treibt dasselbe render(t) an, tritt nicht in die formale Rendering-Schleife ein.

1. Alle Zeitpunkte in timeline.js eintragen; Seite und score.mjs importieren von dort. Die Einstellungstabelle in SHOTS eintragen (bei der Abnahme werden die Bewegungen pro Einstellung gemeldet), bewusste Verweilzeiten in HOLDS (z. B. Endtitel [[b(36), DUR]]), atmungsintensive Beats in DROPS; die Abnahmetools lesen diese. Wenn Übergänge auf den Beat fallen sollen, mit revealOn(Beat, Übergangsdauer, Enthüllungspunkt) den Startpunkt rückwärts berechnen, sodass der Frame, auf dem das neue Bild erscheint, auf dem Beat liegt.
2. Einstellung für Einstellung vorgehen. Für jede Einstellung 3 Standbilder rendern (Anfang, Mitte, Ende); zusätzlich kontinuierliche Videos von wichtigen Zustandsänderungen und Einstellungsübergängen ansehen, um zu prüfen, ob Objekte plötzlich zurückgesetzt werden, die Bewegungsgeschwindigkeit abrupt wechselt oder die Kameraeinstellung unterbrochen wird. Gute Standbilder ersetzen keine Bewegungsprüfung; für schnelle Bewegungen inspect.mjs strip verwenden, um kontinuierliche Frames zu betrachten.
3. Deterministischen Test ausführen: render.mjs <slug> --determinism. Nicht bestanden → zuerst korrigieren.
4. Bei Filmlängen von 30 Sekunden oder mehr oder langsamen Renderzeiten zuerst ein Proxy-Video mit niedriger Auflösung erstellen: --size 960x540 --out out/proxy.mp4.
5. Finalen Cut erstellen: Zuerst oben in build.sh gemäß Briefing FPS, SIZE, AUDIO, LOOP setzen, dann sh <slug>/build.sh ausführen. Es erstellt die Musik, führt zuerst den deterministischen Test durch (bei Nichtbestehen kein Video), rendert dann, führt dann die Textrahmen-Prüfung durch (erzeugt nur Review-Material, blockiert den Build nicht), und führt schließlich mit denselben Spezifikationen die technische Prüfung durch (die Länge wird aus timeline.js' DUR entnommen). --subframes, --dpr, --grain als Parameter anhängen, je nach Stilanforderung. Diese Parameter erhöhen den Zeitaufwand um ein Vielfaches; vor dem Rendern die geschätzte Zeit mitteilen.

Für gemischte Tonspuren AUDIO=file AUDIO_FILE=audio/final.wav sh build.sh verwenden; die alten synth/tone/layer/none-Build-Methoden sind weiterhin verfügbar. Bei langen Filmen build-long.mjs für persistente kapitelweise Builds verwenden, siehe references/long-form.md.

Harte Regeln:

• Das Bild wird nur durch t bestimmt: Keine Verwendung von Math.random, Date.now, rAF, Timer, CSS-Animationen; kein Zustand zwischen den Frames.
• Alle Schriftarten und Materialien laden, dann READY = true setzen; Schriftarten im Projekt selbst hosten.
• Das Layout wird von den von stageSize() zurückgegebenen Breiten- und Höhenwerten abgeleitet, nicht fest codiert.

Schritt 5: BGM, Soundeffekte und Mischung

references/sound.md lesen. BGM und Soundeffekte werden jeweils gemäß der bestätigten Quelle erstellt; Kombinationen wie Benutzermusik + KI-Soundeffekte sind erlaubt. Die folgende Tabelle zeigt die Auswahl der KI-Engine; die bestätigten Quellen dürfen nicht durch Engine-Standardwerte überschrieben werden. Die klangliche Richtung (Benchmark, Groove, Harmonie, Instrumentierung, Kurve) wird bereits im Briefing festgelegt:

Stufe	Was wird verwendet	Geeignet für
Stufe 1 · Integrierte Synthese	score.mjs, Synthesizer in Node (Drums, Handtrommeln, Bass, Pad, Pizzicato, Marimba/Metallophon/Kalimba, Orgel, Vocal-Pad, FM, Umgebungsrauschen, Soundeffekte, Sidechain, Hall, Lo-Fi-Bearbeitung), keine Abhängigkeiten	Elektronisch, UI, Chipmusik, Ambient, Lo-Fi, Handgemacht & Spielzeug, die meisten Motion-Filme
Stufe 2 · Tone.js	score.tone.js, Offline-Rendering in einem Headless-Browser mit Tone.js: Sample-Instrumente (audio.mjs samples salamander herunterladen: CC BY Piano), Faltungshall, umfangreichere Synthesizer und Effekte	Stile, die echte Instrumente, Räumlichkeit, filmische Atmosphäre benötigen
Externe Tracks	Vom Benutzer bereitgestellte Musik (eigene, lizenzierte, von KI-Musikdiensten erstellte)	Benutzer hat bereits Musik

• Build: audio.mjs build <slug>/score.mjs oder score.tone.js; beide geben audio/music.wav mit −14 LUFS aus.
• Benutzertrack: Ohne Sprachausgabe zuerst audio.mjs beats ausführen (bei vorhandenem librosa automatisch verwendet), um die Timeline auszurichten, dann in der Score S.load() verwenden, um Soundeffekte zu überlagern. Mit Sprachausgabe die Musik-Beat-Punkte nur als Referenz verwenden, Musik und Soundeffekte an die Sprache anpassen, nicht die bestätigte Sprachzeitachse verschieben.
• Stumm: Überspringen, wenn BGM, Soundeffekte und Sprachausgabe alle deaktiviert sind; das Deaktivieren von nur BGM bedeutet nicht, dass der Film stumm ist.
• Mit Sprachausgabe: Musik reduziert Melodie, dichte Beats und große Dynamik; Soundeffekte nur für informative Aktionen verwenden, Schlüsselwörter und Satzanfänge vermeiden. Separate Spuren beibehalten, mit narration.mjs mix für Ducking während der Sprachpassagen, einheitliche Lautstärke und Spitzenpegel-Begrenzung. Die synchronisierten Bilder anhand der echten Satz-Zeitstempel überprüfen; der Höreindruck muss dennoch vom Benutzer endgeprüft werden.

Nach jedem Build des finalen Mixes audio.mjs check ausführen, um Zahlen und Diagramme zu erhalten; wenn der Host das Abhören unterstützt, zusätzlich abhören; das Bestehen der Zahlenwerte allein bedeutet nicht „Höreindruck bestätigt“. Wenn timeline.js DROPS enthält, misst das Tool zusätzlich die Einbuchtung und den Anstieg vor dem Beat und gibt eine WARNUNG aus, wenn keine Atmung vorhanden ist.

Schritt 6: Abnahme

Technische Prüfung: Programmgesteuert, bei Fehlschlag keine Auslieferung.

node <skill>/scripts/inspect.mjs qa <slug>/out/final.mp4 --out <slug>/qa/final \
  --expect-size 1920x1080 --expect-fps 30 --expect-duration 16 --audio required   # Bei stummen Filmen --audio none; bei Loops --loop hinzufügen

Es prüft: Datei dekodierbar, Abmessungen, Bildrate, Länge, Frame-Anzahl, Tonspur, schwarze Frames, Lautstärke, True Peak sowie Loop-Nähte (falls erforderlich). Bei mindestens einem FAIL ist der Exit-Code 1, der Fehler muss behoben werden. Nicht übergebene Spezifikationen werden als NOT CHECKED aufgeführt; dies gilt nicht als bestandene Abnahme. build.sh übergibt die Spezifikationen automatisch. Das Rendering-Tool selbst verweigert die Veröffentlichung von Dateien mit falscher Frame-Anzahl.

Review: Für menschliche Beurteilung, nicht programmgesteuert. Ansehen: Ausgewählte Frames, Frames in Handy-Größe, eingefrorene Abschnitte (HOLDS deklarierte werden als bewusste Verweilzeiten markiert, der Rest muss auf leere Beats geprüft werden), Schnittpunkte, Bewegungen und Blink-Frames pro Einstellung, markierte Bilder der Textrahmen-Prüfung (qa/text-*.png), Audio-Diagramme. Nach der Checkliste aus references/review.md jede Position notieren und die drei schwerwiegendsten Probleme auflisten; bei Filmen mit Zahlen und Diagrammen den Inhalt und die Zahlenangaben überprüfen. Nach der Korrektur nur die problematische Einstellung erneut rendern, dann den gesamten Film ausgeben; den Prozess in qa/review_log.md dokumentieren. Wenn der Host Sub-Agenten unterstützt, einen weiteren Agenten, der nicht an der Produktion beteiligt war, nur dieses Material prüfen lassen, um Probleme zu finden (Review.md „Unabhängiger Review“).

Bei Sprachausgabe zusätzlich narration.mjs check ausführen, um die Satz-Zeitabdeckung, die Audio-Länge und die bestätigten Spezifikationen zu überprüfen; dann Satz für Satz das Skript, das Bild und die Sprache auf Konsistenz prüfen; automatische Prüfungen ersetzen keinen Höreindruck-Review. Bei langen Filmen kapitelweise reviewen und die Übergänge in Bild, Ton und Zeitachse prüfen.

Das Review-Ergebnis dient dem Benutzer als Referenz, ersetzt nicht das eigene Ansehen des Films durch den Benutzer. Nicht zutreffende Punkte als „nicht zutreffend“ kennzeichnen, z. B. Bild-Ton-Synchronisation bei stummen Filmen; keine Bewertungen erzwingen.

Schritt 7: Auslieferung

Dem Benutzer mitteilen:

• Pfade zu out/final.mp4 und out/poster.png (Poster: render.mjs <slug> --poster <t>).
• brief.md: Die vollständigen strukturierten Anweisungen, Aufzeichnungen der beiden Bestätigungen; wiederverwendbar, enthält keine API-Anmeldeinformationen.
• Bei Sprachausgabe: Das Benutzerskript, die Satz-Zeitachse und die Quellen der einzelnen Spuren; bei langen Filmen das Kapitel-Manifest und die Wiederherstellungsbefehle für Unterbrechungen.
• Ergebnisse der technischen Prüfung (alle PASS), noch nicht gelöste Probleme aus dem Review-Protokoll, Renderzeit.
• Wie der Film neu erstellt werden kann (sh build.sh), wie nur ein Abschnitt geändert werden kann.
• Quellen und Lizenzen von Drittanbieter-Material (Schriftarten, Benutzermaterial, Musik); den Benutzer bitten, faktenbasierte Inhalte noch einmal zu überprüfen.

Review-Ergebnisse und Überprüfungsnachweise werden in der Projektdatei qa/review_log.md gespeichert und zusammen mit den Produktionsdateien ausgeliefert.

---

Grundregeln (für alle Stile verbindlich)

1. Anforderungen und Skript: Pflichtangaben bestätigt; Video nicht länger als 20 Minuten; TTS-Skript muss vom Benutzer stammen. Längenkonflikte müssen abgestimmt werden, kein eigenmächtiges Ändern, Kürzen oder Beschleunigen.
2. Faktenkorrektheit: Produktfunktionen, Zahlen, Namen stammen nur vom Benutzer oder aus zuverlässigen Quellen; Unsicheres kennzeichnen.
3. Lesbarkeit von Text: Schriftgröße auch auf Handy-Größe lesbar; Verweildauer ausreichend zum Lesen (siehe craft.md Abschnitt 7); Text läuft nicht über, überlappt nicht und wird nicht verdeckt.
4. Materiallizenzen: Logo, Screenshots, Schriftarten, Musik müssen verwendbar sein; bei Auslieferung auflisten.
5. Technische Korrektheit: Deterministisches Rendering, technische Prüfung vollständig bestanden, keine schwarzen Frames, Ende nicht abrupt (Endtitel einfrieren oder nahtloser Loop).
6. Stilkonsistenz: Die gewählten Stilregeln von Anfang bis Ende einhalten; nicht in die Verbotsliste des Briefings fallen.

Darüber hinaus bestimmen Stil und Inhalt, wie viel Bewegung, ob Federn verwendet werden, die Dichte der Soundeffekte und das Tempo (siehe references/styles/ und craft.md).

---

Tools – Schnellreferenz (S=<skill>/scripts)

Zweck	Befehl
Abhängigkeiten installieren / Umgebung prüfen / Selbsttest	sh $S/setup.sh · node $S/check-env.mjs · cd $S && npm test
Projekt erstellen	sh $S/scaffold.sh <slug> [--audio synth|tone|layer|file|none]
Standbilder + Zusammenstellung	node $S/render.mjs <slug> --still 0.5,3,7.2 --sheet · --range 0:15:1 --sheet
Drei Richtungen / Poster	node $S/render.mjs <slug> --directions a,b,c --at 14.5,2,0 → qa/directions.png · --poster 14.5 → out/poster.png
Deterministisch	node $S/render.mjs <slug> --determinism
Textrahmen (Review-Material)	node $S/render.mjs <slug> --text-check [--safe auto|none|T,R,B,L] → qa/text.json + Markierungsbilder (wird von build.sh automatisch ausgeführt)
Referenzvideo analysieren	node $S/inspect.mjs grid <ref> --strips (Schnittpunkte + Beat-Raster + Übergangs-Kontinuierliche-Frames) · heat <ref> (Bewegungs-Wärmekarte pro Segment)
Proxy / Final Cut / Segment	--size 960x540 --out out/proxy.mp4 · Final Cut sh <slug>/build.sh --subframes 2 --grain 4 (Spezifikationen oben in build.sh) · --start 6 --duration 3 --out out/seg.mp4
Sound	node $S/audio.mjs build <slug>/score.mjs (oder score.tone.js) · samples salamander · beats <track> --out audio/beats.json · check audio/music.wav (liest DROPS)
Sprachausgabe / Finaler Mix	node $S/narration.mjs tts … · import … · mix … · check … (Parameter siehe narration.md)
Langfilm-Build	node $S/build-long.mjs <slug>/chapters.json (Parameter siehe long-form.md)
Vorschau mit Ton	node $S/preview.mjs <slug> --size 1920x1080 --fps 30 (kann --audio audio/final.wav hinzufügen; Verwendung siehe stack.md)
Abnahme & Review-Material	node $S/inspect.mjs qa out/final.mp4 --expect-… (wird von build.sh automatisch ausgeführt) · sheet · phone · strip --at 4.2 · loop · motion (liest SHOTS / HOLDS: Bewegung, Sprünge, Blink-Frames pro Einstellung)

Referenzdateien (bei Bedarf lesen)

Datei	Wann lesen
references/formats.md	Schritt 2: Verwendungszweck, z. B. Werbefilm, Portfolio, UI-Animation, Typografie-Beat-Sync, Logo, Daten-Explosion, Greenscreen-Composing
references/styles/INDEX.md	Schritt 2: Verzeichnis der 43 Stile, Drei-Richtungen-Regel, Mischregeln; dann nur die ausgewählte(n) styles/<slug>.md lesen. Benutzerdefiniert mit styles/_template.md
references/craft.md	Schritt 2 und 4: Rhythmus, Bewegung, Übergänge, Kamera, Typografie, Farbe, Textur, Merkmale, Standard-Klischee-Liste
references/brief-template.md	Beim Schreiben des Briefings
references/stack.md	Schritt 4: Seitenvertrag, Deterministisch, Fallstricke der Technologien, Schriftarten, Material, verschiedene Seitenverhältnisse, Performance
references/recipes.md	Wenn vorgefertigte Lösungen benötigt werden
references/sound.md	Schritt 2 (Abschnitt 2: Klangliche Richtung) und Schritt 5
references/review.md	Schritt 6: Erklärung der technischen Prüfung, Review-Checkliste, Unabhängiger Review, Häufige Probleme, Auslieferungs-Checkliste
references/narration.md	Bei Auswahl von TTS, Benutzersprachaufnahme, unabhängigem BGM/Soundeffekt-Mix
references/long-form.md	Bei mehr als 2 Minuten: Kapitelplanung, persistenter Cache, segmentierte Audio- und Wiederherstellungs-Builds