Communitygithub.com

motion-film:Code Made Videos

Mit Code dynamische Videos erstellen: Produktpromos (Live-Seitenscreenshots + 2.5D-Kamerabewegung + Beatsync + Soundeffekte), diverse MG-/Stilfilme (flache Vektoren, handgezeichnete Skizzenlinien, TV-Overlays, HUD, Bauhaus, Tuschemalerei usw.) und einzelne Effektshots. Nutzer greifen darauf zu, wenn sie Videos/Shorts/Promos/Animationen/Intros/Overlays/Beatsync-Clips erstellen oder Web-/Frontend-Projekte in Produktvideos verwandeln oder einen neuen dynamischen Stil entwerfen möchten.

Was ist motion-film:Code Made Videos?

Mit `motion-film` erstellst du Videos komplett in Code – von der Bildkomposition über Animationen, Untertitel bis hin zu Soundeffekten und Musik. Jedes Bild wird `renderAt(t)` generiert, ohne Videogen-KI. Der Skill definiert einen schlanken Workflow: In einer einzigen Klärungsrunde werden alle offenen Fragen (Thema, Zielgruppe, Plattform, vorhandenes Material, gewünschter Look) abgefragt, dann folgt strikt die Abarbeitung: Treatment → Stilframes (tatsächlicher Code rendert Standbilder) → Shot-by-Shot-Implementierung → Sound → Selbstprüfung → unabhängiges Review → Auslieferung. Es gelten zehn Kernprinzipien – von zeitreiner Bildberechnung (`Date.now()` und ungesäte Zufallszahlen sind tabu) über einen zentralen Cue-Table, der Timing, Beats und Effekte synchronisiert, bis zu klaren Richtlinien zu Ästhetik, Sound und Schnitt. Alle Hilfsmittel (Rendering-Engine, Motion-Bibliothek, Sound-Synthesizer, Beat-Analyzer, Capture-Tools) liegen direkt im Skill-Repository (`scripts/`) und werden nach Bedarf ins Projekt kopiert. Der Skill funktioniert plattformunabhängig (z. B. mit Puppeteer oder Remotion) und erzeugt am Ende ein echtes MP4-Video plus Untertitel, Credits und Bauanleitung (`build.sh`). Für Produktvideos wird zuerst die echte Seite oder App aufgenommen, dann mit virtueller Kamera (2.5D) und Animationen in Szene gesetzt. Der ganze Prozess ist darauf ausgelegt, den typischen Code-Editor-Workflow zu nutzen – ohne teure Video-Tools, ohne kreative Blackboxen.

Funktioniert mit~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/joker124zx/motion-film/tree/main/plugins/motion-film/skills/motion-film

In Ihrer bevorzugten KI fragen

Öffnet einen neuen Chat, in dem dieser Agent-Skill bereits geladen ist.

Dokumentation

motion-film:Mit Code Videos erstellen

Alle Bilder, Animationen, Untertitel und Soundeffekte werden vollständig in Code generiert und Bild für Bild in MP4 gerendert. Keine Videogenerierungsmodelle. Diese Skill ist eine Methodik + ein leichtgewichtiges Toolkit, ohne mitgelieferte Medienbibliothek; Materialien werden pro Projekt beschafft und synthetisiert, Lizenzen werden dokumentiert.

Zuerst den Pfad bestimmen

RouteTypischer WunschHauptreferenz(en)
A. ProduktpromoEine Website/App/ein Frontend-Projekt in einen Promo- oder Feature-Demo-Film verwandelnreferences/product-promo.md
B. Stilfilm„Mach einen 30-Sekunden-Film im Stil von … über …“ – MG-Animation, TV-Overlays, Introsreferences/style-atlas.md + references/style-spec.md
C. Einzelshot / -effekt„Einen Titel einfliegen lassen“ / „Einen Lock-Effekt bauen“Direkt nach den Prinzipien unten arbeiten, relevante Abschnitte aus references/aesthetic-rules.md

