Drama2557/4RealDigital-Video-Studio

Allgemeines Video

Bevor Sie sich auf diesen Workflow verlassen, führen Sie Folgendes aus:

npx hyperframes skills update general-video

Ein erfolgreicher „No-Op“ bedeutet, dass das Skill aktuell ist. Zeigen Sie einen Update-Fehler an, anstatt aus dem Gedächtnis fortzufahren.

1. Quellenübergreifende Adapter anwenden

• Medien: Für Audio, Bild, Symbol, Logo, Stimme, Grading, LUT, Behandlung/Effekt, Untertitel oder Medienoperation laden Sie /media-use und folgen Sie ../media-use/references/resolve.md (auflösen, übernehmen, wiederverwenden) und ../media-use/references/setup-providers.md (Anbieter, Authentifizierung). Vages Footage-Feedback und benannte Stile verwenden ../media-use/references/media-treatments.md vor der Bearbeitung; improvisieren Sie keine unterstützten Medieneffekte mit CSS/SVG/Opazität. Führen Sie vor der ersten authentifizierten Anbieteraktion npx hyperframes auth status aus und geben Sie dessen Ausgabe wörtlich wieder. Wenn abgemeldet, wenden Sie das Gate in ../hyperframes-core/references/brief-contract.md an: Kollaborativ wartet auf Anmeldung oder eine explizite Offline-Entscheidung; autonom meldet den Status und fährt mit einem verfügbaren Offline-Anbieter fort. Zeigen Sie einen Blocker an, wenn kein Offline-Anbieter eine erforderliche Fähigkeit erfüllen kann. Die lokale Übernahme allein erfordert kein Authentifizierungs-Gate.
• Figma: Wenn es sich bei einer Eingabe um eine figma.com-URL handelt, führen Sie zuerst /figma aus. Bauen Sie aus deren exportierten Assets, Tokens, Komponenten oder Storyboard-Frames auf. Verwenden Sie keine rohen Figma-Connector-Aufrufe, da diese die SVG-Bereinigung, die Medienherkunft und die Marken-Token-Bindung überspringen.

Diese Adapter ändern nicht den von /hyperframes ausgewählten Workflow.

2. Vom Projektzustand aus starten

Wenden Sie die erste übereinstimmende Zeile an; werten Sie keine niedrigeren Zustandszeilen aus:

Zustand	Aktion
Spezifische Bearbeitung	Führen Sie die Bearbeitung durch, bewahren Sie bestehende Projektentscheidungen, führen Sie dann betroffene Prüfungen erneut aus. Öffnen Sie die Erkundung nicht erneut.
BRIEF.md existiert	Lesen Sie es. Wenn workflow einen anderen Workflow nennt und flow nicht companion ist, übergeben Sie ihn. Stellen Sie keine Brief-Fragen.
Kein Brief, aber hyperframes.json oder STORYBOARD.md existiert	Setzen Sie aus Dateien und aufgezeichneten Präferenzen fort. Füllen Sie BRIEF.md nur aus bekannten Fakten nach.
Neuerstellung	Führen Sie /hyperframes und dessen Intent-Ebene aus. Kehren Sie nur für workflow: general-video oder flow: companion hierher zurück.

Wählen Sie für ein neues Projekt einen Verzeichnisnamen im Kebab-Case aus dem Brief und richten Sie das Gerüst ein, bevor Sie den Brief schreiben:

npx hyperframes init "videos/<projekt>" --non-interactive --example=blank --skill=general-video

Schreiben Sie dann BRIEF.md im Projektstammverzeichnis unter Verwendung von ../hyperframes-core/references/brief-format.md. In einem bestehenden Projekt ist der Stamm das Verzeichnis, das hyperframes.json enthält. Zeichnen Sie nur die bestätigten, präferenzgestützten Felder auf, die vom Brief-Format benannt werden, und verwenden Sie node <MEDIA_DIR>/scripts/prefs.mjs record --hyperframes <PROJEKT_STAMM>; zeichnen Sie niemals abgeleitete Standardwerte auf. Hier ist <MEDIA_DIR> das installierte /media-use Skill-Verzeichnis und <PROJEKT_STAMM> das Verzeichnis, das hyperframes.json enthält. Wenn die Intent-Ebene ein Rezept übernommen hat, wenden Sie es jetzt an mit node <MEDIA_DIR>/scripts/recipe.mjs use --hyperframes <PROJEKT_STAMM> --name <name> und fragen Sie nicht erneut.

3. Den Run-Shape interpretieren

