Plugin-Installationen: Bevor Sie Setup- oder Aktualisierungsbefehle ausführen, befolgen Sie die Plugin-Ausführungsregeln, wenn sich dieses Skill in einem HyperFrames-Plugin befindet. Bei eigenständigen Installationen gelten die Aktualisierungshinweise unten.
Halten Sie dieses Skill zuerst aktuell – bestätigen Sie mit dem Benutzer, bevor Sie es ausführen:
npx hyperframes skills update pr-to-video. Ein schneller No-op, wenn alles auf dem neuesten Stand ist; andernfalls aktualisiert es dieses Skill sowie die Kern-Domain-Skills, von denen es abhängt, bevor Sie sich auf sie verlassen.
media-use: Bevor Sie Audio/Bilder/Logos beschaffen, rufen Sie
/media-useauf, um BGM/SFX/Bilder aus dem HeyGen-Katalog und Markenlogos aus offiziellen Quellen zu beziehen. Führen Sie zuerst--adoptaus, um vorhandene Assets zu registrieren. Siehe/media-useSkill.
PR zu HyperFrames
Verwenden Sie dieses Skill, um einen GitHub-Pull-Request aufzunehmen, die Änderung zu verstehen, ein Erklärvideo für Code-Änderungen zu planen und es Frame für Frame in HyperFrames zu erstellen. Die Eingabe ist eine Code-Änderung (über gh gelesen), keine Website – es gibt keinen Erfassungsschritt und keine echten Assets außer den Avataren der Beitragenden.
Der Einstieg ist
/hyperframes. Sie sind der Orchestrator. Führen Sie jeden Schritt aus, überprüfen Sie dessen Tor, und fahren Sie erst dann fort. Dieses Skill ist für einen GitHub-Pull-Request (eine Code-Änderung). Bei jeder anderen Absicht, einem bloßen "Video erstellen" oder bei Unsicherheit → lesen Sie zuerst/hyperframes– die Absichtsebene besitzt jede Routenentscheidung, und eine neue Erstellung, die hier ohneBRIEF.mdankommt, durchläuft sie trotzdem (Setup's Eröffnungsregel).
Sie sind der Orchestrator. Arbeiten Sie im aufgelösten externen PROJECT_DIR, niemals standardmäßig im aufrufenden Repository. Führen Sie die Schritte in der Reihenfolge aus und passieren Sie jedes Tor, bevor Sie fortfahren. Benutzergesteuerte Schritte sind Schritt 0, Schritt 3 und Schritt 6. Lesen Sie ../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ühren Sie jeden Schritt selbst aus, außer Schritt 5, wo Sie einen begrenzten Pool von Frame-Workern entsenden. Legen Sie keine Design- oder Bewegungsregeln hier fest; diese leben im Frame-Worker-Sub-Agent, den lokalen ../hyperframes-animation/rules/ + ../hyperframes-animation/blueprints/ und hyperframes-creative dieses Skills.
Workflow: Schritt 0 Setup → hyperframes.json; Schritt 1 Erfassung → capture/extracted/ + assets/<login>.png; Schritt 2 Designsystem → frame.md; Schritt 3 Storyboard/Skript → STORYBOARD.md und SCRIPT.md; Schritt 3.1 Audio → audio_meta.json; Schritt 4 Visuelles Design → erweitertes 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 eintreten – einschließlich der PR-Referenz (eine vollständige URL, eine <owner>/<repo>#<N>-Referenz oder "diesen PR" in einem ausgecheckten Repository) – das HyperFrames-Projekt erstellen und den Brief dauerhaft machen. Der Stil ist immer code-editorial (in Schritt 2 festgelegt, nie gefragt).
Der Brief wird von der Absichtsebene bestätigt, nicht durch hier gestellte Fragen. Eröffnungsregel, in dieser Reihenfolge: (1) BRIEF.md existiert → lesen und nichts fragen – der Brief ist abgeschlossen, und sein flow/storyboard leiten den Modus ab (Briefvertrag § 1). (2) Kein BRIEF.md, aber das Projekt existiert (hyperframes.json / STORYBOARD.md auf der Festplatte) → vom Frontmatter des Storyboards und den aufgezeichneten Präferenzen fortsetzen; ein halb fertiges Projekt niemals erneut befragen. (3) Keines von beidem – eine frische Erstellungsanfrage, die hier direkt ankommt → /hyperframes lesen und dessen Absichtsebene ausführen (references/intent-interview.md): es prüft Rezepte und gespeicherte Standardeinstellungen und führt die Fragen dieser Route durch – einschließlich der PR-Größe → Längen-Doktrin, die vollständig in ../hyperframes/references/routes/pr-to-video.md lebt – und gibt dann den gesperrten Brief zurück. Bearbeitungsanfragen überspringen all dies – gehen Sie zur Bearbeitung.
Lösen Sie das Projektverzeichnis auf, bevor Sie andere Arbeiten ausführen. Bewahren Sie ein vom Benutzer angegebenes Projektverzeichnis; verwenden Sie andernfalls den dauerhaften externen Cache-Speicherort, der vom Resolver ausgegeben wird. Erstellen Sie niemals videos/ im aufrufenden Repository:
PR="<url | owner/repo#N>"
if [ -n "${EXPLICIT_PROJECT_DIR:-}" ]; then
PROJECT_DIR="$(node <SKILL_DIR>/scripts/project-dir.mjs --pr "$PR" --project-dir "$EXPLICIT_PROJECT_DIR")"
else
PROJECT_DIR="$(node <SKILL_DIR>/scripts/project-dir.mjs --pr "$PR")"
fi
echo "PR-to-video project: $PROJECT_DIR"
node <SKILL_DIR>/scripts/preflight.mjs
Die Capability-Überprüfung läuft vor dem Abruf, der Story-Arbeit, dem Audio oder der Frame-Verteilung. Wenn die installierte CLI den von diesem Skill benötigten Validierungsbefehl nicht ausführen kann, stoppen Sie mit dessen Upgrade-Anweisung, anstatt den Kontext des Laufs zuerst zu verbrauchen.
Initialisieren Sie nur, wenn $PROJECT_DIR/hyperframes.json fehlt. Sein Basisname stammt vom PR, z.B. acme-sdk-pr-1842; verwenden Sie niemals den Workspace-Namen oder einen Zeitstempel.
npx hyperframes init "$PROJECT_DIR" --non-interactive --example=blank --skill=pr-to-video – init prüft die installierten Skills gegen die neuesten auf GitHub und aktualisiert den globalen Satz, falls welche veraltet sind.
Jeder relative Pfadbefehl unten wird mit $PROJECT_DIR als Arbeitsverzeichnis ausgeführt. Beispiele ohne explizite Subshell bedeuten (cd "$PROJECT_DIR" && …); ändern Sie niemals den Arbeitsbaum des aufrufenden Repositorys.
Schreiben Sie BRIEF.md unmittelbar nach dem Init (niemals davor – init lehnt ein nicht leeres Verzeichnis ab): der gesperrte Brief der Absichtsebene, Form gemäß ../hyperframes/references/brief-format.md. Lösen Sie <MEDIA_DIR> als das installierte /media-use Skill-Verzeichnis auf. Zeichnen Sie dann jede präferenzgestützte Antwort mit node <MEDIA_DIR>/scripts/prefs.mjs record --hyperframes . auf (brief-format.md benennt die Teilmenge). Wenn die Absichtsebene ein Rezept übernommen hat, führen Sie 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, von denen Schritt 3 Entwürfe erstellt. Ein Rezept füllt Antworten, nicht Genehmigungen; die Überprüfungstore laufen trotzdem.
Zeigen Sie den Anmeldestatus an, bevor Sie über das Setup hinausgehen – führen Sie npx hyperframes auth status aus und geben Sie dessen Ausgabe wörtlich weiter. Es meldet, ob Stimme/BGM HeyGen oder lokale Engines verwenden wird und, wenn abgemeldet, wie man sich anmeldet. Wenden Sie eine Verzweigung an:
- Kollaborativ: auf die Anmeldung des Benutzers oder die explizite Wahl von
offline/gowarten. - Autonom: den Status angeben und mit den verfügbaren lokalen Engines fortfahren.
Übergehen Sie nicht stillschweigend eine erforderliche Fähigkeit, wenn kein Offline-Anbieter existiert; machen Sie den Blocker sichtbar. Falten Sie diese Entscheidung nicht in eine andere Frage und schreiben Sie keine Schlüssel in ein repo-spezifisches .env. Authentifizierungsbesitz und Offline-Fallback: /media-use references/setup-providers.md § Anbieter.
Tor: hyperframes.json und BRIEF.md existieren; die PR-Referenz ist im Brief erfasst; die präferenzgestützten Antworten wurden aufgezeichnet (Briefvertrag § 2); der Anmeldestatus wurde angezeigt (angemeldet oder Fortsetzung offline).
Schritt 1: PR erfassen (keine Aufnahme)
Ziel: Die Fakten des PR abrufen und als Informationsquelle in das Projekt einbinden. Es gibt keine Website-Erfassung. fetch-pr.mjs führt gh deterministisch aus – vervollständigt die Dateiliste über paginierte gh api, damit ein großer PR nicht bei ~100 Dateien abgeschnitten wird, und schreibt nur capture/pr.json + capture/diff.patch (kein Scratch-Verzeichnis). Bei ZUSAMMENGEFÜHRTEN PRs wird zusätzlich eine shipped_version (+ version_source) nach bestem Wissen in pr.json aufgelöst, damit die Endkarte eine echte Version angeben kann, anstatt eine zu erfinden. Dann faltet ingest.mjs dies offline in das synthetische Erfassungspaket.
PR="<url | owner/repo#N | N>"
# Den PR deterministisch abrufen: führt gh aus, vervollständigt die Dateiliste über paginierte
# gh api (damit ein großer PR nicht bei ~100 Dateien abgeschnitten wird), schreibt nur capture/pr.json +
# capture/diff.patch — kein Scratch-Verzeichnis. gh auth / not-found / private Fehler beenden mit Exit 1 hier.
(cd "$PROJECT_DIR" && node <SKILL_DIR>/scripts/fetch-pr.mjs --pr "$PR" --out-dir ./capture)
# Offline Transformation → capture/extracted/{tokens.json (colors:[] → code-editorial-Palette),
# visible-text.txt (der Brief), people.json (Mitwirkende, bot-gefiltert, name+login,
# avatarFile=assets/<login>.png)}.
(cd "$PROJECT_DIR" && node <SKILL_DIR>/scripts/ingest.mjs \
--pr-json ./capture/pr.json --diff ./capture/diff.patch --out-dir ./capture/extracted)
# Der eine Netzwerkschritt für die Personen – laden Sie den GitHub-Avatar jedes Mitwirkenden herunter nach
# assets/<login>.png für den Credits-Abspann. Best-Effort; immer mit Exit 0 beenden.
(cd "$PROJECT_DIR" && node <SKILL_DIR>/scripts/fetch-people-avatars.mjs \
--people ./capture/extracted/people.json)
Wenn fetch-pr.mjs mit Exit 1 beendet (gh auth / not found / private), melden Sie seinen stderr und stoppen Sie – erfinden Sie keine PR-Inhalte. Wenn ingest.mjs mit Exit 1 beendet, lesen Sie seinen stderr (meist ein fehlerhaftes pr.json), beheben Sie es und führen Sie es erneut aus (deterministisch). fetch-people-avatars.mjs beendet immer mit Exit 0; fehlende Avatare bedeuten nur, dass es keinen Credits-Abspann für den Autor gibt.
people.json trägt einen name für die Mitwirkenden, die gh bereits benannt hat (der PR-Autor, Commit-Autoren, mergedBy) – null für die restlichen (Reviewer/Kommentatoren/Beauftragte, die gh pr view jemals nur als bloßen login liefert). Bevor Sie den Credits-Abspann in Schritt 3 schreiben, lösen Sie alle null-Namen selbst für die 1-6 Personen auf, die tatsächlich in diesem Frame erscheinen werden: gh api users/<login> --jq .name (Sie haben bereits gh – kein Skript nötig). Wenn GitHub für diesen Benutzer ebenfalls keinen öffentlichen Namen hat, verwenden Sie auf dem Bildschirm den Login als Fallback und entfernen Sie diese Person aus der gesprochenen Zeile (siehe story-design.md Abschnitt Credits – der Voiceover muss dennoch Namen sagen, niemals rohe Handles).
Tor: capture/pr.json, capture/diff.patch, capture/extracted/tokens.json, capture/extracted/visible-text.txt und capture/extracted/people.json existieren; Sie können die Änderung des PR in einem klaren Satz angeben. assets/<login>.png ist Best-Effort – seine Abwesenheit ist kein Fehler.
Schritt 2: Designsystem
Ziel: Den code-editorial Frame-Vorgabesatz übernehmen; ein Skript verwandelt ihn in das frame.md + Caption-Skin dieses Videos.
Der Stil ist festgelegt – code-editorial (warm redaktionell; eine marineblaue Code-Oberfläche, die für Diffs ausgelegt ist). Ausführen:
node <SKILL_DIR>/scripts/build-frame.mjs --preset code-editorial --hyperframes .
Das Skript kopiert den FRAME.md des code-editorial Vorgabesatzes → frame.md, mischt ihn auf alle Markentoken in capture/extracted/tokens.json (ein PR hat keine → colors:[]/fonts:[] behält die eigene Palette von code-editorial, ein vollständiges Design), kopiert das Caption-Skin des Vorgabesatzes nach .hyperframes/caption-skin.html und validiert sich selbst (Exit 1 bei einer defekten Zuordnung). Fahren Sie fort, sobald es mit Exit 0 beendet – keine manuelle Bearbeitung.
Tor: build-frame.mjs mit Exit 0 beendet – frame.md existiert vom code-editorial Vorgabesatz und .hyperframes/caption-skin.html existiert als Caption-Skin-Quelle.
Schritt 3: Storyboard und Skript
Ziel: Den PR in einen genehmigten Frame-für-Frame-Erklärungsplan verwandeln.
Lesen Sie ../hyperframes-creative/references/story-spine.md (Haken-Sprache, Wert-vor-Beweis, Storyboard-als-Vorschlag, quellnachvollziehbare Visualisierungen), references/story-design.md, ../hyperframes-animation/blueprints-index.md, ../hyperframes/references/storyboard-format.md und ../hyperframes/references/script-format.md. Verwenden Sie sie, um STORYBOARD.md und, wenn eine Erzählung erforderlich ist, SCRIPT.md zu schreiben. Setzen Sie die Frontmatter duration: aus dem length des Briefs – eine grobe Erwartung; die Montage berichtet, wo der Schnitt im Vergleich dazu landet.
Verwenden Sie story-design.md für das PR-Archetyp (Changelog / Feature-Reveal / Fix-Explainer / Refactor-Walkthrough), die PR-nativen Frametypen, Haken, Überzeugung, Beats, das Wortbudget pro Frame und den Credits-Abspann. Die Reihenfolge stammt aus dem narrativen Design, nicht der Dateireihenfolge des Diffs – erklären Sie die Änderung, lesen Sie den Diff nicht laut vor. Als weiche Richtlinie konsultieren Sie das Rollen→Blueprint-Menü in ../hyperframes-animation/blueprints-index.md: Schreiben Sie für jeden Beat den Voiceover in der Form, die sein Kandidat-Blueprint impliziert, und taggen Sie diesen Kandidaten mit blueprint: id, wenn einer passt (die Story-Wahrheit entscheidet dennoch, welche Beats existieren – zwingen Sie niemals einen Beat in eine Form). Zeigen Sie 2–4 echte Diff-Hunks (aus capture/diff.patch), jedes ein kleines lesbares Snippet; benennen Sie den code-* Block, den jeder im scene des Frames haben soll. Frames tragen keine asset_candidates außer dem credits-Abschluss (1–6 assets/<login>.png Avatare). Verwenden Sie die genauen erforderlichen Felder aus den Storyboard- und Skript-Referenzen.
Nach dem Entwurf führen Sie die Planungsrunde des Überprüfungszyklus durch – ../hyperframes/references/review-loop.md § 1: präsentieren Sie den Plan als Vorschlag und stellen Sie die beiden Fragen – genehmigen oder ändern, und zuerst Skizzen (empfohlen) oder überspringen. Feedback kommt als Chat-Antwort; wiederholen Sie die Schleife bis zur Genehmigung. Dies ist ein Checkpoint-Tor (Briefvertrag § 1): im autonomen Modus gibt es nichts zu fragen – posten Sie die gleiche Zusammenfassung als Hinweis und fahren Sie fort; Skizzen werden in den Build integriert, 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 erforderlich ist, und der Benutzer hat den Plan genehmigt (autonom: die Zusammenfassung wurde als Hinweis gepostet).
Schritt 3.1: Audio
Ziel: Erzählung, Wortzeitsteuerungen, Musik und Audio-Metadaten aus dem genehmigten Skript generieren.
Starten Sie Audio nach der Genehmigung von Schritt 3. Führen Sie es im Hintergrund aus, fahren Sie dann mit Schritt 4 fort.
Wählen Sie die Erzählstimme aus der Anfrage des Benutzers aus, bevor Sie sie aufrufen. Wenn die Anfrage eine Stimme, ein Geschlecht oder einen Tonfall benannt hat, wählen Sie eine passende Stimm-ID und übergeben Sie sie mit --voice <id>. Die Pipeline-Standardwahl ist ansonsten Marcia (weiblich) auf HeyGen / am_michael auf Kokoro – daher wird eine Anfrage wie "eine männliche Stimme" stillschweigend ignoriert, es sei denn, Sie übergeben das Flag. Stimm-IDs sind anbieterabhängig; lösen Sie 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, fallen Sie auf die gespeicherte Stimme zurück (Briefvertrag § 2), bevor Sie die Pipeline-Standardwahl treffen.