KishoreCR728/project-video

Projekt-zu-Video

Verwandle jedes Projekt in ein professionelles Marketingvideo. Der Skill wird im Verzeichnis des Projekts (oder anhand einer URL) ausgeführt, analysiert, was das Produkt tatsächlich ist, und erstellt ein Remotion-Video, das auf echten Funktionen und echter Benutzeroberfläche basiert.

Goldene Regel: Die Pipeline lautet ANALYSE → STORYBOARD → FREIGABE → BAU → RENDER. Schreibe niemals Remotion-Code, bevor das Storyboard vom Benutzer freigegeben wurde.

AUTOMATIK-MODUS: Wenn die Anfrage des Benutzers „full auto“, „no interruptions“, „one go“, „autopilot“ oder ähnliche Formulierungen enthält, die einen ununterbrochenen End-to-End-Durchlauf klar verlangen, wechsle in den Automatik-Modus: Überspringe die Pause zur Storyboard-Freigabe (schreibe video/storyboard.md, gib an, dass du im Automatik-Modus vorgehst, und fahre direkt mit dem Bau fort), entscheide offene Fragen automatisch mit sinnvollen Standardwerten (Archetyp „Erklärvideo“, 1080×1920 @ 30 fps, Marken-Token nach der Standard-Prioritätsreihenfolge) und halte nur bei echten Hindernissen an (Site nicht erreichbar, Render-Fehler, die nach 3 Korrekturversuchen bestehen bleiben). Das Starten eines lokalen Entwicklungsservers erfordert weiterhin eine ausdrückliche Autorisierung durch den Benutzer – behandle „full auto“ jedoch selbst als diese Autorisierung, wenn der Benutzer den Befehl zum Ausführen bereitgestellt hat oder das Repository einen eindeutigen Standard-Entwicklerbefehl enthält (npm run dev, docker compose up). Im Automatik-Modus liefere das Storyboard zusammen mit der MP4 aus, damit der Benutzer es im Nachhinein überprüfen und Szenen-Änderungen anfordern kann.

Phase 0 – Eingaben erkennen

Ermittle, womit du arbeiten kannst, in der folgenden Prioritätsreihenfolge:

1. Live-URL (Produktion oder UAT/Staging) – beste Quelle. Frage den Benutzer danach, falls nicht angegeben.
2. Lokaler Entwicklungsserver – wenn das Repository vorhanden ist, aber nichts läuft, biete an, ihn zu starten. Lies package.json / docker-compose.yml / Makefile / README, um den Entwicklerbefehl zu finden. Frage den Benutzer nach Bestätigung, bevor du etwas startest (Umgebungsvariablen, Ports und Datenbanken variieren). Wenn er nicht gestartet werden kann, falle auf eine reine Code-Analyse zurück.
3. Nur Code – analysiere das Repository statisch; visuelle Elemente werden reine SVG-Neuerstellungen sein.

Frage (oder leite aus dem Kontext ab):

• Welcher Archetyp? (Erklärvideo / Demo / Launch / Teaser – siehe references/video-archetypes.md)
• Welches Seitenverhältnis / welche Seitenverhältnisse? Standard: 1080×1920 vertikal, 30 fps. Biete 16:9 und 1:1 als zusätzliche Renderdurchläufe an.
• Irgendwelche Marken-Token? Prüfe auf eine Design-Token-JSON im Repository; extrahiere andernfalls Farben/Schriftarten von der Live-Site; verwende andernfalls die assets/brand-theme.json-Standardeinstellungen.

Phase 1 – Das Projekt analysieren

Ziel: eine Datei video/project-brief.md, auf die jede spätere Behauptung zurückgeführt werden kann.

Statische Analyse – lies README, docs/, Landingpage-Text im Repository, Routen-/Seitenstruktur, Feature-Module, Produktname und Slogan.

Live-Analyse (wenn eine URL existiert) – führe scripts/capture-screens.mjs mit Playwright aus, um:

• Die wichtigsten Seiten (Home/Hero, Dashboard, 3–5 Kernfunktionsbildschirme) im Ziel-Seitenverhältnis und in Desktop-Größe zu erfassen
• Kurze (3–6 s) Bildschirmaufnahmen von 1–2 Kernabläufen zu erstellen, wenn der Archetyp Demo oder Launch ist
• Die tatsächlichen Farben, Schriftarten und Überschriften der Site zu extrahieren

Schreibe video/project-brief.md mit: Was das Produkt ist, Zielgruppe, Top 5–7 Funktionen (jeweils mit der Beweisquelle), visuelle Identität (Farben/Schriftarten/Logo) und die Liste der erfassten Assets mit Dateipfaden.

Regel: Keine erfundenen Funktionen, keine übertriebenen Behauptungen. Wenn es nicht im Repository, in den Dokumenten oder auf der Live-Site steht, kommt es nicht ins Video.