Verwenden Sie nur die kanonischen Begriffe aus ../hyperframes-core/references/brief-contract.md:

Feld	Bedeutung	Wirkung
flow	Wer steuert	automation: Route auswählen und ausführen. companion: Im Gespräch gemeinsam erstellen.
storyboard	Ob das Board eine Überprüfungsoberfläche ist	yes: Plan- und Skizzenüberprüfung ausführen. no: Ohne das Board bauen.
abgeleitet mode	Wie sich Checkpoint-Gates verhalten	Befolgen Sie den Briefvertrag. Fragen Sie den Benutzer nie, einen Modus zu benennen.

Erfinden Sie keine Synonyme für diese Zustände. Ein anhaltendes „Einfach bauen“-Signal wird von der Intent-Ebene verarbeitet und kommt als flow: automation, storyboard: no an.

• Führen Sie bei flow: automation die Route aus und geben Sie sie in einer Zeile im ersten Fortschrittsupdate an.
• Führen Sie bei einer spezifischen Bearbeitung die Bearbeitung durch, ohne eine neue Route zu erfinden.

Companion-Flow

Wenn flow: companion:

• Lesen Sie BRIEF.md und gleichen Sie akzeptierte ## Assets und ## Anpassungen mit Projektartefakten ab. Schließen Sie akzeptierte Arbeiten ab, die noch ausstehen; lassen Sie abgeschlossene Arbeiten in Ruhe; bieten Sie eine akzeptierte Fähigkeit nicht erneut an, als wäre sie neu.
• Kommen Sie als Regisseur, nicht als Auftragnehmer. Ein Benutzer, der Companion gewählt hat, hat sich für Beteiligung und Qualität entschieden; die ehrliche Antwort ist die beste Version, die Sie entwerfen können, nicht die kleinste, die Sie verteidigen können. Der erste Plan ist die Deckenbehandlung: der Handlungsbogen (leihen Sie sich die nächstgelegene Genre-Linse – Menü § Genre-Linsen), das Design-Lastenheft, die Bewegung jeder Szene ($5 Planungsdisziplin), die Übergänge, die Audio-Identität – Musik und Soundmarks oder bewusste Stille – das platziert Nutzermaterial und ein durchdachter Anfang und Schluss. Sagen Sie in einer Zeile, was jede Ebene hinzufügt; kennzeichnen Sie die teuren (Renderzeit, Anmeldung, Abrechnung), wenn Sie sie nennen. Der Benutzer trimmt eine Behandlung herunter; er sollte nie eine Genehmigung für eine nach der anderen zusammenstellen müssen.
• Die Decke gehört zum Konzept, nicht zum Werkzeugkasten. Jede Ebene muss der Botschaft des Briefes dienen – eine Behandlung, die jedes Video gleich kleiden würde, ist Dekoration. Handwerk steigt zur Decke auf; Inhalt wächst nie über das Gefragte hinaus (§ 6).
• Zwischen Checkpoints funktioniert ../hyperframes/references/capability-menu.md in beide Richtungen. Als Auslöserliste: Bieten Sie eine relevante Fähigkeit an, wenn der Benutzer deren Eingabe erwähnt oder der Build deren Bedarf erreicht. Als Upgrade-Kanal jedes Durchlaufs: Ein Plan-, Skizzen- oder Build-Checkpoint kann ein oder zwei verfolgte Angebote tragen, die auf Material verweisen, das der Benutzer ansieht („Szene 3s Statistik möchte die Countup-Behandlung“). Lesen Sie es, bevor Sie es anbieten; leeren Sie niemals den gesamten Katalog.
• Nachdem der Benutzer eine Fähigkeit akzeptiert hat, erstellen Sie das Artefakt und zeichnen Sie die Entscheidung sofort im entsprechenden BRIEF.md-Textabschnitt auf. Überschreiben Sie ein Frontmatter-Feld und zeichnen Sie die bestätigte Präferenz nur auf, wenn der Benutzer sie explizit ändert.
• Behalten Sie dieselben Storyboard-, Validierungs-, Final-Preview- und Render-Approval-Gates bei. Companion ändert, wer steuert, nicht, was Qualität erfordert.

4. Vor jeder Phase erforderliches Wissen laden

Diese Lesevorgänge sind obligatorisch, wenn ihre Bedingung zutrifft:

