Installation du plugin : Avant les commandes de configuration ou de mise à jour, suivez les règles d'exécution des plugins lorsque ce skill se trouve dans un plugin HyperFrames. Pour une installation autonome, conservez les instructions de mise à jour ci-dessous.
D'abord, gardez ce skill à jour — confirmez avec l'utilisateur avant d'exécuter :
npx hyperframes skills update faceless-explainer. Une opération rapide et sans effet si tout est à jour ; sinon, elle met à jour ce skill ainsi que les skills de base dont il dépend avant que vous ne les utilisiez.
media-use : Avant de sourcer des images/audio/logos, appelez
/media-usepour résoudre les BGM/SFX/images du catalogue HeyGen et les logos de marque depuis leurs sources officielles. Exécutez--adoptd'abord pour enregistrer les actifs existants. Voir le skill/media-use. Lorsque l'application hôte fournit ses propres outils de musique ou d'effets sonores, utilisez-les pour la musique et les effets sonores.
Faceless Explainer vers HyperFrames
Utilisez ce skill pour transformer un corps de texte en vidéo explicative : choisissez un système de design, planifiez une histoire pédagogique et construisez-la image par image dans HyperFrames. Faceless signifie que chaque visuel est inventé en aval — il n'y a pas d'étape de capture ni d'inventaire d'actifs réel.
La porte d'entrée est
/hyperframes. Vous êtes l'orchestrateur. Exécutez chaque étape, vérifiez sa porte, et continuez seulement ensuite. Ce skill est destiné à expliquer un sujet à partir d'un texte, sans produit ni site web à capturer. Toute autre intention, un simple "faire une vidéo", ou toute incertitude → lisez/hyperframesd'abord — la couche d'intention possède chaque décision d'itinéraire, et une création fraîche arrivant ici sansBRIEF.mdpasse de toute façon par elle (règle d'ouverture de la configuration).
Vous êtes l'orchestrateur. Travaillez dans videos/<projet>/. 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/references/brief-contract.md avant l'étape 0 — il définit les types de portes et comment flow/storyboard de BRIEF.md dérivent le mode qui régit les portes des étapes 3/4/6. Faites chaque étape vous-même, sauf l'étape 5, où vous déléguez un sous-agent par image. Ne placez pas de règles de design ou de mouvement ici ; elles vivent dans le sous-agent de travail d'image, les ../hyperframes-animation/rules/ + ../hyperframes-animation/blueprints/ locales de ce skill, et hyperframes-creative.
Flux de travail : Étape 0 configuration → hyperframes.json ; Étape 1 résumé → capture/extracted/ ; É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 → STORYBOARD.md enrichi ; Étape 5 images → compositions/frames/NN-*.html et index.html ; Étape 6 rendu final → renders/video.mp4.
Étape 0 : Configuration
Objectif : Entrer avec un résumé confirmé, créer le projet HyperFrames et rendre le résumé durable.
Le résumé 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 résumé est réglé, et son flow/storyboard dérivent le mode (contrat de résumé § 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) Ni l'un ni l'autre — 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, mène les questions de cet itinéraire (../hyperframes/references/routes/faceless-explainer.md), et renvoie le résumé verrouillé. Les demandes de modification sautent tout ceci — allez faire la modification.
Initialisez seulement si hyperframes.json est manquant. Nommez <projet> à partir du sujet en kebab-case, par exemple interets-composes-expliques ; n'utilisez jamais le nom de l'espace de travail ou un horodatage.
npx hyperframes init "videos/<projet>" --non-interactive --example=blank --skill=faceless-explainer — init vérifie les skills installés par rapport aux dernières versions sur GitHub et met à jour l'ensemble global si certains sont obsolètes.
Après l'init, laissez <PROJECT_ROOT> être videos/<projet> et exécutez chaque commande de chemin relatif suivante avec ce répertoire comme répertoire de travail. Dans les commandes ci-dessous, . signifie <PROJECT_ROOT> ; n'écrivez jamais .media, capture ou des fichiers de sortie dans le répertoire appelant.
Écrivez BRIEF.md immédiatement après l'init (jamais avant — init refuse un répertoire non vide) : le résumé verrouillé de la couche d'intention, forme selon ../hyperframes/references/brief-format.md. Résolvez <MEDIA_DIR> comme le répertoire du skill /media-use installé. Ensuite, enregistrez chaque réponse basée sur 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 que l'étape 3 ébauche. 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 l'étape de 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 : indiquez l'état et continuez via les moteurs locaux disponibles.
N'omettez pas silencieusement une capacité requise lorsqu'aucun fournisseur hors ligne n'existe ; signalez le blocage. Ne pliez pas cette décision dans une autre question ou n'écrivez pas de clés dans un .env par dépôt. Propriété de l'authentification et basculements hors ligne : /media-use references/setup-providers.md § Fournisseurs.
Porte : hyperframes.json et BRIEF.md existent ; les réponses basées sur les préférences ont été enregistrées (contrat de résumé § 2) ; l'état de connexion a été affiché (connecté, ou continuation hors ligne).
Étape 1 : Résumé (sans capture)
Objectif : Intégrer le texte de l'utilisateur dans le projet comme source d'information. Il n'y a pas de capture de site web ni d'actifs réels — c'est un explainer sans visage.
Enregistrez l'entrée complète de l'utilisateur textuellement, puis créez le paquet de capture synthétique manuellement :
capture/extracted/visible-text.txt— l'article / les notes / le sujet / le résumé complet, textuellement. C'est la source d'information, pas un modèle d'histoire (l'étape 3 le remodèle).capture/extracted/tokens.json—{ "title": "", "description": "", "colors": [], "fonts": [] }. Remplisseztitle/descriptionà partir du résumé. Laissezcolors/fontsvides sauf si l'utilisateur a explicitement donné des couleurs ou polices de marque — alors ajoutez-les (le préréglage de design fournit une palette complète de toute façon).
Si l'utilisateur a collé un script ou souhaite que son texte soit conservé, enregistrez-le textuellement sous user_script.txt ; VO_MODE (textuel ou restructuré) vient de BRIEF.md — la couche d'intention le demande lorsqu'un script arrive. Demandez une fois ici seulement si le résumé lui manque, et stockez la réponse pour l'étape 3.
Ne pas exécuter npx hyperframes capture (il n'y a pas d'URL). Ne créez pas asset-descriptions.md ni ne peuplez capture/assets/ — les visuels sans visage sont inventés aux étapes 4-5, pas capturés. La seule exception : si l'utilisateur a fourni une image réelle, placez-la sous public/<nom_de_base> et notez-la pour l'étape 3.
Porte : capture/extracted/visible-text.txt et capture/extracted/tokens.json existent ; vous pouvez énoncer le sujet de l'explainer et son public cible en une phrase claire.
Étape 2 : Système de design
Objectif : Choisir un préréglage d'image livré ; un script le transforme en frame.md + skin de légende de cette vidéo.
Lorsque BRIEF.md nomme un style_preset — l'utilisateur l'a choisi visuellement dans les présentations de la couche d'intention — utilisez-le ; l'appel de jugement est le vôtre seulement lorsque le résumé est silencieux. Ensuite, vous faites le seul appel — quel préréglage : lisez ../hyperframes-creative/references/design-spec.md et parcourez ../hyperframes-creative/frame-presets/ ; choisissez le préréglage dont l'apparence correspond le mieux au sujet, au ton et au public. Puis exécutez :
node <SKILL_DIR>/scripts/build-frame.mjs --preset <nom> --hyperframes .
Le script fait le reste de manière déterministe : copie le FRAME.md du préréglage → frame.md et le remixe sur tous les jetons de marque dans capture/extracted/tokens.json (couleurs de marque mappées sur les clés de couleur du préréglage par rôle ; les polices d'affichage + corps du préréglage remplacées par celles de la marque), copie le skin de légende du préréglage vers .hyperframes/caption-skin.html, et s'auto-valide (sortie 1 en cas de mapping cassé). Procédez dès qu'il sort 0 — pas d'édition manuelle de la spécification.
Un explainer sans visage n'a généralement pas de couleurs/polices de marque (tokens.json couleurs/polices vides) → le script conserve la propre palette du préréglage, un design complet livrable. Seulement lorsque l'utilisateur a nommé des couleurs/polices de marque, ajoutez-les à tokens.json avant l'exécution, et ajustez frame.md manuellement après seulement si un mapping le nécessite vraiment.
Porte : build-frame.mjs s'est terminé avec le code 0 — frame.md existe à partir d'un préréglage nommé, et (lorsque le préréglage en livre un) .hyperframes/caption-skin.html existe comme source du skin de légende ; le préréglage choisi a été enregistré comme préférence (--key style_preset --workflow <ce workflow>, contrat de résumé § 2).
Étape 3 : Storyboard et script
Objectif : Transformer le texte en un plan pédagogique approuvé image par image.
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 le frontmatter duration: à partir de la length du résumé — une attente approximative ; l'assemblage indique où la coupe se situe par rapport à elle.
Utilisez story-design.md pour la structure de l'explainer (concept / tutoriel / listicle / histoire), la stratégie d'accroche, les techniques de clarté, les battements émotionnels, le mapping type-énumération et VO_MODE. La séquence vidéo provient de la conception narrative, pas de l'ordre des paragraphes du texte d'entrée — réorganisez, fusionnez, omettez, compressez. En tant que guide souple, consultez le menu rôle→blueprint dans ../hyperframes-animation/blueprints-index.md : pour chaque battement, écrivez la voix off dans la forme que son blueprint candidat implique et étiquetez cet id blueprint: candidat lorsqu'il convient. La vérité pédagogique décide toujours quels battements existent — ne forcez jamais un battement à correspondre à un blueprint, et n'inventez jamais un battement simplement parce qu'une forme éprouvée est disponible. Les visuels sans visage sont inventés en aval, donc les images ne portent pas d'inventaire d'actifs : laissez asset_candidates vide sauf si l'utilisateur a fourni une image réelle public/<nom_de_base>. Utilisez les champs requis exacts des références de storyboard et de script.
Après l'ébauche, 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 ébauches d'abord (recommandé) ou sauter. Les retours arrivent sous forme de réponse de chat ; bouclez jusqu'à approbation. C'est une porte de point de contrôle (contrat de résumé § 1) : en mode autonome, il n'y a rien à demander — publiez le même résumé comme information et continuez ; les ébauches se fondent dans la construction, et l'aperçu final avec sa question unique 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 image par image (autonome : le résumé a été publié comme information).
Étape 3.1 : Audio
Objectif : Générer la narration, les timings 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. (L'état de connexion a déjà été affiché à l'étape 0 ; le moteur se rabat automatiquement.)
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 identifiant 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 sauf si vous passez le drapeau. Les identifiants de voix sont spécifiques au fournisseur ; résolvez 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 le tableau des voix dans <MEDIA_DIR>/audio/references/tts.md (préfixes am_/bm_ masculins, af_/bf_ féminins). Lorsque l'utilisateur n'a exprimé aucune préférence, revenez à la voix mémorisée (contrat de résumé § 2) avant la valeur par défaut du pipeline, et dites laquelle vous avez utilisée ; omettez --voice seulement lorsqu'aucune des deux n'en nomme une. Lorsque l'utilisateur a explicitement choisi une voix pour cette exécution, enregistrez-la (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> &
Le script audio gère la narration, les timings des mots, la recherche BGM dans la bibliothèque musicale de HeyGen et les métadonnées de timing. L'ambiance BGM provient du champ music: du storyboard. Cela utilise l'API Audio de HeyGen pour la récupération, pas la génération, et la même identité ~/.heygen que TTS. Pour les détails du fournisseur, lisez ../media-use/audio/references/tts.md. Lorsque les propres outils de l'application hôte créent la musique ou un effet sonore, placez le fichier sous assets/ et listez-le dans le fichier audio_meta.json marqué "source": "host" : musique comme bgm { "path": "assets/…", "source": "host" } avec music: none dans le storyboard ; un son comme une entrée sfx { "frame": <n>, "file": "assets/…", "offset_s": 0, "duration_s": <sa longueur>, "source": "host" }. Chaque passage audio conserve ceux-ci, et une image avec un son hôte n'obtient pas de signal recherché.
S'il n'y a pas de narration et pas de SCRIPT.md, sautez la génération vocale. Le BGM peut toujours s'exécuter si le storyboard a une ambiance musicale.
Le marqueur silencieux total canonique (partagé entre les workflows qui réutilisent ce modèle audio) : music: none dans le bloc YAML supérieur de STORYBOARD.md, pas de SCRIPT.md, et pas de signaux sfx: ni d'audio hôte. Cette combinaison marque le projet comme silencieux. Aucune étape audio ne s'exécute ; le moteur de rendu jette la piste audio lors du rendu. Tout ce qui s'écarte de ce signal (musique, voix, sons hôtes) déclenche le pipeline. Ce marqueur est défini par storyboard-format.md ; ne le changez pas par recette.
L'audio a une porte, mais elle ne bloque pas l'étape 4 : en mode collaboratif, l'étape 3.1 s'exécute en arrière-plan. Lorsque audio.mjs se termine, vérifiez le code de sortie. (a) Le script rédige audio_meta.json et sort 0 → l'étape 4 peut utiliser ses timings. (b) Le script échoue → lisez le message d'erreur, corrigez ce qui peut être corrigé (fichier manquant, voix inconnue) et réexécutez-le. En mode autonome, il s'exécute en arrière-plan pendant l'étape 4 ; si le fichier est absent à l'étape 6, émettez un avertissement et terminez. audio_meta.json partage son chemin avec tout le monde ; l'exécution en arrière-plan n'écrase pas un audio_meta.json en cours d'utilisation par une construction d'étape 5 — mais l'étape 5 n'en a pas besoin, donc ce n'est pas un problème.
Porte : audio_meta.json a été créé ou n'est pas nécessaire (silencieux total).
Étape 4 : Conception visuelle
Objectif : Transformer le plan de conception visuelle aux images animées réelles. L'orchestrateur ne crée pas de HTML ; il enrichit STORYBOARD.md avec une décoration visuelle (couleur d'arrière-plan, polices, environnement de mise en page, informations de blueprint) comme une demande de spécification pour le sous-agent de travail d'image.
Lisez les règles du sous-agent de travail d'image dans ../hyperframes-animation/rules/ et parcourez ../hyperframes-animation/blueprints-index.md. Ensuite, lisez le ../hyperframes-animation/blueprints/ réel pour chaque blueprint que l'étape 3 a étiqueté en tant que blueprint:. Pour chaque image de STORYBOARD.md, ajoutez (ou remplacez) les champs suivants sous visual_design: :
background: couleur d'arrière-plan ou dégradé à partir de la palette de la marque ou du préréglage. Peut inclure une texture ou un motif abstrait si le blueprint le suggère.typography: quelles polices utiliser (affichage / corps / accent) et leur taille/graisse approximative.layout: l'environnement de mise en page (centré, divisé, grille, focus, entonnoir). Laissez les détails de positionnement exacts au sous-agent.blueprint: écrasez toute étape 3blueprint:étiquette ici avec le nom complet du fichier, par exempleblueprints/flowchart.md. L'ébauche de l'étape 3 l'a peut-être déduit de l'intention narrative ; l'étape 4 le verrouille comme la spécification de rendu.scene: si l'image fait partie d'une séquence de scènes continues, un champscene:avec un nom partagé (par exemple, "introduction", "explication") pour que le sous-agent puisse maintenir la continuité visuelle entre les images de la même scène. Voirstoryboard-format.mdpour la forme exacte et les règles de fusion entre le frontmatter global et les images individuelles.asset_candidates: laissez vide sauf si un actif public/ réel existe. Tous les graphiques, diagrammes et icônes sont inventés en aval.- Laissez
actor:vide pour les explainers sans visage.
Marquez le dossier actif du sous-agent pour l'étape 5. Lorsque l'utilisateur a choisi sketch dans la boucle de révision ou que le mode autonome est actif, exécutez l'esquisse du blueprint principal (pour le sous-agent) : node ../hyperframes-animation/scripts/sketch.mjs --blueprint <blueprint> --out test-output.html --hyperframes . — notez le résultat visuellement (vous le montrerez à l'étape 6). Sinon, sautez l'esquisse.
Aucune porte explicite ici. La sortie de l'étape 4 est simplement un STORYBOARD.md enrichi qui, pour chaque image, a les champs ci-dessus.
Étape 5 : Images
Objectif : Rendre chaque image sous forme de page HTML de composition.
N'écrivez pas le HTML vous-même. Pour chaque image avec les champs de niche et le texte de script, appelez le sous-agent de travail d'image HyperFrames une fois par image. Le sous-agent lit frame.md (règles de design global), les règles d'animation (../hyperframes-animation/rules/), et le blueprint de cette image spécifique (../hyperframes-animation/blueprints/), puis écrit un fichier HTML dans compositions/frames/. Avant la première invocation du sous-agent, exécutez npx hyperframes reset-frame-agent pour garantir que des nouveaux contextes de caches d'apprentissage ne sont pas gaspillés.
Chaque image est une page HTML autonome avec CSS et SVG intégrés (pas d'actifs externes) qui représente l'image bouclée dans une superposition de navigateur. La position "vue" est automatique : soit un --scene <nom> partagé, auquel cas les images de la même scène maintiennent l'état partagé et la continuité, soit des images individuelles.
Les images sont écrites dans compositions/frames/ selon le format de nommage NN-<slug>.html. Le dossier de composition compositions/ s'initialise avec une commande d'assemblage de construction, mais les images individuelles peuvent être construites dans n'importe quel ordre.
Exécutez l'assemblage et la construction de l'aperçu : npx hyperframes assemble --hyperframes . puis npx hyperframes build --hyperframes . — cela construit compositions/index.html qui charge toutes les images et applique le skin de légende.
Porte : La construction de l'assemblage a réussi ; compositions/index.html existe.
Étape 6 : Rendu final
Objectif : Exporter la composition finale en vidéo et partager avec l'utilisateur.
npx hyperframes render --hyperframes . --out renders/video.mp4
Le rendu utilise STORYBOARD.md pour le séquençage (ordre et durée des images), audio_meta.json pour le timing de la narration/de la musique, le skin de légende de .hyperframes/caption-skin.html et le préréglage de frame.md pour le style. En mode collaboratif, il y a une porte d'approbation utilisateur : montrez l'aperçu (via renders/video.mp4) et posez la question unique — approuver pour publication finale, ou rejeter avec des retours de modification. En mode autonome, aucune question n'est posée ; le rendu est considéré comme final.
Le rendu est le résultat final, pas une ébauche. S'il est approuvé (ou en autonome), appelez play-video avec le chemin du fichier de rendu. L'étape du mode collaboratif pour cette résolution se termine lorsque le rendu est approuvé ou rejeté ; une modification redémarre à l'étape appropriée via la boucle de révision. En cas de rejet avec modification redémarrant, l'utilisateur spécifie l'étape.