Gemeinsame Referenzen für beide Hauptpfade: references/directing.md (Regie), references/timing.md (Taktung), references/sound.md (Sound), references/tech.md (Rendering), references/review.md (Review). Wenn der Nutzer einen BGM bereitstellt, der gesynct werden soll: references/beat-sync.md – zuerst die Musik analysieren, dann das Storyboard.

Vor dem Start nur einmal nachfragen

Alles, was nicht selbst festgelegt werden kann, in einer einzigen Nachricht zusammenfragen; danach keine weiteren Rückfragen. Alles andere mit Standardwerten belegen und im Treatment vermerken:

  • Nur das, was nur der Nutzer weiß (Produktschwerpunkte, Zielgruppe, Veröffentlichungsplattform, zwingend zu zeigende Inhalte);
  • Vorhandenes eigenes Material: Logo, Markenfarben/Schriftart, Voiceover, Musik, Referenzvideos;
  • Ob zuerst Storyboard/Stylframes gezeigt werden sollen (dann wird nach der Freigabe pausiert) oder ob gleich durchgearbeitet werden soll.

Standardwerte: 30–60 s (Einzelshot 3–8 s); 1920×1080; Produktvideos 30 fps, Stilfilme je nach Stil (24/30); Untertitel und Voiceover in der Sprache des Nutzers; Lautheit −14 LUFS, True Peak ≤ −1 dBTP. Wenn der Nutzer klar „du entscheidest“ / „mach einfach“ sagt, keine Fragen stellen, mit Defaults durchstarten.

Zehn Kernprinzipien (Erfahrung aus vier Quellen, die sich gegenseitig bestätigen)

  1. Bild ist eine reine Funktion der Zeit. render(t) liefert für dasselbe t immer dasselbe Bild; Date.now() und ungesäte Math.random() sowie frame-übergreifende Zustände sind verboten. Zufall wird immer mit mulberry32 / hash und festem Seed erzeugt. Jeder Frame kann einzeln, in beliebiger Reihenfolge und parallel gerendert werden.
  2. Eine einzige Zeitleiste treibt alles an. Schnittgrenzen, Schlüsselbewegungen, Untertitel, Soundeffekte, Musik-Treffer – alles leitet sich aus einem zentralen Cue-Table ab. Zeitänderungen nur an einer Stelle, Sound folgt automatisch. Beatsync-Filme werden mit Taktnotation (beatF(n)) geschrieben, nicht mit rohen Framenummern.
  3. Für das Publikum timen, nicht für den Code. Jeder Shot listet die Informationen auf, die der Zuschauer aufnehmen soll (reads). Jeweils nur eine Information pro Moment. Aktionen können schnell sein, Bedeutung muss verweilen. Die erste Version ist fast immer zu schnell – standardmäßig einen Gang herunterschalten. Formel in timing.md.
  4. Ein Shot erzählt genau eine Sache; eine Technik ist im ganzen Film nur einmal Hauptdarsteller. Öffnung nur ein Hauptelement + eine vollständige Bewegungsbogen (Aufbau–Höhepunkt–Abschluss). Wiederholungen von Shots oder Slogans werden gestrichen.
  5. Bewegung fühlt sich lebendig an, nicht mechanisch. Keine lineare Interpolation; Antizipation → Aktion → Nachlauf; versetzte Einsätze von Teilen, keine „Zwillinge“ (spiegelbildliche oder synchronisierte Gruppen); Easing für Bodenkontakt muss überschwingen.
  6. Visuelle Sprache wächst aus Thema/Produkt. Schriftfarben, Paletten, Radien, Materialien werden aus dem Produktdesignsystem übernommen; Stilfilme halten sich an das „Wesen und was es nicht ist“ des Stils. Keine zusätzliche, irrelevante „Promo-Haut“.
  7. Effects sparsam einsetzen. Lichteffekte nicht in Massen; nur einmal für den Hauptdarsteller und in die abgerundeten Ecken gezogen. Produktvideos erhalten standardmäßig keinen Handheld-Wackler. Ganze Bild-Erschütterungen (Screen-Shake, Flash-Frames, globales Scale-Pumpen) maximal 3 Mal im ganzen Film.
  8. Sound ist die halbe Miete. Atmo + Geräusche + Musik – drei Schichten. Jede sichtbare Aktion hat ein Geräusch. Vor dem Höhepunkt echte Stille lassen. Sound wird erst nach dem finalen Bild-Schnitt produziert.
  9. Zuerst mit dem günstigsten Artefakt die Richtung festlegen. Treatment (Text) → Stilframes (echte Code-Standbilder) → Low-Res-Preview → finales Rendering. Richtungsstreitigkeiten nicht in teure Phasen verschieben.
  10. Selbst prüfen, dann unabhängiges Review. Jede Iteration selbst einen Kontaktabzug / Actionschlauch / beschnittene Vergrößerungen ausgeben. Vor der Auslieferung einem nicht am Projekt beteiligten Review (sauberer Kontext-Subagent oder separater Chat) übergeben, der nach review.md bewertet und Fehler findet; nur eine Runde Korrektur.