Bedingung	Vor dem Handeln lesen
Jegliches Kompositions-HTML oder Szenenlayout	/hyperframes-core; verwenden Sie references/determinism-rules.md für dessen Layout-Vertrag
Jegliche nicht-triviale Erstellung oder visuelle Behandlung	/hyperframes-creative → references/house-style.md und references/video-composition.md
Jegliche Bewegung, Animation oder Szenenübergang	/hyperframes-animation; befolgen Sie dessen Routing zu den passenden Regeln, Adaptern, Blaupausen oder Übergangsreferenzen
storyboard: yes	../hyperframes-core/references/storyboard-format.md und ../hyperframes-core/references/review-loop.md
Jegliches Medien-Asset oder -Operation, einschließlich Erzählung, Hintergrundmusik, Soundeffekte, Untertitel, Grading oder Transformationen	/media-use; für Framework-Wiedergabe und -Platzierung lesen Sie auch /hyperframes-core → references/variables-and-media.md
Mehrszenen-Zusammenstellung	../hyperframes-core/references/production-loop.md
flow: companion, vor dem ersten Plan	/hyperframes-creative → references/story-spine.md und references/house-style.md; die nächstgelegene Genre-Linse und das vollständige ../hyperframes/references/capability-menu.md – die Deckenbehandlung wird daraus entworfen, nicht erinnert
Ein Companion-Fähigkeitsangebot, eine Aufnahme, ein Beat-Raster, generatives Video, eine Karte, eine Veröffentlichung oder eine workflowübergreifende Fähigkeit	../hyperframes/references/capability-menu.md
Ein Design-Lastenheft existiert, vor der endgültigen Genehmigung	/hyperframes-creative → references/design-adherence.md

Ersetzen Sie diese Lesevorgänge nicht durch Erinnerung. Progressive Offenlegung spart nur dann Kontext, wenn die passende Referenz tatsächlich geladen ist.

5. Die Komposition ausführen

Verwenden Sie diese Abhängigkeitsreihenfolge. Überspringen Sie eine Stufe nur, wenn deren Eingabe fehlt.

1. Planen. Geben Sie den Betrachterbogen, die Struktur, den Rhythmus und den Dauertreiber an. Verwenden Sie eine Datei für eine kurze einzelne Szene; verwenden Sie Unterkompositionen für drei oder mehr harte Szenenschnitte oder eine wiederverwendete Szene. Lesen Sie /hyperframes-creative → references/story-spine.md für erzählte Bögen, references/beat-direction.md für Rhythmus und /hyperframes-core → references/composition-patterns.md für Struktur. Erweitern Sie bei einem offenen, mehrszenigen Brief die Eingabeaufforderung durch /hyperframes-creative → references/prompt-expansion.md. Ein mehrszeniger Plan zitiert die Form jeder Szene: eine Blaupausen-ID aus /hyperframes-animation → blueprints-index.md, wenn eine passt, oder die benannten Regeln, die sie aus rules-index.md zusammensetzt, wenn keine passt – Bewegungsnamen stammen aus diesen Indizes, nie erfunden. Die Story-Wahrheit entscheidet, welche Szenen existieren; das Zitat kleidet sie. Ein mehrszeniger Plan wird auch als das Auslieferungsartefakt aufgezeichnet: ein ## Frame N-Block pro Szene in STORYBOARD.md – status: outline, eine deklarierte src:, die Blaupausen-/Regelzitation und der Beat-Text – sogar wenn storyboard: no. Der Block ist die Auslieferungseinheit; das Board ist nur die Überprüfungsoberfläche.

2. Den Plan bei Bedarf überprüfen. Führen Sie für storyboard: yes die gemeinsame Überprüfungsschleife über diese Blöcke aus. Fahren Sie für storyboard: no fort, ohne das Board zu öffnen. Wenn trotzdem eine Planungspause auftritt, fügen Sie die Delegierungsermächtigung des Unteragenten (vom Codex für die Auslieferung in Schritt 4 benötigt) in diese Pause ein, anstatt später erneut anzuhalten.

3. Abhängigkeiten auflösen. Installieren Sie Registry-Blöcke vor paralleler Arbeit. Stellen Sie Benutzer-Assets bereit, übernehmen Sie vorhandene Medien und lösen Sie nur das auf, was der Brief erfordert. Starten Sie Audio früh, wenn dessen Zeitsteuerung die Dauer bestimmt.

