Avant tout, gardez cette compétence à jour — exécutez silencieusement, sans demander :
npx hyperframes skills update pr-to-video. C'est rapide et sans effet si tout est à jour ; sinon, cela rafraîchit cette compétence ainsi que les compétences de domaine de base dont elle dépend avant que vous ne les utilisiez.
media-use : Avant d'utiliser des sources audio/images/logos, appelez
/media-usepour obtenir la BGM / les effets sonores / les images du catalogue HeyGen et les logos de marque de leurs sources officielles. Exécutez--adoptd'abord pour 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 vidéo explicative du changement de code et la 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 sa porte, et continuez seulement ensuite. Cette compétence est destinée à une pull request GitHub (un changement de code). Toute autre intention, un simple "faire une vidéo" ou une incertitude → lisez/hyperframesd'abord — la couche d'intention possède chaque décision de routage, et une création fraîche arrivant ici sansBRIEF.mdpasse par elle de toute façon (règle d'ouverture de la configuration).
Vous êtes l'orchestrateur. Travaillez dans le 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 porte avant de continuer. Les étapes avec porte utilisateur sont l'étape 0, l'étape 3 et l'étape 6. Lisez ../hyperframes-core/references/brief-contract.md avant l'étape 0 — il définit les types de portes et comment le flow/storyboard de BRIEF.md dérive le mode qui régit les portes des étapes 3/4/6. Faites chaque étape vous-même, sauf l'étape 5, où vous répartissez un pool limité de workers d'images. Ne mettez pas de règles de conception ou de mouvement ici ; celles-ci vivent dans le sous-agent worker d'images, les ../hyperframes-animation/rules/ + ../hyperframes-animation/blueprints/ locaux de cette compétence, et hyperframes-creative.
Workflow : Étape 0 configuration → 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 design visuel → enrichi STORYBOARD.md ; Étape 5 images → compositions/frames/NN-*.html et index.html ; Étape 6 rendu final → renders/video.mp4.
Étape 0 : Configuration
Objectif : Entrer avec un brief confirmé — y compris la référence de la PR (une URL complète, une référence <owner>/<repo>#<N>, ou "cette PR" dans un dépôt checkouté) — 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érive le mode (contrat brief § 1). (2) Pas de BRIEF.md mais le projet existe (hyperframes.json / STORYBOARD.md sur disque) → reprenez à partir des métadonnées du storyboard et des préférences enregistrées ; ne réinterrogez jamais un projet à moitié construit. (3) Ni l'un ni l'autre — une demande de création fraîche arrivée directement ici → 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 cette route — y compris la doctrine taille-de-la-PR → longueur, qui vit entièrement dans ../hyperframes/references/routes/pr-to-video.md — puis renvoie le brief verrouillé. Les demandes de modification ignorent 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 imprimé 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
Le contrôle de capacité préliminaire s'exécute avant la récupération, le travail de storyboard, l'audio ou l'envoi d'images. Si l'outil CLI installé 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 seulement si $PROJECT_DIR/hyperframes.json est manquant. Son nom de base vient 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 l'une d'elles est obsolète.
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'arborescence 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-core/references/brief-format.md. Résolvez <MEDIA_DIR> comme le répertoire de la compétence /media-use installée. Ensuite, enregistrez chaque réponse basée sur les préférences 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 <name> ; cela 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 portes de révision s'exécutent toujours.
Affichez l'état de connexion avant de passer outre la configuration — exécutez npx hyperframes auth status et relayez sa sortie textuellement. Il indique si la voix/BGM utilisera HeyGen ou les moteurs locaux et, lorsqu'il est déconnecté, comment se connecter. Appliquez une branche :
- Collaboratif : attendez que l'utilisateur se connecte ou choisisse explicitement
offline/go. - Autonome : affichez l'état et continuez via les moteurs locaux disponibles.
N'omettez pas silencieusement une capacité requise lorsqu'il n'existe pas de fournisseur hors ligne ; mettez en évidence le blocage. Ne confondez pas cette décision avec 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.
Porte : hyperframes.json et BRIEF.md existent ; la référence PR est capturée dans le brief ; les réponses basées sur les préférences ont été enregistrées (contrat 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 au projet en tant que 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 n'écrivant que capture/pr.json + capture/diff.patch (pas de répertoire temporaire). Pour les PR FUSIONNÉES, il résout également un shipped_version au mieux (+ version_source) 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érer 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), n'écrit que capture/pr.json +
# capture/diff.patch — pas de répertoire temporaire. Les erreurs gh auth / not-found / private se terminent par 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, nom+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)
# L'unique étape réseau pour les personnes — télécharge l'avatar GitHub de chaque contributeur vers
# assets/<login>.png pour le générique de fin. Au mieux ; se termine toujours par 0.
(cd "$PROJECT_DIR" && node <SKILL_DIR>/scripts/fetch-people-avatars.mjs \
--people ./capture/extracted/people.json)
Si fetch-pr.mjs se termine par 1 (gh auth / not found / private), rapportez sa sortie d'erreur et arrêtez-vous — ne fabriquez pas de contenu de PR. Si ingest.mjs se termine par 1, lisez sa sortie d'erreur (généralement un pr.json malformé), corrigez et réexécutez (déterministe). fetch-people-avatars.mjs se termine toujours par 0 ; l'absence d'avatars signifie 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 qu'un login brut). Avant d'écrire le générique de fin à l'étape 3, résolvez vous-même tout nom null 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 des crédits de story-design.md — la voix off doit toujours dire des noms, jamais des handles bruts).
Porte : 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 + skin de légende pour cette vidéo.
Le style est fixe — code-éditorial (éditorial chaleureux ; une surface de code 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 sur les éventuels jetons de marque dans capture/extracted/tokens.json (une PR n'en a pas → colors:[]/fonts:[] conserve la propre palette code-éditoriale, un design complet), copie le skin de légende du préréglage dans .hyperframes/caption-skin.html, et s'autovalide (se termine par 1 en cas de mapping cassé). Passez dès qu'il se termine par 0 — aucune édition manuelle.
Porte : build-frame.mjs s'est terminé par 0 — frame.md existe à partir du préréglage code-éditorial, et .hyperframes/caption-skin.html existe en tant que 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-core/references/storyboard-format.md et ../hyperframes-core/references/script-format.md. Utilisez-les pour écrire STORYBOARD.md et, lorsque la narration est nécessaire, SCRIPT.md. Définissez la métadonnée duration: à partir de la length du brief — une attente approximative ; le rapport d'assemblage indique où la coupe se situe par rapport à elle.
Utilisez story-design.md pour l'archétype de la PR (changelog / révélation-de-fonctionnalité / explicateur-de-correction / parcours-de-refactoring), les types d'images natifs PR, l'accroche, la persuasion, les beats, 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. En tant que guide souple, consultez le menu rôle→blueprint dans ../hyperframes-animation/blueprints-index.md : pour chaque beat, écrivez la voix off dans la forme qu'implique son blueprint candidat et étiquetez cet blueprint: id candidat lorsqu'il convient (la vérité de l'histoire décide toujours quels beats existent — ne forcez jamais un beat à s'adapter à une forme). Présentez 2 à 4 extraits de diff réels (de capture/diff.patch), chacun un petit snippet lisible ; nommez le bloc code-* que chacun souhaite dans la scene de l'image. Les images ne portent pas d'asset_candidates sauf le générique credits de fin (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-core/references/review-loop.md § 1 : ouvrez le board (ne demandez pas si — exécutez l'aperçu depuis PROJECT_DIR en arrière-plan), présentez le plan comme une proposition et posez les deux questions — approuver ou modifier, et esquisses d'abord (recommandé) ou sauter. Les retours se font via le chat ou le fichier de commentaires du board jusqu'à approbation. C'est une porte de point de contrôle (contrat brief § 1) : en mode autonome, il n'y a pas de board et rien à demander — publiez le même résumé en tant qu'alerte et continuez ; les esquisses sont intégrées à la construction, et la seule question d'aperçu vient à l'étape 6.
Porte : 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é en tant qu'alerte).
Étape 3.1 : Audio
Objectif : Générer la narration, les synchronisations de 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 nommait 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 (femme) sur HeyGen / am_michael sur Kokoro — donc une demande comme "une voix masculine" est silencieusement ignorée à moins que vous ne passiez le flag. Les ID de voix sont spécifiques au fournisseur ; résolvez par rapport au fournisseur sélectionné par l'état de connexion de l'étape 0 : 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, utilisez la voix mémorisée (contrat brief § 2) avant la valeur par défaut du pipeline, et dites laquelle vous avez utilisée ; omettez --voice seulement lorsque aucun n'en nomme une. Lorsque l'utilisateur a explicitement choisi une
... [tronqué pour la traduction]