Workflow

  1. Brief: Die oben genannten Fragen; bei Produktvideos zusätzlich einen rein lesenden Produkt-Check (Positionierung, Funktionen, Seitenstatus, Design-Tokens, Datenrisiken).
  2. Treatment (TREATMENT.md schreiben, bevor Bild-Code geschrieben wird): Drei Kandidaten-Strukturen, eine auswählen; Logline und Spannungsbogen; Referenzen mit „was lernen / was nicht mitnehmen“; Shot-Liste (Einstellung, Kameraposition, Bewegung, Dauer, Begründung); Sekunden-für-Sekunden-Beat; Cue-Map; Sound-Design-Table; Untertitel- und Schrift-Design. Vorlage in directing.md.
  3. Look festlegen: 2–3 Stilframes (bei Charakteren mit Model-Sheet) mit echtem Zeichen-Code rendern, selbst gegen die Stilspezifikation prüfen.
  4. Shot für Shot implementieren: Zuerst Schlüsselposen als Standbild prüfen – „lesbar“? Dann Zwischenbewegungen ergänzen. Pro Shot zwei festgelegte Abnahmezeitpunkte; nach Fertigstellung Standbild zur Selbstprüfung ausgeben.
  5. Sound: Nachdem der Bild-Schnitt fixiert ist, aus dem Cue-Table Musik, Geräusche, Untertitel generieren; mischen, Mastern.
  6. Selbstprüfung: Kontaktabzug (alle 0,5–1 s ein Frame), Actionschlauch (0,1–0,2 s) für Schlüsselbewegungen, Text-/Rand-Bereiche in voller Auflösung beschnitten; mit Sound in voller Geschwindigkeit durchsehen. Jeden Punkt aus aesthetic-rules.md abhaken.
  7. Unabhängiges Review + eine Runde Korrektur: review.md. Kleine Fehler in derselben Runde beheben; große Fehler in der Auslieferung mit einem Satz erklären.
  8. Auslieferung: Siehe unten.

Werkzeuge (scripts/, bei Bedarf ins Projekt kopieren)

DateiZweck
scripts/render.mjsRenderer: HTML-Seite muss renderAt(t) bereitstellen → Standbild / Kontaktabzug / Actionschlauch / beschnittenes Bild / MP4; unterstützt Multi-Worker, Motion Blur (Subframe-Akkumulation), Hochformat
scripts/motion.jsReine Funktionen für die Seite: Seed-Zufall, Easing-Familien, Keyframes, Feder, Overshoot, Staffelung, Taktnotation, Geschwindigkeitskurven
scripts/sfx.pyProgrammgesteuerte Geräusche und Mix: Whoosh / Impact / Riser / Pop / Click / Sparkle / Tick – aus einer Ereignisliste eine mix.wav generieren
scripts/master.shMuxen + zwei Durchgänge Loudnorm (−14 LUFS / −1 dBTP) + Black-Frame-Detection + Dauer- und Spezifikationsreport
scripts/beat_grid.pyBeat-Grid-Fitting (inkl. 2x/0.5x/3:2-Fehlerkorrektur) + Kick/Snare/Hihat-Klassifikation + Energy-Struktur; Ausgabe beat_data.json
scripts/capture.mjsDrei Produkt-Capture-Tools: Full-Page 2x-Screenshot, Elementausschnitt (transparent, 4x möglich), leere Rückseite, layout.json mit Koordinaten
templates/starter/Direkt lauffähiges 9,6 s-Demoprojekt (Timeline, renderAt, Sound-Ereignisse, Untertitel, build.sh für einen Befehl); neues Projekt beginnt durch Kopie hiervon