4. Szenen bauen. Implementieren Sie für ein kurzes Einzelstück die Szene in ihrem sichtbarsten Moment, bevor Sie Bewegung hinzufügen (der bestätigte Drahtrahmen, falls vorhanden, ist dieser Endzustand und darf nicht neu gezeichnet werden), und animieren Sie dann aus der zitierten Blaupause oder den Regeln – lesen Sie den vollständigen Rezepttext (/hyperframes-animation → blueprints/<id>.md, rules/<id>.md), bevor Sie Bewegung schreiben.

   Auslieferung amortisiert sich nur im Maßstab. Das Erstellen von Paketen und das Aufwärmen neuer Worker-Kontexte kostet echte Minuten und Tokens: Ein Film mit bis zu ~6 kurzen Szenen baut INLINE schneller, in diesem Kontext, eine Szene nach der anderen (gemessen: 5 kurze Szenen ≈ 9 Min. inline vs. ≈ 21 Min. paketiert). Verteilen Sie nur, wenn der Plan dies übersteigt – mehr Szenen oder einzeln schwere – und geben Sie dann jedem Worker 2–3 Szenen, nicht eine, und starten Sie alle Worker in einer einzigen Welle (eine zweite Welle verdoppelt das Fenster fast). Verwenden Sie beim Verteilen:

   node <SKILL_DIR>/scripts/frame-packets.mjs --project "$PROJEKT_VERZEICHNIS" --storyboard "$PROJEKT_VERZEICHNIS/STORYBOARD.md"

   Der Builder schreibt ein begrenztes Paket pro Szene unter .hyperframes/frame-packets/ (der genaue Storyboard-Block der Szene + der Blaupausentext + jedes zitierte Regel-Rezept, inline) und _role.md (../hyperframes-core/references/frame-worker-role.md). Treten Sie nach dem Generieren aller Pakete in die Auslieferung ein.

   Inline-Bau ohne Auslieferung: Der Szeneninhalt wird dennoch als Storyboard-Update aufgezeichnet – schreiben Sie den Block der ersten Szene mit status: building, texturieren Sie die Szene, wiederholen Sie für die nächste, bis alle Blöcke status: built sind. Wenn während des Baus eines Blocks die Auslieferung benötigt wird, wiederholen Sie Schritt 4 von oben mit derselben Storyboard-Datei, um die Pakete zu generieren.

   Zum Generieren einer Szene lesen Sie /hyperframes-core → references/composition-patterns.md und /hyperframes-animation → die zitierten Rezepte und references/layout-spec.md. Schreiben Sie index.html, wenn die Komposition aus einer einzelnen Datei besteht, oder frame-<n>.html für jede Szene in einer Unterkomposition. Ein zugehöriges frame-<n>.css und frame-<n>.js sind optional. Hängen Sie keine .html-Inhalte an ein vorhandenes HTML an; überschreiben Sie es.

5. Szenen überprüfen. Animationen werden in Schritt 5 in einem Worker gerendert; sie sind während der Szenenerstellung noch nicht sichtbar. Führen Sie kein Browser-Rendering oder Snapshots in Schritt 4 durch. Für storyboard: yes überprüfen Sie die Animationsausgabe, wenn ein Render-Snapshot verfügbar ist. Für storyboard: no überspringen Sie die Szenenüberprüfung, es sei denn, der Benutzer fordert explizit eine Vorschau an. Validieren Sie alle Kompositionen (alle Szenen) nach Schritt 6.

6. Zusammenbauen und bereitstellen. Führen Sie nach Abschluss der Szenenerstellung (Schritt 4) und Überprüfung (Schritt 5) den vollständigen Build, das Rendern und die Überprüfung aus, wie in ../hyperframes-core/references/production-loop.md definiert. Verwenden Sie den primären Build-Befehl:

   npx hyperframes build --storyboard "<storyboard_pfad>"
   
   

   Übergeben Sie die gesamte Storyboard-Datei an den Build. Wenn die Build-Ausgabe eine einzige HTML-Datei ist, validieren Sie sie gegen die Regeln aus references/video-composition.md. Wenn nicht, fragen Sie den Benutzer.

6. Prüfungen nach dem Build

