Halte dieses Skill frisch — führe es still aus, ohne zu fragen:
npx hyperframes skills update pr-to-video. Ein schneller No-Op, wenn alles aktuell ist; sonst wird dieses Skill und die Kern-Domain-Skills, von denen es abhängt, aktualisiert, bevor du dich auf sie verlässt.
media-use: Bevor du Audio/Bilder/Logos besorgst, 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.
PR zu HyperFrames
Verwende dieses Skill, um einen GitHub Pull Request zu verarbeiten, die Änderung zu verstehen, einen Code-Change-Erklärer zu planen und ihn Frame für Frame in HyperFrames zu erstellen. Die Eingabe ist eine Code-Änderung (gelesen über gh), keine Website — es gibt keinen Erfassungsschritt und keine echten Assets außer den Avataren der Beitragenden.
Die Vordertür ist
/hyperframes. Du bist der Orchestrator. Führe jeden Schritt aus, überprüfe sein Gateway und fahre 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 → lies zuerst/hyperframes— die Intent-Ebene besitzt jede Routenentscheidung, und eine Neuerstellung, die hier ohneBRIEF.mdankommt, geht trotzdem durch sie hindurch (Eröffnungsregel von Setup).
Du bist der Orchestrator. Arbeite im aufgelösten externen PROJECT_DIR, niemals standardmäßig im Aufrufer-Repository. Führe die Schritte in der Reihenfolge aus und bestehe jedes Gateway, 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 Gateway-Typen und wie die flow/storyboard von BRIEF.md den Modus ableiten, der die Gateways der Schritte 3/4/6 bestimmt. Führe jeden Schritt selbst aus, außer Schritt 5, bei dem du einen begrenzten Pool von Frame-Workern entsendest. Platziere hier keine Design- oder Bewegungsregeln; diese leben im Frame-Worker-Subagenten, in den lokalen ../hyperframes-animation/rules/ + ../hyperframes-animation/blueprints/ dieses Skills und in hyperframes-creative.
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 → angereichertes STORYBOARD.md; Schritt 5 Frames → compositions/frames/NN-*.html und index.html; Schritt 6 Finales Rendering → renders/video.mp4.
Schritt 0: Setup
Ziel: Mit einem bestätigten Brief eintreten — einschließlich des PR-Verweises (eine vollständige URL, eine <owner>/<repo>#<N>-Referenz oder "dieser PR" in einem ausgecheckten Repository) — das HyperFrames-Projekt erstellen und den Brief dauerhaft machen. Der Stil ist immer code-editorial (festgelegt in Schritt 2, niemals gefragt).
Der Brief wird von der Intent-Ebene bestätigt, nicht durch hier gestellte Fragen. Eröffnungsregel, in der Reihenfolge: (1) BRIEF.md existiert → lese es und frage nichts — der Brief ist endgültig, und seine flow/storyboard leiten den Modus ab (Briefvertrag § 1). (2) Kein BRIEF.md, aber das Projekt existiert (hyperframes.json / STORYBOARD.md auf der Festplatte) → setze vom Frontmatter des Storyboards und den aufgezeichneten Präferenzen fort; befrage nie ein halbfertiges Projekt erneut. (3) Weder noch — eine frische Erstellungsanfrage, die direkt hier ankam → lies /hyperframes und führe seine Intent-Ebene (references/intent-interview.md) aus: es überprü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 übergibt dann den gesperrten Brief zurück. Bearbeitungsanfragen überspringen all dies — gehe zur Bearbeitung.
Löse das Projektverzeichnis auf, bevor du andere Arbeiten ausführst. Behalte ein vom Benutzer angegebenes Projektverzeichnis bei; verwende andernfalls den dauerhaften externen Cache-Speicherort, der vom Resolver ausgegeben wird. Erstelle niemals videos/ im Aufrufer-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
Der Fähigkeits-Check läuft vor dem Abruf, der Story-Arbeit, dem Audio oder dem Frame-Versand. Wenn die installierte CLI den von diesem Skill benötigten Validierungsbefehl nicht ausführen kann, stoppe mit der Upgrade-Anweisung, anstatt zuerst den Kontext des Durchlaufs zu verbrauchen.
Initialisiere nur, wenn $PROJECT_DIR/hyperframes.json fehlt. Sein Basisname kommt vom PR, z. B. acme-sdk-pr-1842; verwende niemals den Arbeitsbereichsnamen oder einen Zeitstempel.
npx hyperframes init "$PROJECT_DIR" --non-interactive --example=blank --skill=pr-to-video — init überprüft die installierten Skills gegen die neuesten auf GitHub und aktualisiert die globale Menge, wenn welche veraltet sind.
Jeder relative Pfadbefehl unten wird mit $PROJECT_DIR als Arbeitsverzeichnis ausgeführt. Beispiele ohne explizite Subshell bedeuten (cd "$PROJECT_DIR" && …); ändere niemals den Arbeitsbaum des Aufrufer-Repositorys.
Schreibe BRIEF.md sofort nach init (niemals davor — init verweigert ein nicht leeres Verzeichnis): der gesperrte Brief der Intent-Ebene, Form pro ../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-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 Skelette zurück, aus denen Schritt 3 Entwürfe erstellt. Ein Rezept füllt Antworten, keine Genehmigungen; die Überprüfungs-Gateways laufen trotzdem.
Zeige den Anmeldestatus an, bevor du über das Setup hinausgehst — führe npx hyperframes auth status aus und gib seine Ausgabe wörtlich weiter. Es meldet, ob die Stimme/BGM HeyGen oder lokale Engines verwendet und, wenn abgemeldet, wie man sich anmeldet. Wende einen Zweig an:
- Kollaborativ: warte, bis sich der Benutzer anmeldet oder explizit
offline/gowählt. - Autonom: gib den Status an und fahre mit den verfügbaren lokalen Engines fort.
Unterlasse es, stillschweigend eine erforderliche Fähigkeit wegzulassen, wenn kein Offline-Anbieter existiert; zeige das Hindernis an. Falte diese Entscheidung nicht in eine andere Frage oder schreibe Schlüssel in ein Pro-Repo .env. Authentifizierungsbesitz und Offline-Fallbacks: /media-use references/setup-providers.md § Anbieter.
Gateway: hyperframes.json und BRIEF.md existieren; der PR-Verweis 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 (kein Capture)
Ziel: Die Fakten des PRs abrufen und als Informationsquelle in das Projekt einfließen lassen. Es gibt kein Website-Capture. fetch-pr.mjs führt gh deterministisch aus — vervollständigt die Dateiliste über paginierte gh api, sodass 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 löst es auch eine bestmögliche shipped_version (+ version_source) in pr.json auf, sodass die Endkarte eine echte Version anstelle einer erfundenen zitieren kann. Dann faltet ingest.mjs das offline in das synthetische Capture-Paket.
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 / nicht gefunden / private Fehler beenden mit 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 (Beitragende, 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 der Personen-Front — lade den GitHub-Avatar jedes Beitragenden herunter nach
# assets/<login>.png für den Credits-Abspann. Best-Effort; beendet immer mit 0.
(cd "$PROJECT_DIR" && node <SKILL_DIR>/scripts/fetch-people-avatars.mjs \
--people ./capture/extracted/people.json)
Wenn fetch-pr.mjs mit 1 beendet wird (gh auth / nicht gefunden / privat), melde seinen stderr und stoppe — fälsche keine PR-Inhalte. Wenn ingest.mjs mit 1 beendet wird, lies seinen stderr (normalerweise ein fehlerhaftes pr.json), behebe es und führe es erneut aus (deterministisch). fetch-people-avatars.mjs beendet immer mit 0; fehlende Avatare bedeuten nur keinen Credits-Abspann für den Autor.
people.json trägt einen name für diejenigen Beitragenden, die gh bereits benannt hat (der PR-Autor, Commit-Autoren, mergedBy) — null für den Rest (Reviewer/Kommentatoren/Beauftragte, die gh pr view nur als nackten login liefert). Bevor du den Credits-Abspann in Schritt 3 schreibst, löse selbst jeden null-Namen für die 1-6 Personen auf, die tatsächlich auf diesem Frame erscheinen werden: gh api users/<login> --jq .name (du hast bereits gh — kein Grund, dies zu skripten). Wenn GitHub auch keinen öffentlichen Namen für diesen Benutzer hat, falle auf den Login auf dem Bildschirm zurück und lasse diese Person aus der gesprochenen Zeile fallen (siehe story-design.md Abschnitt Credits — die Voiceover muss dennoch Namen sagen, niemals rohe Handles).
Gateway: capture/pr.json, capture/diff.patch, capture/extracted/tokens.json, capture/extracted/visible-text.txt und capture/extracted/people.json existieren; du kannst die Änderung des PRs in einem klaren Satz angeben. assets/<login>.png ist Best-Effort — seine Abwesenheit ist kein Fehler.
Schritt 2: Designsystem
Ziel: Die code-editoriale Frame-Voreinstellung übernehmen; ein Skript verwandelt sie in das frame.md + Caption-Skin dieses Videos.
Der Stil ist festgelegt — code-editorial (warmes Editorial; eine marineblaue Code-Oberfläche, die für Diffs entwickelt wurde). Führe aus:
node <SKILL_DIR>/scripts/build-frame.mjs --preset code-editorial --hyperframes .
Das Skript kopiert die code-editoriale Voreinstellung FRAME.md → frame.md, mischt sie mit etwaigen Marken-Tokens in capture/extracted/tokens.json (ein PR hat keine → colors:[]/fonts:[] behält die eigene Palette der code-editorialen Voreinstellung, ein vollständiges Design), kopiert das Caption-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 wird — keine manuelle Bearbeitung.
Gateway: build-frame.mjs wurde mit 0 beendet — frame.md existiert von der code-editorialen Voreinstellung 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.
Lies ../hyperframes-creative/references/story-spine.md (Hook-Sprache, Wert-vor-Beweis, Storyboard-als-Vorschlag, quellnachvollziehbare 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; die Montage berichtet, wo der Schnitt dagegen landet.
Verwende story-design.md für den PR-Archetyp (Changelog / Feature-Enthüllung / Fehler-Erklärer / Refactoring-Durchlauf), die PR-nativen Frame-Typen, Hook, Überzeugung, Beats, das Pro-Frame-Wortbudget und den Credits-Abspann. Die Reihenfolge kommt vom narrativen Design, nicht der Datei-Reihenfolge des Diffs — erkläre die Änderung, lies den Diff nicht laut vor. Als weichen Leitfaden konsultiere die Rollen-zu-Blueprint-Menü in ../hyperframes-animation/blueprints-index.md: für jeden Beat schreibe die Voiceover in der Form, die sein Kandidaten-Blueprint impliziert, und tagge diesen Kandidaten mit der blueprint:-ID, wenn einer passt (die Story-Wahrheit entscheidet dennoch, welche Beats existieren — erzwinge niemals einen Beat, um in eine Form zu passen). Zeige 2-4 reale Diff-Hunks (aus capture/diff.patch), jedes ein kleines lesbares Snippet; nenne den code-*-Block, den jedes im scene des Frames möchte. Frames tragen keine asset_candidates außer dem credits-Abspann (1-6 assets/<login>.png-Avatare). 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 — führe die Vorschau von PROJECT_DIR im Hintergrund aus), präsentiere den Plan als Vorschlag und stelle die zwei Fragen — genehmigen oder ändern, und Skizzen zuerst (empfohlen) oder überspringen. Feedback durchläuft Chat oder die Kommentardatei des Boards, bis es genehmigt ist. Dies ist ein Checkpoint-Gateway (Briefvertrag § 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.
Gateway: 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 Plan genehmigt (autonom: die Zusammenfassung wurde als Vorankündigung gepostet).
Schritt 3.1: Audio
Ziel: Erzählung, Wort-Timings, 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.
Wähle die Erzählstimme aus der Anfrage des Benutzers, 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-Standardeinstellung ist ansonsten Marcia (weiblich) auf HeyGen / am_michael auf Kokoro — so wird eine Anfrage wie "eine männliche Stimme" 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 (Briefvertrag § 2), bevor die Pipeline-Standardeinstellung verwendet wird, und sage, welche du verwendet hast; lasse --voice nur weg, wenn keiner eine nennt. Wenn der Benutzer explizit eine ...
[Rest des Inhalts aus Gründen der Länge abgeschnitten — folgt dem gleichen Übersetzungsmuster.]