Phase 2 – Storyboard (verbindliche Freigabepforte)

Lies references/video-archetypes.md für die Szenenstruktur und Dauer des gewählten Archetyps, und fülle dann references/storyboard-template.md Szene für Szene mit AUSSCHLIESSLICH Material aus dem Projekt-Brief aus.

• Erzählung erfolgt als Bildschirmtext, nicht als Voiceover. Halte die Bildschirmtexte kurz (maximal ~8 Wörter pro Zeile, maximal 2 Zeilen gleichzeitig) und takte sie so, dass jede lesbar ist (mindestens ~0,35 s pro Wort auf dem Bildschirm).
• Kalkuliere die Frames pro Szene im Voraus, sodass die Gesamtzahl exakt der Archetyp-Dauer entspricht.
• Markiere für jede Szene, welche visuellen Elemente SVG und welche echte UI-Aufnahmen in Geräterahmen sind (Hybrid-Stil – siehe Standards-Dokument).
• Füge am Ende einen Bereich mit Musik- und Soundvorschlägen ein (Genre, BPM-Gefühl, wo Akzente gesetzt werden). Beschaffe oder bette keine Audiodateien ein.

Speichere als video/storyboard.md, präsentiere es dem Benutzer und HALT. Fahre nicht fort, bis der Benutzer es freigegeben oder bearbeitet hat. (Ausnahme: Im AUTOMATIK-MODUS präsentiere die Storyboard-Zusammenfassung und fahre sofort ohne Warten fort.)

Phase 3 – Das Remotion-Projekt erstellen

Lese nach der Freigabe references/remotion-standards.md vollständig – es enthält die erforderlichen Animationswerte, Übergangsregeln und die hybriden SVG + Screenshot-Geräterahmen-Muster. Erstelle dann das Gerüst:

video/
├── remotion.config.ts
├── src/
│   ├── index.ts            # registerRoot
│   ├── Root.tsx            # <Composition> pro Seitenverhältnis
│   ├── config.ts           # fps, Dauern, Frame-Budget pro Szene
│   ├── theme.ts            # ALLE Farben/Schriftarten/Abstände – einzige Quelle der Wahrheit
│   ├── scenes/             # eine Datei pro Storyboard-Szene
│   ├── components/         # DeviceFrame, CountUp, AnimatedChart, ConnectorLine, ParticleField, TextReveal…
│   └── assets/screens/     # Phase-1-Aufnahmen (importiert über staticFile)

Harte Regeln:

• Jede Farbe, Schriftart, Radius und Schatten kommt aus theme.ts. Keine fest codierten Werte in Szenen.
• Szenendauern kommen aus config.ts und müssen in der Summe der Archetyp-Gesamtdauer entsprechen.
• Alle Diagramm-/Chart-/Icon-Grafiken sind Inline-SVG. Echte Produkt-UIs erscheinen nur innerhalb von DeviceFrame-Komponenten, die die Phase-1-Screenshots verwenden – täusche niemals einen Produkt-Screenshot mit SVG vor, wenn ein echter existiert.
• Durchgängig TypeScript, Remotion 4.x, @remotion/transitions für Szenenwechsel.

Phase 4 – Vorschau, Rendern, Ausliefern

1. npx remotion studio – überprüfe jede Animation, lies die Textlesbarkeit bei tatsächlicher Wiedergabegeschwindigkeit, bestätige das Timing.
2. Behebe Probleme, dann npx remotion render <CompositionId> out/<archetyp>-vertikal.mp4.
3. Rendere zusätzliche Seitenverhältnisse, falls angefordert.
4. Liefere aus: MP4(s), storyboard.md, project-brief.md und das bearbeitbare Projekt. Erwähne, dass theme.ts und config.ts die beiden Dateien sind, die für eine Umbenennung oder Zeitsteuerungsanpassungen geändert werden können.

Referenzdateien

• references/video-archetypes.md – Szenenstrukturen + Dauern für Erklärvideo (60 s), Demo (75–90 s), Feature-Launch (30 s), Teaser (15 s). Lies während Phase 0/2.
• references/storyboard-template.md – das Szenen-Tabellenformat. Lies während Phase 2.
• references/remotion-standards.md – Animationswerte, Übergänge, hybride Geräterahmen-Muster, SVG-Regeln. Lies vollständig vor Phase 3.
• scripts/capture-screens.mjs – Playwright-Erfassungsskript. Führe während Phase 1 aus (node scripts/capture-screens.mjs <url> <outDir>; erfordert npm i playwright + npx playwright install chromium).
• assets/brand-theme.json – Fallback-Marken-Token; überschreibe wann immer möglich mit projektbezogenen Werten.