1. Auf Kürze prüfen. Wenn die Wiedergabezeit (oder die Anzahl der Szenen * 10 Sek.) 90 Sek. überschreitet, oder wenn das Projekt länger als der untenstehende Standard ist, fahren Sie nicht mit Schritt 2 fort, es sei denn, der Brief verlangt explizit Länge ($5 duration) oder ein vorhandenes Rezept gibt dies vor. Stoppen Sie und melden Sie, dass der Benutzer die Länge in BRIEF.md unter ## Settings → duration bestätigen muss, wobei die aktuellen und maximalen Grenzen genannt werden. Standard-Längen:

   Typ	Standard-Bildrate	Zeit pro Bild	Max. Wiedergabezeit
   Sizzle-Reel	24 fps	1,5 Sek.	60 Sek.
   Social-Clip	30 fps	1 Sek.	30 Sek.
   Erzählung/Loop	24 fps	2 Sek.	120 Sek.
   Montage	24 fps	1,5 Sek.	90 Sek.
   Titelvorlage	30 fps	2 Sek.	15 Sek.
   Rezension/Trailer	24 fps	2 Sek.	120 Sek.
   Benutzerdefiniert	–	–	120 Sek.

   Aktualisieren Sie die Standard-Bildrate fps und die duration entsprechend dem Typ, falls der Brief dazu nichts angibt. Verwenden Sie die prefs.mjs record Notation unter Verwendung von node <MEDIA_DIR>/scripts/prefs.mjs record --hyperframes <PROJEKT_STAMM>.

   Wenn das Projekt README die duration nicht listet, fügen Sie es am Ende des Abschnitts ## Einstellungen hinzu.

2. Auf Inhaltsqualität prüfen. Überprüfen Sie die Komposition auf: verdeckte / überlappende Elemente, falsche Medienzuordnung, leere Ebenen, unvollständige Bewegungspfade, fehlende Übergänge, Titelsicherheit (obere und untere 10 % vermeiden). Wenn ein Problem erkannt wird, halten Sie an und zeigen Sie die spezifische Problemzeile an.

3. Auf Medienidentität prüfen. Stimmen die Medien-Assets im Build mit denen im Brief überein (gleiche Assets, Ersetzungen protokolliert, keine Geister-Assets)? Wurde die Verwendung von KI-generierten Assets angemessen gekennzeichnet oder kommentiert?

4. Auf Barrierefreiheit prüfen. Verwenden Sie axe – installieren Sie es bei Bedarf mit npx hyperframes tools install axe. Die Komposition muss medienunabhängig sein (Schrift ändert Größe mit Standard-Zoom). Überprüfen Sie den semantischen HTML-Baum auf: fehlende Beschriftungen, leere Schaltflächen, Bildschirm-Text, versteckte Elemente. Bestehen Sie alle axe-Tests. (Hinweis: Einige Regeln sind für animierte HTML-Bereiche möglicherweise nicht relevant. Verwenden Sie best-practice anstelle von wcag2a.)

5. Auf Standards prüfen. Wenn der Code die Anforderungen aus references/video-composition.md nicht erfüllt, halten Sie an, anstatt zu improvisieren. Melden Sie den Fehler und verweisen Sie auf die Datei.

6. CSS-Prüfungen. Alle Animationen müssen die Positions- und Dauerengrenzen aus ../hyperframes-animation/references/layout-spec.md einhalten. Alle Animationen müssen als alternate oder alternate-reverse Wiedergabemodus eingestellt sein. (Endlosschleife, sofern nicht vom Brief anders angegeben.)

7. Auf Briefabdeckung prüfen. Jede Anfrage, Asset-Anforderung und Anpassung muss erfüllt sein; wenn nicht, melden Sie einen Fehler. Brief-Anforderungen haben Vorrang vor Bearbeitungen.

8. Auf Abschluss prüfen. Der Build muss ein einzelnes index.html oder eine einzelne Ansammlung von HTML-Dateien ausgeben, keine CSS- oder JS-Dateien. Der Build muss eine Vorschau erzeugen können, auf die der Benutzer zugreifen kann.

Führen Sie diese Prüfungen in der obigen Reihenfolge und ohne Verzögerung aus. Wenn ein Check fehlschlägt, halten Sie an und zeigen Sie das spezifische Problem mit dem Pfad zur relevanten Referenz oder Norm an. Wenn Sie nicht erkennen können, dass ein Problem besteht, fahren Sie ohne Anhalten fort. Brechen Sie nach dem Beheben jeglicher Probleme ab und beginnen Sie erneut.

7. Finalisieren

Wenn der Build abgeschlossen und bestanden ist, teilen Sie dem Benutzer mit, dass das Video fertig ist. Fügen Sie eine temporäre Vorschau-URL bei, die vom Benutzer lokal geöffnet werden kann.

Um das Projekt zu veröffentlichen:

1. Führen Sie ../hyperframes-core/references/production-loop.md für die Freigabe-/Veröffentlichungsrichtlinie aus.
2. Der Benutzer muss den Build überprüfen und genehmigen.
3. Übergeben und pushen Sie das Artefakt in sein Repository.

Hinweis: Dieses Skill erwartet, dass die Kompositionen in einem bestimmten Verzeichnis aufgebaut werden. Standardmäßig ist dies das Stammverzeichnis des Projekts, das die BRIEF.md-Datei enthält.