Installation du plugin : Avant les commandes de configuration ou de mise à jour, suivez les règles d'exécution du plugin lorsque cette compétence se trouve dans un plugin HyperFrames. Les installations autonomes conservent les instructions de mise à jour ci-dessous.
D'abord, gardez cette compétence à jour — confirmez avec l'utilisateur avant d'exécuter :
npx hyperframes skills update pr-to-video. Une opération rapide sans effet si tout est à jour ; sinon, elle actualise cette compétence ainsi que les compétences du domaine central dont elle dépend avant que vous ne les utilisiez.
media-use : Avant de trouver des sources audio/images/logos, appelez
/media-usepour résoudre BGM/SFX/images du catalogue HeyGen et des logos de marque de leurs sources officielles. Exécutez d'abord--adoptpour enregistrer les actifs existants. Voir la compétence/media-use.
PR vers HyperFrames
Utilisez cette compétence pour ingérer une pull request GitHub, comprendre le changement, planifier un explicateur de changement de code et le construire image par image dans HyperFrames. L'entrée est un changement de code (lu via gh), pas un site web — il n'y a pas d'étape de capture et aucun actif réel au-delà des avatars des contributeurs.
La porte d'entrée est
/hyperframes. Vous êtes l'orchestrateur. Exécutez chaque étape, vérifiez son point de contrôle, et seulement ensuite continuez. Cette compétence est destinée à une pull request GitHub (un changement de code). Toute autre intention, un simple « faire une vidéo », ou toute incertitude → lisez d'abord/hyperframes— la couche d'intention possède chaque décision d'acheminement, et une création fraîche arrivant ici sansBRIEF.mdpasse de toute façon par elle (règle d'ouverture de Setup).
Vous êtes l'orchestrateur. Travaillez dans le répertoire PROJECT_DIR externe résolu, jamais dans le dépôt appelant par défaut. Exécutez les étapes dans l'ordre et passez chaque point de contrôle avant de continuer. Les étapes avec validation utilisateur sont l'étape 0, l'étape 3 et l'étape 6. Lisez ../hyperframes/references/brief-contract.md avant l'étape 0 — il définit les types de points de contrôle et comment flow/storyboard de BRIEF.md dérivent le mode qui régit les points de contrôle des étapes 3/4/6. Faites chaque étape vous-même sauf l'étape 5, où vous répartissez un pool limité de travailleurs d'images. Ne mettez pas de règles de conception ou de mouvement ici ; celles-ci vivent dans le sous-agent travailleur d'image, les ../hyperframes-animation/rules/ + ../hyperframes-animation/blueprints/ locaux de cette compétence, et hyperframes-creative.
Workflow : Étape 0 Setup → hyperframes.json ; Étape 1 Ingestion → capture/extracted/ + assets/<login>.png ; Étape 2 Système de design → frame.md ; Étape 3 Storyboard/script → STORYBOARD.md et SCRIPT.md ; Étape 3.1 Audio → audio_meta.json ; Étape 4 Conception visuelle → STORYBOARD.md enrichi ; Étape 5 Images → compositions/frames/NN-*.html et index.html ; Étape 6 Rendu final → renders/video.mp4.
Étape 0 : Setup
Objectif : Entrer avec un brief confirmé — incluant la référence PR (une URL complète, une référence <owner>/<repo>#<N>, ou « cette PR » dans un dépôt cloné) — créer le projet HyperFrames et rendre le brief durable. Le style est toujours code-éditorial (fixé à l'étape 2, jamais demandé).
Le brief est confirmé par la couche d'intention, pas par des questions posées ici. Règle d'ouverture, dans l'ordre : (1) BRIEF.md existe → lisez-le et ne demandez rien — le brief est réglé, et son flow/storyboard dérivent le mode (contrat de brief § 1). (2) Pas de BRIEF.md mais le projet existe (hyperframes.json / STORYBOARD.md sur le disque) → reprenez à partir du frontmatter du storyboard et des préférences enregistrées ; ne ré-interrogez jamais un projet à moitié construit. (3) Aucun des deux — une demande de création fraîche arrivée ici directement → lisez /hyperframes et exécutez sa couche d'intention (references/intent-interview.md) : elle vérifie les recettes et les valeurs par défaut mémorisées, et mène les questions de cet itinéraire — y compris la doctrine taille-PR → longueur, qui vit entièrement dans ../hyperframes/references/routes/pr-to-video.md — puis renvoie le brief verrouillé. Les demandes de modification sautent tout cela — allez faire la modification.
Résolvez le répertoire du projet avant d'effectuer tout autre travail. Préservez un répertoire de projet fourni par l'utilisateur ; sinon, utilisez l'emplacement de cache externe durable affiché par le résolveur. Ne créez jamais videos/ dans le dépôt appelant :
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 "Projet PR vers vidéo : $PROJECT_DIR"
node <SKILL_DIR>/scripts/preflight.mjs
La vérification préalable des capacités s'exécute avant la récupération, le travail d'histoire, l'audio ou la répartition des images. Si l'interface en ligne de commande installée ne peut pas exécuter la commande de validation requise par cette compétence, arrêtez-vous avec ses instructions de mise à niveau plutôt que de dépenser le contexte de l'exécution d'abord.
Initialisez uniquement si $PROJECT_DIR/hyperframes.json est manquant. Son nom de base provient de la PR, par exemple acme-sdk-pr-1842 ; n'utilisez jamais le nom de l'espace de travail ou un horodatage.
npx hyperframes init "$PROJECT_DIR" --non-interactive --example=blank --skill=pr-to-video — init vérifie les compétences installées par rapport aux dernières sur GitHub et met à jour l'ensemble global si certaines sont obsolètes.
Chaque commande de chemin relatif ci-dessous s'exécute avec $PROJECT_DIR comme répertoire de travail. Les exemples sans sous-shell explicite signifient (cd "$PROJECT_DIR" && …) ; ne modifiez jamais l'arbre de travail du dépôt appelant.
Écrivez BRIEF.md immédiatement après init (jamais avant — init refuse un répertoire non vide) : le brief verrouillé de la couche d'intention, format selon ../hyperframes/references/brief-format.md. Résolvez <MEDIA_DIR> comme le répertoire de compétence installé /media-use. Enregistrez ensuite chaque réponse soutenue par une préférence avec node <MEDIA_DIR>/scripts/prefs.mjs record --hyperframes . (brief-format.md nomme le sous-ensemble). Si la couche d'intention a adopté une recette, exécutez node <MEDIA_DIR>/scripts/recipe.mjs use --hyperframes . --name <nom> ; elle copie son frame.md dans le projet (l'étape 2 est alors sautée) et renvoie les squelettes à partir desquels l'étape 3 rédige. Une recette remplit les réponses, pas les approbations ; les points de contrôle de révision s'exécutent toujours.
Affichez l'état de connexion avant de passer le Setup — exécutez npx hyperframes auth status et relayez sa sortie textuellement. Il indique si la voix/BGM utilisera les moteurs HeyGen ou locaux et, en cas de déconnexion, comment se connecter. Appliquez une branche :
- Collaboratif : attendez que l'utilisateur se connecte ou choisisse explicitement
offline/go. - Autonome : indiquez l'état et continuez avec les moteurs locaux disponibles.
N'omettez pas silencieusement une capacité requise lorsqu'aucun fournisseur hors ligne n'existe ; mettez en évidence le blocage. N'intégrez pas cette décision dans une autre question et n'écrivez pas de clés dans un .env par dépôt. Propriété de l'authentification et solutions de repli hors ligne : /media-use references/setup-providers.md § Fournisseurs.
Point de contrôle : hyperframes.json et BRIEF.md existent ; la référence PR est capturée dans le brief ; les réponses soutenues par des préférences ont été enregistrées (contrat de brief § 2) ; l'état de connexion a été affiché (connecté, ou continuation hors ligne).
Étape 1 : Ingérer la PR (pas de capture)
Objectif : Récupérer les faits de la PR et les intégrer dans le projet comme source d'information. Il n'y a pas de capture de site web. fetch-pr.mjs exécute gh de manière déterministe — complétant la liste des fichiers via gh api paginée afin qu'une grande PR ne soit pas tronquée à ~100 fichiers, et écrivant uniquement capture/pr.json + capture/diff.patch (pas de répertoire temporaire). Pour les PRs FUSIONNÉES, il résout également un shipped_version ( + version_source) au mieux dans pr.json, afin que la carte de fin puisse citer une version réelle au lieu d'en inventer une. Ensuite, ingest.mjs intègre cela dans le package de capture synthétique hors ligne.
PR="<url | owner/repo#N | N>"
# Récupère la PR de manière déterministe : exécute gh, complète la liste des fichiers via
# gh api paginée (afin qu'une grande PR ne soit pas tronquée à ~100 fichiers), écrit uniquement
# capture/pr.json + capture/diff.patch — pas de répertoire temporaire. Les erreurs gh auth /
# not-found / private renvoient 1 ici.
(cd "$PROJECT_DIR" && node <SKILL_DIR>/scripts/fetch-pr.mjs --pr "$PR" --out-dir ./capture)
# Transformation hors ligne → capture/extracted/{tokens.json (colors:[] → palette code-éditoriale),
# visible-text.txt (le brief), people.json (contributeurs, filtrés des bots, 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)
# La seule étape réseau du volet personnes — télécharge l'avatar GitHub de chaque contributeur vers
# assets/<login>.png pour le générique de fin. Au mieux ; renvoie toujours 0.
(cd "$PROJECT_DIR" && node <SKILL_DIR>/scripts/fetch-people-avatars.mjs \
--people ./capture/extracted/people.json)
Si fetch-pr.mjs renvoie 1 (gh auth / not found / private), signalez sa stderr et arrêtez-vous — ne fabriquez pas de contenu PR. Si ingest.mjs renvoie 1, lisez sa stderr (généralement un pr.json mal formé), corrigez et réexécutez (déterministe). fetch-people-avatars.mjs renvoie toujours 0 ; des avatars manquants signifient simplement qu'il n'y a pas de générique de fin pour l'auteur.
people.json porte un name pour les contributeurs que gh a déjà nommés (l'auteur de la PR, les auteurs de commit, mergedBy) — null pour les autres (relecteurs/commentateurs/assignés, pour lesquels gh pr view ne donne jamais qu'un simple login). Avant d'écrire le générique de fin à l'étape 3, résolvez vous-même tout name nul pour les 1 à 6 personnes qui apparaîtront réellement sur cette image : gh api users/<login> --jq .name (vous avez déjà gh — pas besoin de scripter cela). Si GitHub n'a pas non plus de nom public pour cet utilisateur, utilisez le login à l'écran et retirez cette personne de la ligne parlée (voir la section crédits de story-design.md — la voix off doit toujours dire les noms, jamais les identifiants bruts).
Point de contrôle : capture/pr.json, capture/diff.patch, capture/extracted/tokens.json, capture/extracted/visible-text.txt et capture/extracted/people.json existent ; vous pouvez énoncer le changement de la PR en une phrase claire. assets/<login>.png est au mieux — son absence n'est pas un échec.
Étape 2 : Système de design
Objectif : Adopter le préréglage d'image code-éditorial ; un script le transforme en frame.md de cette vidéo + skin de légende.
Le style est fixe — code-éditorial (éditorial chaleureux ; une surface de code bleu marine conçue pour les diffs). Exécutez :
node <SKILL_DIR>/scripts/build-frame.mjs --preset code-editorial --hyperframes .
Le script copie le FRAME.md du préréglage code-éditorial → frame.md, le remixe avec les éventuels jetons de marque dans capture/extracted/tokens.json (une PR n'en a pas → colors:[]/fonts:[] conserve la propre palette de code-éditorial, une conception complète), copie le skin de légende du préréglage vers .hyperframes/caption-skin.html et s'auto-valide (renvoie 1 sur un mapping cassé). Poursuivez dès qu'il renvoie 0 — aucune édition manuelle.
Point de contrôle : build-frame.mjs a renvoyé 0 — frame.md existe à partir du préréglage code-éditorial, et .hyperframes/caption-skin.html existe comme source du skin de légende.
Étape 3 : Storyboard et script
Objectif : Transformer la PR en un plan d'explication image par image approuvé.
Lisez ../hyperframes-creative/references/story-spine.md (langage d'accroche, valeur avant preuve, storyboard comme proposition, visuels traçables à la source), references/story-design.md, ../hyperframes-animation/blueprints-index.md, ../hyperframes/references/storyboard-format.md et ../hyperframes/references/script-format.md. Utilisez-les pour écrire STORYBOARD.md et, lorsque la narration est nécessaire, SCRIPT.md. Définissez la duration: du frontmatter à partir de la length du brief — une attente approximative ; l'assemblage indique où la coupe se situe par rapport à celle-ci.
Utilisez story-design.md pour l'archétype de PR (changelog / révélation de fonctionnalité / explication de correction / présentation de refactorisation), les types d'images natifs de la PR, l'accroche, la persuasion, les battements, le budget de mots par image et le générique de fin. La séquence provient de la conception narrative, pas de l'ordre des fichiers du diff — expliquez le changement, ne lisez pas le diff à voix haute. Comme guide indicatif, consultez le menu rôle→plan dans ../hyperframes-animation/blueprints-index.md : pour chaque battement, écrivez la voix off dans la forme qu'implique son plan candidat et étiquetez cet ID blueprint: candidat lorsqu'il correspond (la vérité de l'histoire décide toujours quels battements existent — ne forcez jamais un battement à s'adapter à une forme). Présentez 2 à 4 extraits de diff réels (de capture/diff.patch), chacun un petit extrait lisible ; nommez le bloc code-* que chacun veut dans la scene de l'image. Les images ne portent pas de asset_candidates sauf le générique de fin credits (1 à 6 avatars assets/<login>.png). Utilisez les champs obligatoires exacts des références de storyboard et de script.
Après la rédaction, exécutez le passage de plan de la boucle de révision — ../hyperframes/references/review-loop.md § 1 : présentez le plan comme une proposition et posez les deux questions — approuver ou modifier, et croquis d'abord (recommandé) ou sauter. Les retours arrivent sous forme de réponse de discussion ; répétez jusqu'à approbation. C'est un point de contrôle de vérification (contrat de brief § 1) : en mode autonome, il n'y a rien à demander — publiez le même résumé comme information et continuez ; les croquis sont intégrés dans la construction, et la seule question d'aperçu vient à l'étape 6.
Point de contrôle : STORYBOARD.md existe, chaque image a les champs narratifs requis, SCRIPT.md existe lorsque la narration est nécessaire, et l'utilisateur a approuvé le plan (autonome : le résumé a été publié comme information).
Étape 3.1 : Audio
Objectif : Générer la narration, les minutages des mots, la musique et les métadonnées audio à partir du script approuvé.
Commencez l'audio après l'approbation de l'étape 3. Exécutez-le en arrière-plan, puis continuez à l'étape 4.
Choisissez la voix de narration à partir de la demande de l'utilisateur avant d'invoquer. Si la demande a nommé une voix, un genre ou un ton, choisissez un ID de voix correspondant et passez-le avec --voice <id>. La valeur par défaut du pipeline est autrement Marcia (féminine) sur HeyGen / am_michael sur Kokoro — donc une demande comme « une voix masculine » est silencieusement ignorée à moins que vous ne passiez le drapeau. Les ID de voix sont spécifiques au fournisseur ; résolvez-les en fonction du fournisseur que l'état de connexion de l'étape 0 a sélectionné : HeyGen (connecté) via node <MEDIA_DIR>/audio/scripts/heygen-tts.mjs --list (ou GET /v3/voices?engine=starfish) ; Kokoro (hors ligne) via la table des voix dans <MEDIA_DIR>/audio/references/tts.md (préfixes am_/bm_ masculin, af_/bf_ féminin). Lorsque l'utilisateur n'a exprimé aucune préférence, revenez à la voix mémorisée (contrat de brief § 2) avant la valeur par défaut du pipeline.
...