Plugin-Installationen: Bevor Setup- oder Aktualisierungsbefehle ausgeführt werden, befolge die Plugin-Ausführungsregeln, wenn sich dieser Skill innerhalb eines HyperFrames-Plugins befindet. Bei eigenständigen Installationen behalten die folgenden Aktualisierungsanweisungen ihre Gültigkeit.
Halte diesen Skill zuerst aktuell – bestätige mit dem Benutzer, bevor du Folgendes ausführst:
npx hyperframes skills update faceless-explainer. Eine schnelle No-Op, wenn alles aktuell ist; andernfalls wird dieser Skill zusammen mit den von ihm abhängigen Kern-Domain-Skills aktualisiert, bevor du sie verwendest.
media-use: Bevor du Audio/Bilder/Logos beschaffst, rufe
/media-useauf, um BGM/SFX/Bilder aus dem HeyGen-Katalog und Markenlogos aus ihren offiziellen Quellen zu beziehen. Führe zuerst--adoptaus, um vorhandene Assets zu registrieren. Siehe/media-useSkill.
Faceless Explainer zu HyperFrames
Verwende diesen Skill, um einen Textkörper in ein erklärendes Video zu verwandeln: Wähle ein Designsystem aus, plane eine Lehrgeschichte und baue sie Bild für Bild in HyperFrames auf. Faceless bedeutet, dass jedes visuelle Element nachgelagert erfunden wird – es gibt keinen Erfassungsschritt und kein Inventar an echten Assets.
Die erste Anlaufstelle ist
/hyperframes. Du bist der Orchestrator. Führe jeden Schritt aus, überprüfe sein Tor und fahre nur dann fort. Dieser Skill dient zur Erklärung eines Themas aus einem Text, ohne Produkt und ohne Website, die erfasst werden muss. Bei jeder anderen Absicht, einem bloßen „Video erstellen" oder bei Unklarheit → lies zuerst/hyperframes– die Absichts-Ebene besitzt jede Routenentscheidung, und eine neue Erstellung, die ohneBRIEF.mdhier ankommt, durchläuft sie ohnehin (Einstiegsregel von Setup).
Du bist der Orchestrator. Arbeite in videos/<projekt>/. Führe die Schritte nacheinander aus und bestehe jedes Tor, bevor du fortfährst. Benutzergesteuerte Schritte sind Schritt 0, Schritt 3 und Schritt 6. Lies ../hyperframes/references/brief-contract.md vor Schritt 0 – es definiert die Tortypen und wie BRIEF.md's flow/storyboard den Modus ableiten, der die Tore von Schritt 3/4/6 regelt. Führe jeden Schritt selbst aus, außer Schritt 5, wo du einen Unter-Agenten pro Frame entsendest. Lege hier keine Design- oder Bewegungsregeln fest; diese leben im Frame-Worker-Unter-Agenten, in den lokalen ../hyperframes-animation/rules/ + ../hyperframes-animation/blueprints/ und hyperframes-creative.
Workflow: Schritt 0 Setup → hyperframes.json; Schritt 1 Briefing → capture/extracted/; Schritt 2 Designsystem → frame.md; Schritt 3 Storyboard/Drehbuch → STORYBOARD.md und SCRIPT.md; Schritt 3.1 Audio → audio_meta.json; Schritt 4 Visuelles Design → angereichertes STORYBOARD.md; Schritt 5 Frames → compositions/frames/NN-*.html und index.html; Schritt 6 Finaler Render → renders/video.mp4.
Schritt 0: Setup
Ziel: Mit einem bestätigten Briefing beginnen, das HyperFrames-Projekt erstellen und das Briefing dauerhaft machen.
Das Briefing wird von der Absichts-Ebene bestätigt, nicht durch hier gestellte Fragen. Einstiegsregel, in der Reihenfolge: (1) BRIEF.md existiert → lies es und frage nichts – das Briefing ist abgeschlossen, und sein flow/storyboard leiten den Modus ab (Brief-Contract § 1). (2) Kein BRIEF.md, aber das Projekt existiert (hyperframes.json / STORYBOARD.md auf der Festplatte) → nimm ab dem Frontmatter des Storyboards und den aufgezeichneten Präferenzen wieder auf; befrage nie ein halb erstelltes Projekt erneut. (3) Weder noch – eine frische Erstellungsanfrage, die direkt hier ankam → lies /hyperframes und führe seine Absichts-Ebene aus (references/intent-interview.md): es prüft Rezepte und gespeicherte Standardeinstellungen, führt die Fragen dieser Route durch (../hyperframes/references/routes/faceless-explainer.md) und gibt das gesperrte Briefing zurück. Bearbeitungsanfragen überspringen dies alles – führe die Bearbeitung durch.
Initialisiere nur, wenn hyperframes.json fehlt. Benenne <projekt> aus dem Thema in Kebab-Schreibweise, z. B. compound-interest-explained; verwende niemals den Arbeitsbereichsnamen oder einen Zeitstempel.
npx hyperframes init "videos/<projekt>" --non-interactive --example=blank --skill=faceless-explainer – init prüft die installierten Skills gegen die neuesten auf GitHub und aktualisiert den globalen Satz, wenn einer veraltet ist.
Nach der Initialisierung setze <PROJECT_ROOT> auf videos/<projekt> und führe jeden nachfolgenden Befehl mit relativem Pfad mit diesem Verzeichnis als Arbeitsverzeichnis aus. In den folgenden Befehlen bedeutet . <PROJECT_ROOT>; schreibe niemals .media, capture oder Ausgabedateien in das Aufruferverzeichnis.
Schreibe BRIEF.md sofort nach init (niemals davor – init lehnt ein nicht leeres Verzeichnis ab): das gesperrte Briefing der Absichts-Ebene, Form gemäß ../hyperframes/references/brief-format.md. Löse <MEDIA_DIR> als installiertes /media-use Skill-Verzeichnis auf. Zeichne dann jede präferenzgestützte Antwort mit node <MEDIA_DIR>/scripts/prefs.mjs record --hyperframes . auf (brief-format.md benennt die Teilmenge). Wenn die Absichts-Ebene ein Rezept übernommen hat, führe node <MEDIA_DIR>/scripts/recipe.mjs use --hyperframes . --name <name> aus; es kopiert sein frame.md in das Projekt (Schritt 2 wird dann übersprungen) und gibt die Gerüste zurück, von denen aus Schritt 3 entworfen wird. Ein Rezept füllt Antworten, nicht Genehmigungen; die Prüfungstore laufen trotzdem.
Zeige den Anmeldestatus an, bevor du über Setup hinausgehst – führe npx hyperframes auth status aus und gib seine Ausgabe wörtlich weiter. Es gibt an, ob Sprachausgabe/BGM die HeyGen- oder lokale Engines verwenden wird und, wenn abgemeldet, wie man sich anmeldet. Wende einen Zweig an:
- Kollaborativ: Warte, bis der Benutzer sich anmeldet oder explizit
offline/gowählt. - Autonom: Gib den Status an und fahre mit den verfügbaren lokalen Engines fort.
Verschweige nicht stillschweigend eine erforderliche Fähigkeit, wenn kein Offline-Anbieter existiert; hebe das Hindernis hervor. Verpacke diese Entscheidung nicht in eine andere Frage und schreibe keine Schlüssel in ein repobezogenes .env. Eigentum an der Authentifizierung und Offline-Fallbacks: /media-use references/setup-providers.md § Anbieter.
Tor: hyperframes.json und BRIEF.md existieren; die präferenzgestützten Antworten wurden aufgezeichnet (Brief-Contract § 2); der Anmeldestatus wurde angezeigt (angemeldet oder Fortsetzung offline).
Schritt 1: Briefing (keine Erfassung)
Ziel: Den Text des Benutzers als Informationsquelle in das Projekt einbinden. Es gibt keine Website-Erfassung und keine echten Assets – dies ist ein Faceless Explainer.
Speichere die vollständige Eingabe des Benutzers wörtlich und erstelle dann das synthetische Erfassungspaket von Hand:
capture/extracted/visible-text.txt– der vollständige Artikel / die Notizen / das Thema / das Briefing, wörtlich. Dies ist die Informationsquelle, nicht eine Story-Vorlage (Schritt 3 formt sie um).capture/extracted/tokens.json–{ "title": "", "description": "", "colors": [], "fonts": [] }. Fülletitle/descriptionaus dem Briefing. Lassecolors/fontsleer, es sei denn, der Benutzer hat explizit Markenfarben oder -schriftarten angegeben – dann füge sie hinzu (die Design-Voreinstellung liefert unabhängig davon eine vollständige Palette).
Wenn der Benutzer ein Drehbuch eingefügt hat oder seine Formulierung erhalten möchte, speichere es wörtlich als user_script.txt; VO_MODE (wörtlich oder umstrukturiert) stammt aus BRIEF.md – die Absichts-Ebene fragt danach, wenn ein Drehbuch ankommt. Frage hier nur einmal, wenn das Briefing es irgendwie nicht enthält, und speichere die Antwort für Schritt 3.
Führe nicht npx hyperframes capture aus (es gibt keine URL). Erstelle kein asset-descriptions.md und belege kein capture/assets/ – gesichtslose Bilder werden in den Schritten 4-5 erfunden, nicht erfasst. Die einzige Ausnahme: Wenn der Benutzer ein echtes Bild bereitgestellt hat, lege es unter public/<basisname> ab und vermerke es für Schritt 3.
Tor: capture/extracted/visible-text.txt und capture/extracted/tokens.json existieren; du kannst das Thema und die Zielgruppe des Erklärers in einem klaren Satz angeben.
Schritt 2: Designsystem
Ziel: Wähle eine ausgelieferte Frame-Voreinstellung aus; ein Skript wandelt sie in das frame.md + Untertitel-Skin dieses Videos um.
Wenn BRIEF.md eine style_preset nennt – der Benutzer hat sie per Augenschein aus den Showcases auf der Absichts-Ebene ausgewählt – verwende sie; die Beurteilung liegt nur dann bei dir, wenn das Briefing schweigt. Dann triffst du die eine Entscheidung – welche Voreinstellung: lies ../hyperframes-creative/references/design-spec.md und durchsuche ../hyperframes-creative/frame-presets/; wähle die Voreinstellung, deren Look am besten zum Thema, Ton und Publikum passt. Führe dann aus:
node <SKILL_DIR>/scripts/build-frame.mjs --preset <name> --hyperframes .
Das Skript erledigt den Rest deterministisch: es kopiert das FRAME.md der Voreinstellung → frame.md und remixt es mit allen Markentoken in capture/extracted/tokens.json (Markenfarben werden nach Rolle auf die Farbschlüssel der Voreinstellung abgebildet; die Anzeige- und Text-Schriftarten der Voreinstellung werden gegen die der Marke ausgetauscht), kopiert den Untertitel-Skin der Voreinstellung nach .hyperframes/caption-skin.html und validiert sich selbst (beendet mit 1 bei einer defekten Zuordnung). Fahre fort, sobald es mit 0 beendet ist – keine manuelle Bearbeitung der Spezifikation.
Ein Faceless Explainer hat normalerweise keine Markenfarben/-schriftarten (tokens.json colors/fonts leer) → das Skript behält die eigene Palette der Voreinstellung, ein vollständiges versandfähiges Design. Nur wenn der Benutzer Markenfarben/-schriftarten genannt hat, füge sie vor der Ausführung zu tokens.json hinzu, und passe frame.md nur dann von Hand an, wenn eine Zuordnung es wirklich erfordert.
Tor: build-frame.mjs wurde mit 0 beendet – frame.md existiert von einer benannten Voreinstellung, und (wenn die Voreinstellung eine ausliefert) .hyperframes/caption-skin.html existiert als Untertitel-Skin-Quelle; die gewählte Voreinstellung wurde als Präferenz aufgezeichnet (--key style_preset --workflow <this workflow>, Brief-Contract § 2).
Schritt 3: Storyboard und Drehbuch
Ziel: Den Text in einen genehmigten, bildweisen Lehrplan verwandeln.
Lies ../hyperframes-creative/references/story-spine.md (Haken-Sprache, Wert-vor-Beweis, Storyboard-als-Vorschlag, quellrückverfolgbare Bilder), references/story-design.md, ../hyperframes-animation/blueprints-index.md, ../hyperframes/references/storyboard-format.md und ../hyperframes/references/script-format.md. Verwende sie, um STORYBOARD.md und, wenn eine Erzählung benötigt wird, SCRIPT.md zu schreiben. Setze die duration: im Frontmatter aus der length des Briefings – eine grobe Erwartung; die Zusammenstellung berichtet, wo der Schnitt im Vergleich dazu landet.
Verwende story-design.md für die Erklärer-Struktur (Konzept / Anleitung / Liste / Geschichte), Haken-Strategie, Klarheitstechniken, emotionale Schläge, die Typ-Enum-Zuordnung und VO_MODE. Die Abfolge des Videos ergibt sich aus dem narrativen Design, nicht aus der Absatzreihenfolge des Eingabetextes – ordne neu, füge zusammen, lasse weg, komprimiere. Als weiche Richtlinie konsultiere die Rollen→Blueprint-Menü in ../hyperframes-animation/blueprints-index.md: Schreibe für jeden Beat den Voiceover in der Form, die sein Kandidaten-Blueprint impliziert, und tagge diesen Kandidaten mit der blueprint:-ID, wenn einer passt. Die Lehrwahrheit entscheidet immer noch, welche Beats existieren – erzwinge niemals einen Beat, um in einen Blueprint zu passen, und erfinde niemals einen Beat, nur weil eine bewährte Form verfügbar ist. Da gesichtslose Bilder nachgelagert erfunden werden, führen Frames kein Asset-Inventar: Lasse asset_candidates leer, es sei denn, der Benutzer hat ein echtes public/<basisname>-Bild bereitgestellt. Verwende die genauen erforderlichen Felder aus den Storyboard- und Drehbuch-Referenzen.
Nach dem Entwurf führe den Plan-Durchlauf des Prüfzyklus durch – ../hyperframes/references/review-loop.md § 1: präsentiere den Plan als Vorschlag und stelle die beiden Fragen – genehmigen oder ändern, und zuerst Skizzen (empfohlen) oder überspringen. Feedback kommt als Chat-Antwort; wiederhole, bis genehmigt. Dies ist ein Kontrollpunkt-Tor (Brief-Contract § 1): Im autonomen Modus gibt es nichts zu fragen – poste dieselbe Zusammenfassung als Vorankündigung und fahre fort; Skizzen fallen in den Bau, und die eine Vorschaufrage kommt in Schritt 6.
Tor: STORYBOARD.md existiert, jeder Frame hat die erforderlichen narrativen Felder, SCRIPT.md existiert, wenn eine Erzählung benötigt wird, und der Benutzer hat den bildweisen Plan genehmigt (autonom: die Zusammenfassung wurde als Vorankündigung gepostet).
Schritt 3.1: Audio
Ziel: Erzählung, Wortzeiten, Musik und Audio-Metadaten aus dem genehmigten Drehbuch generieren.
Starte Audio nach der Genehmigung von Schritt 3. Führe es im Hintergrund aus, fahre dann mit Schritt 4 fort. (Der Anmeldestatus wurde bereits in Schritt 0 angezeigt; die Engine fällt automatisch zurück.)
Wähle die Erzählstimme aus der Anfrage des Benutzers aus, bevor du sie aufrufst. Wenn die Anfrage eine Stimme, ein Geschlecht oder einen Ton genannt hat, wähle eine passende Stimmen-ID und übergebe sie mit --voice <id>. Die Pipeline-Voreinstellung ist ansonsten Marcia (weiblich) auf HeyGen / am_michael auf Kokoro – eine Anfrage wie „eine männliche Stimme“ wird also stillschweigend ignoriert, es sei denn, du übergibst das Flag. Stimmen-IDs sind anbieterspezifisch; löse sie gegen den Anbieter auf, den der Anmeldestatus von Schritt 0 ausgewählt hat: HeyGen (angemeldet) über node <MEDIA_DIR>/audio/scripts/heygen-tts.mjs --list (oder GET /v3/voices?engine=starfish); Kokoro (offline) über die Stimmentabelle in <MEDIA_DIR>/audio/references/tts.md (Präfixe am_/bm_ männlich, af_/bf_ weiblich). Wenn der Benutzer keine Präferenz geäußert hat, falle auf die gespeicherte Stimme zurück (Brief-Contract § 2), bevor die Pipeline-Voreinstellung verwendet wird, und sage, welche du verwendet hast; lasse --voice nur weg, wenn keiner eine nennt. Wenn der Benutzer in diesem Durchlauf explizit eine Stimme ausgewählt hat, zeichne sie auf (prefs.mjs record --key voice).
node <SKILL_DIR>/scripts/audio.mjs --script ./SCRIPT.md --storyboard ./STORYBOARD.md --hyperframes . --out ./audio_meta.json --voice <voice-id> &
Das Audio-Skript kümmert sich um Erzählung, Wortzeiten, BGM-Suche aus der HeyGen-Musikbibliothek und Timing-Metadaten. Die BGM-Stimmung stammt aus dem music:-Feld des Storyboards. Es verwendet die HeyGen-Audio-API zum Abruf, nicht zur Generierung, und dieselbe ~/.heygen-Anmeldeinformation wie TTS. Für Anbieterdetails lies ../media-use/audio/references/tts.md.
Wenn es keine Erzählung und kein SCRIPT.md gibt, überspringe die Sprachgenerierung. BGM kann trotzdem laufen, wenn das Storyboard eine Musikstimmung hat.
Die kanonische vollständig stille Markierung (von den Workflows gemeinsam genutzt, die dieses Audiomodell wiederverwenden): music: none im oberen YAML-Block von STORYBOARD.md und kein SCRIPT.md. Diese Kombination markiert das Projekt als still – keine Erzählung, kein BGM, kein SFX. audio.mjs erkennt es und generiert nichts (es entfernt eine veraltete audio_meta.json; eine fehlende audio_meta.json wird von Zusammenstellung als still behandelt), sodass dieser Schritt sauber übersprungen wird. music: none mit Erzählung behält TTS und schaltet nur BGM aus. Verwende genau diese Schreibweise – improvisiere keine anderen Markierungen.
Tor: Der Audio-Job wurde gestartet, oder das Projekt ist als still markiert (music: none + kein SCRIPT.md).
Schritt 4: Visuelles Framedesign
Ziel: Füge jedem Storyboard-Frame die visuelle Richtung, Layout-Absicht und Bewegungsentscheidungen hinzu.
**Skizziere zuerst das Storyboard-Blatt (kollaborativ) oder überspringe es (autonom) – dann elasticity_id}.