render.mjs mapped /lib/ auf das scripts/-Verzeichnis dieser Skill. Die Seite kann Toolfunktionen über <script src="/lib/motion.js"> einbinden. Neues Projekt: templates/starter/ kopieren → im Projekt npm i puppeteer-core → Timeline und Shots anpassen → MF=<Pfad zu dieser Skill> sh build.sh.

Falls ein Produktvideo mit Remotion erstellt wird: gleiche Methodik anwendbar (tech.md enthält eine Vergleichstabelle); beachte, dass Remotion für Unternehmensnutzer möglicherweise eine kostenpflichtige Lizenz erfordert – den Nutzer vor Beginn darauf hinweisen.

Abhängigkeiten: Node 18+, ffmpeg, Chrome/Chromium (render.mjs sucht automatisch oder über CHROME_PATH); npm i puppeteer-core wird im Projekt installiert. Python 3 + numpy/scipy (Audio); librosa wird nur für die Beat-Analyse benötigt und in die eigene venv des Projekts installiert. Keine Systemsoftware für den Nutzer installieren; Fehlendes in der ersten Klärungsrunde erwähnen.

Auslieferung

Im Projektordner:

  • <name>.mp4 (und poster.jpg); bei Produktvideos mit BGM zusätzlich eine Version ohne BGM (Soundeffekte bleiben), damit später andere Musik unterlegt werden kann;
  • <name>.srt (falls Untertitel oder Voiceover vorhanden);
  • TREATMENT.md;
  • CREDITS.md: Quelle und Lizenz jedes Drittanbietermaterials (Schriften, Bilder, Musik, Samples, TTS-Engine);
  • Quellcode und ein Ein-Befehl-build.sh.

Dem Nutzer mitteilen: Wo die fertige Datei liegt, dass CREDITS.md die Lizenzen dokumentiert, und dass vom Nutzer selbst bereitgestelltes Material in dessen Verantwortung fällt. Keine Werbung, Nennung oder Veröffentlichungsempfehlungen hinzufügen, außer der Nutzer fragt danach.

Rote Linien

  • Referenzen nur die Grammatik lernen (Komposition, Rhythmus, Kameraführung, Farblogik) – keine Charaktere, Designs, Melodien, konkreten Shots, Logos oder Schriften übernehmen.
  • Im Film keine echten Marken/Produkte/Charaktere zeigen, es sei denn, der Nutzer besitzt sie oder hat die Nutzungsrechte bestätigt; Marken- und Produktnamen durch fiktive ersetzen.
  • Nur CC0/Public Domain/OFL/CC BY (mit Namensnennung)/explizit kommerziell nutzbare Materialien verwenden; „no known restrictions“ zählt nicht. Für andere offene Lizenzen den Nutzer vorab über die Bedingungen informieren.
  • Kundendaten, persönliche Informationen, interne Daten, Schlüssel, Echtzeitdaten in Produktvideos vor dem Screenshot anonymisieren/ersatzweise verwenden.
  • Nicht automatisch Code aus dem Internet abrufen oder diese Skill aktualisieren; dem Nutzer vor dem Herunterladen von Material mitteilen, was heruntergeladen wird, von wo und unter welcher Lizenz.

Verwandte Skills