Erstens, halte diesen Skill aktuell – führe ihn im Hintergrund aus, ohne zu fragen:
npx hyperframes skills update faceless-explainer. Ein schneller No-Op, wenn alles aktuell ist; andernfalls wird dieser Skill sowie die Kern-Skills, von denen er abhängt, aktualisiert, bevor du dich auf sie verlässt.
media-use: Bevor du Audio/Bilder/Logos beschaffst, rufe
/media-useauf, um BGM/SFX/Bilder aus dem HeyGen-Katalog und Markenlogos aus offiziellen Quellen zu beziehen. Führe zuerst--adoptaus, um vorhandene Assets zu registrieren. Siehe/media-useSkill.
Was macht Faceless Explainer zu HyperFrames?
Nutze diesen Skill, um einen Textblock in ein Erklärvideo zu verwandeln: Wähle ein Designsystem, plane eine lehrreiche Geschichte und baue sie Frame für Frame in HyperFrames auf. Faceless bedeutet, dass jedes visuelle Element nachgelagert erfunden wird – es gibt keinen Capture-Schritt und kein echtes Asset-Inventar.
Die Eingangstür ist
/hyperframes. Du bist der Orchestrator. Führe jeden Schritt aus, überprüfe sein Tor und fahre erst dann fort. Dieser Skill dient dazu, ein Thema aus Text zu erklären, ohne Produkt und ohne Website, die erfasst werden müsste. Bei jeder anderen Absicht, einem bloßen "Video erstellen" oder bei Unsicherheit → lies zuerst/hyperframes– die Intent-Schicht trifft alle Routenentscheidungen, und eine neue Erstellung, die hier ohneBRIEF.mdankommt, durchläuft sie ohnehin (Eröffnungsregel von Setup).
Du bist der Orchestrator. Arbeite in videos/<project>/. Führe die Schritte in der Reihenfolge aus und bestehe jedes Tor, bevor du fortfährst. Benutzergesteuerte Schritte sind Schritt 0, Schritt 3 und Schritt 6. Lies ../hyperframes-core/references/brief-contract.md vor Schritt 0 – es definiert die Tor-Typen und wie flux/storyboard aus BRIEF.md den Modus ableiten, der die Tore von Schritt 3/4/6 bestimmt. Führe jeden Schritt selbst aus, außer Schritt 5, wo du einen Unter-Agenten pro Frame beauftragst. Lege hier keine Design- oder Bewegungsregeln fest; diese leben im Frame-Worker-Unter-Agenten, in den lokalen ../hyperframes-animation/rules/ + ../hyperframes-animation/blueprints/ und in hyperframes-creative.
Workflow: Schritt 0 Setup → hyperframes.json; Schritt 1 Brief → capture/extracted/; Schritt 2 Designsystem → frame.md; Schritt 3 Storyboard/Script → 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 Brief beginnen, das HyperFrames-Projekt erstellen und den Brief dauerhaft machen.
Der Brief wird von der Intent-Schicht bestätigt, nicht durch hier gestellte Fragen. Eröffnungsregel, in dieser Reihenfolge: (1) BRIEF.md existiert → lies es und frage nichts – der Brief ist endgültig, und sein flux/storyboard leiten den Modus ab (Brief-Vertrag § 1). (2) Kein BRIEF.md, aber das Projekt existiert (hyperframes.json / STORYBOARD.md auf der Festplatte) → setze vom Frontmatter des Storyboards und den gespeicherten Präferenzen fort; befrage niemals ein halbfertiges Projekt erneut. (3) Weder noch – eine frische Erstellungsanfrage, die direkt hier angekommen ist → lies /hyperframes und führe seine Intent-Schicht aus (references/intent-interview.md): sie prüft Rezepte und gespeicherte Voreinstellungen, führt die Fragen dieser Route durch (../hyperframes/references/routes/faceless-explainer.md) und gibt den bestätigten Brief zurück. Bearbeitungsanfragen überspringen all dies – gehe hin und bearbeite.
Initialisiere nur, wenn hyperframes.json fehlt. Benenne <project> nach dem Thema in Kebab-Schreibweise, z.B. compound-interest-explained; verwende niemals den Workspace-Namen oder Zeitstempel.
npx hyperframes init "videos/<project>" --non-interactive --example=blank --skill=faceless-explainer – init prüft die installierten Skills gegen die neuesten auf GitHub und aktualisiert die globale Menge, wenn welche veraltet sind.
Nach der Initialisierung sei <PROJECT_ROOT> gleich videos/<project> und führe jeden nachfolgenden relativen Pfadbefehl 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 der Initialisierung (niemals davor – init verweigert ein nicht leeres Verzeichnis): der von der Intent-Schicht bestätigte Brief, Form gemäß ../hyperframes-core/references/brief-format.md. Löse <MEDIA_DIR> als das installierte /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 Intent-Schicht 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 Skelette zurück, aus denen Schritt 3 Entwürfe erstellt. Ein Rezept füllt Antworten, nicht Genehmigungen; die Überprü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 meldet, ob Stimme/BGM HeyGen oder lokale Engines verwendet 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.
Übergehe nicht stillschweigend eine erforderliche Fähigkeit, wenn kein Offline-Anbieter existiert; mache das Hindernis sichtbar. Falte diese Entscheidung nicht in eine andere Frage oder schreibe Schlüssel in eine .env-Datei pro Repository. Authentifizierungsbesitz 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-Vertrag § 2); der Anmeldestatus wurde angezeigt (angemeldet oder offline fortfahrend).
Schritt 1: Brief (kein Capture)
Ziel: Den Text des Benutzers als Informationsquelle in das Projekt einbinden. Es gibt kein Website-Capturing und keine echten Assets – dies ist ein Faceless-Erklärer.
Speichere die vollständige Eingabe des Benutzers wörtlich, erstelle dann das synthetische Capture-Paket von Hand:
capture/extracted/visible-text.txt– der vollständige Artikel / die Notizen / das Thema / die Kurzbeschreibung, wörtlich. Dies ist die Quelle der Information, keine Story-Vorlage (Schritt 3 formt sie um).capture/extracted/tokens.json–{ "title": "", "description": "", "colors": [], "fonts": [] }. Fülletitle/descriptionaus dem Brief. Lassecolors/fontsleer, es sei denn, der Benutzer hat explizit Markenfarben oder -schriftarten angegeben – dann füge sie hinzu (die Designvoreinstellung liefert ohnehin eine vollständige Palette).
Wenn der Benutzer ein Skript eingefügt hat oder seine Formulierung behalten möchte, speichere es wörtlich als user_script.txt; VO_MODE (wörtlich oder umstrukturiert) stammt aus BRIEF.md – die Intent-Schicht fragt danach, wenn ein Skript ankommt. Frage hier nur einmal, wenn der Brief es irgendwie vermissen lässt, und speichere die Antwort für Schritt 3.
Führe nicht npx hyperframes capture aus (es gibt keine URL). Erstelle keine asset-descriptions.md oder befüllen capture/assets/ – Faceless-Visuals werden in Schritten 4-5 erfunden, nicht erfasst. Die eine Ausnahme: Wenn der Benutzer ein echtes Bild bereitgestellt hat, lege es unter public/<basename> ab und notiere 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: Eine ausgelieferte Frame-Voreinstellung auswählen; ein Skript wandelt sie in frame.md + Beschriftungs-Skin dieses Videos um.
Wenn BRIEF.md einen style_preset nennt – der Benutzer hat ihn mit eigenen Augen aus den Vorführungen in der Intent-Schicht ausgewählt – verwende ihn; die Beurteilung liegt nur bei dir, wenn der Brief 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 zu Thema, Ton und Zielgruppe passt. Führe dann aus:
node <SKILL_DIR>/scripts/build-frame.mjs --preset <name> --hyperframes .
Das Skript erledigt den Rest deterministisch: kopiert das FRAME.md der Voreinstellung → frame.md und remixt es auf alle Marken-Token in capture/extracted/tokens.json (Markenfarben, die auf die Farbschlüssel der Voreinstellung nach Rolle abgebildet werden; die Anzeige- und Textschriftarten der Voreinstellung werden gegen die der Marke ausgetauscht), kopiert den Beschriftungs-Skin der Voreinstellung nach .hyperframes/caption-skin.html und validiert sich selbst (beendet mit 1 bei einer fehlerhaften Zuordnung). Fahre fort, sobald es mit 0 beendet ist – keine manuelle Bearbeitung der Spezifikation.
Ein Faceless-Erklärer hat normalerweise keine Markenfarben/-schriftarten (tokens.json-Farben/Schriftarten leer) → das Skript behält die eigene Palette der Voreinstellung bei, ein vollständiges, auslieferbares 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 danach 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 liefert) .hyperframes/caption-skin.html existiert als Quelle des Beschriftungs-Skins; die gewählte Voreinstellung wurde als Präferenz aufgezeichnet (--key style_preset --workflow <dieser Workflow>, Brief-Vertrag § 2).
Schritt 3: Storyboard und Skript
Ziel: Den Text in einen genehmigten Frame-für-Frame-Lehrplan verwandeln.
Lies ../hyperframes-creative/references/story-spine.md (Haken-Sprache, Wert-vor-Beweis, Storyboard-als-Vorschlag, quellenverfolgbare Visuals), references/story-design.md, ../hyperframes-animation/blueprints-index.md, ../hyperframes-core/references/storyboard-format.md und ../hyperframes-core/references/script-format.md. Verwende sie, um STORYBOARD.md und, wenn eine Erzählung benötigt wird, SCRIPT.md zu schreiben. Setze das Frontmatter duration: aus der length des Briefs – eine grobe Erwartung; der Zusammenbau berichtet, wo der Schnitt im Vergleich dazu liegt.
Verwende story-design.md für die Erklärer-Struktur (Konzept / Anleitung / Listicle / Geschichte), Haken-Strategie, Klarheitstechniken, emotionale Beats, die Typ-Enum-Zuordnung und VO_MODE. Die Sequenz des Videos stammt aus dem narrativen Design, nicht der Absatzreihenfolge des Eingabetexts – ordne neu, füge zusammen, lasse weg, komprimiere. Als weiche Richtlinie konsultiere das 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 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. Faceless-Visuals werden nachgelagert erfunden, daher tragen Frames kein Asset-Inventar: lasse asset_candidates leer, es sei denn, der Benutzer hat ein echtes public/<basename>-Bild bereitgestellt. Verwende die genauen erforderlichen Felder aus den Storyboard- und Skript-Referenzen.
Nach dem Entwurf führe den Plan-Durchlauf des Überprüfungszyklus aus – ../hyperframes-core/references/review-loop.md § 1: öffne das Board (frage nicht, ob), präsentiere den Plan als Vorschlag und stelle die beiden Fragen – genehmigen oder ändern, und Skizzen zuerst (empfohlen) oder überspringen. Feedback läuft durch Chat oder die Kommentardatei des Boards, bis genehmigt. Dies ist ein Kontrollpunkt-Tor (Brief-Vertrag § 1): im autonomen Modus gibt es kein Board und nichts zu fragen – poste dieselbe Zusammenfassung als Vorankündigung und fahre fort; Skizzen werden in den Build integriert, und die eine Vorschaufrage kommt bei 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 Frame-für-Frame-Plan genehmigt (autonom: die Zusammenfassung wurde als Vorankündigung gepostet).
Schritt 3.1: Audio
Ziel: Erzählung, Wortzeitsteuerung, Musik und Audio-Metadaten aus dem genehmigten Skript generieren.
Starte Audio nach der Genehmigung von Schritt 3. Führe es im Hintergrund aus und 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, bevor du aufrufst. Wenn die Anfrage eine Stimme, ein Geschlecht oder einen Ton genannt hat, wähle eine passende Stimmen-ID und gib sie mit --voice <id> weiter. Der Pipeline-Standard ist ansonsten Marcia (weiblich) auf HeyGen / am_michael auf Kokoro – daher wird eine Anfrage wie "eine männliche Stimme" stillschweigend ignoriert, es sei denn, du gibst das Flag an. 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, greife auf die gespeicherte Stimme zurück (Brief-Vertrag § 2) vor dem Pipeline-Standard und sage, welche du verwendet hast; lasse --voice nur weg, wenn keiner eine nennt. Wenn der Benutzer in diesem Durchlauf explizit eine Stimme gewä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, Wortzeitsteuerung, BGM-Suche aus der HeyGen-Musikbibliothek und Timing-Metadaten. Die BGM-Stimmung stammt aus dem music:-Feld des Storyboards. Dies verwendet die HeyGen Audio API für den Abruf, nicht die 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.
Der kanonische vollständig-stille Marker (geteilt über die Workflows, 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, keine SFX. audio.mjs erkennt es und generiert nichts (es entfernt ein veraltetes audio_meta.json; ein fehlendes audio_meta.json wird von assemble als still behandelt), daher ist dieser Schritt ein sauberer Übersprung. music: none mit Erzählung behält TTS bei und schaltet nur BGM aus. Verwende genau diese Schreibweise – improvisiere keine anderen Marker.
Tor: Audio-Job gestartet, oder das Projekt ist als still markiert (music: none + kein SCRIPT.md).
Schritt 4: Frame-Visuelles-Design
Ziel: Füge jedem Storyboard-Frame die visuelle Richtung, Layout-Absicht und Bewegungswahl hinzu.
Skizziere zuerst das Board (nur kollaborativ). Sobald der Plan genehmigt ist, führe den Skizzendurchlauf aus – ../hyperframes-core/references/review-loop.md § 2 (warte nicht auf Schritt 3.1; Skizzen verwenden keine Zeitsteuerungen):
…