Installation des plugins : Avant les commandes de configuration ou de mise à jour, suivez les règles d'installation des plugins lorsque ce skill se trouve dans un plugin HyperFrames. Les installations autonomes conservent les instructions de mise à jour ci-dessous.
D'abord, maintenez ce skill à jour — confirmez avec l'utilisateur avant d'exécuter :
npx hyperframes skills update faceless-explainer. Une opération rapide sans effet si tout est à jour ; sinon, il met à jour ce skill ainsi que les skills du domaine central dont il dépend avant de les utiliser.
media-use : Avant de rechercher des fichiers audio/images/logos, appelez
/media-usepour trouver la BGM/les effets sonores/les images dans le catalogue HeyGen et les logos de marque depuis leurs sources officielles. Exécutez d'abord--adoptpour enregistrer les ressources existantes. 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.
Explainer sans visage vers HyperFrames
Utilisez ce skill pour transformer un corps de texte en vidéo explicative : choisissez un système de design, planifiez un récit pédagogique et construisez-le image par image dans HyperFrames. Sans visage signifie que chaque visuel est inventé en aval — il n'y a pas d'étape de capture ni d'inventaire de ressources 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 et sans site à capturer. 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 de routage, 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 le flow/storyboard de BRIEF.md dérivent le mode qui régit les portes des Étapes 3/4/6. Effectuez chaque étape vous-même, sauf l'Étape 5 où vous déléguez un sous-agent par image. Ne mettez pas de règles de design ou de mouvement ici ; elles résident dans le sous-agent de travail des images, les ../hyperframes-animation/rules/ + ../hyperframes-animation/blueprints/ locaux de ce skill, et hyperframes-creative.
Flux de travail : Étape 0 configuration → hyperframes.json ; Étape 1 brief → 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 : Arriver avec un brief confirmé, créer le projet HyperFrames et rendre le brief durable.
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 posez aucune question — 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 re-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 cette route (../hyperframes/references/routes/faceless-explainer.md), et remet le brief verrouillé. Les demandes de modification ignorent tout cela — allez effectuer la modification.
Initialisez uniquement si hyperframes.json est manquant. Nommez <projet> à partir du sujet en kebab-case, par exemple compound-interest-explained ; 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'initialisation, 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 de l'appelant.
Écrivez BRIEF.md immédiatement après l'initialisation (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 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 ignorée) et retourne les squelettes à partir desquels l'Étape 3 est rédigée. 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 la Configuration — exécutez npx hyperframes auth status et relayez sa sortie textuellement. Il indique si la voix/BGM utilisera HeyGen ou des 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 ; 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.
Porte : hyperframes.json et BRIEF.md existent ; les réponses basées sur des préférences ont été enregistrées (contrat de brief § 2) ; l'état de connexion a été affiché (connecté, ou continuant hors ligne).
Étape 1 : Brief (aucune capture)
Objectif : Intégrer le texte de l'utilisateur dans le projet comme source d'information. Il n'y a aucune capture de site web et aucune ressource réelle — c'est un explainer sans visage.
Enregistrez l'entrée complète de l'utilisateur textuellement, puis créez le package de capture synthétique à la main :
capture/extracted/visible-text.txt— l'article complet / les notes / le sujet / le brief, 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 brief. Laissezcolors/fontsvides à moins que l'utilisateur n'ait 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 uniquement si le brief manque de cela, et stockez la réponse pour l'Étape 3.
N'exécutez pas npx hyperframes capture (il n'y a pas d'URL). Ne créez pas asset-descriptions.md et ne peuplez pas 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 dans 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 et le public de l'explainer 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 parmi les vitrines de la couche d'intention — utilisez-le ; la décision vous appartient uniquement lorsque le brief est silencieux. Ensuite, vous prenez la seule décision — quel préréglage : lisez ../hyperframes-creative/references/design-spec.md et parcourez ../hyperframes-creative/frame-presets/ ; choisissez le préréglage dont le look correspond le mieux au sujet, au ton et au public. Ensuite, 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 remix 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 (sort avec le code 1 sur un mappage cassé). Procédez dès qu'il sort avec le code 0 — aucune é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 et expédiable. Uniquement lorsque l'utilisateur a nommé des couleurs/polices de marque, ajoutez-les à tokens.json avant d'exécuter, et ajustez frame.md à la main après uniquement si un mappage en a vraiment besoin.
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 brief § 2).
Étape 3 : Storyboard et Script
Objectif : Transformer le texte en un plan d'enseignement approuvé image par image.
Lisez ../hyperframes-creative/references/story-spine.md (langage d'accroche, valeur avant preuve, storyboard comme proposition, visuels traçables jusqu'à 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 la structure de l'explainer (concept / tutoriel / listicle / histoire), la stratégie d'accroche, les techniques de clarté, les rythmes émotionnels, le mappage type-énumération et VO_MODE. La séquence de la 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 temps, écrivez la voix off dans la forme qu'implique son blueprint candidat et étiquetez cet ID blueprint : candidat lorsqu'il convient. La vérité pédagogique décide toujours quels temps existent — ne forcez jamais un temps à s'adapter à un blueprint, et n'inventez jamais un temps 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 de ressources : laissez asset_candidates vide à moins que l'utilisateur n'ait 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 la rédaction, exécutez le passage 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 esquisses 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 brief § 1) : en mode autonome, il n'y a rien à demander — publiez le même résumé comme un avertissement et procédez ; les esquisses se fondent dans la construction, et l'aperçu final avec sa seule question arrive à 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 avertissement).
Étape 3.1 : Audio
Objectif : Générer la narration, les horodatages des mots, la musique et les métadonnées audio à partir du script approuvé.
Démarrez 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 revient automatiquement à une solution de repli.)
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 drapeau. Les ID de voix sont spécifiques au fournisseur ; résolvez par rapport au 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, et dites laquelle vous avez utilisée ; omettez --voice uniquement lorsque ni l'une ni l'autre 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 <voix-id> &
Le script audio gère la narration, les horodatages des mots, la recherche de BGM dans la bibliothèque musicale d'HeyGen et les métadonnées de timing. L'ambiance de la BGM provient du champ music: du storyboard. Cela utilise l'API Audio d'HeyGen pour la récupération, pas la génération, et la même identité ~/.heygen que pour le TTS. Pour les détails du fournisseur, lisez ../media-use/audio/references/tts.md. Lorsque les propres outils de l'application hôte fabriquent la musique ou un effet sonore, placez le fichier dans assets/ et listez-le dans le fichier audio_meta.json marqué "source" : "host" : la 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 durée>, "source": "host" }. Chaque passage audio conserve ceux-ci, et une image avec un son hôte n'a pas de repère recherché.
S'il n'y a pas de narration et pas de SCRIPT.md, sautez la génération de la voix. La BGM peut toujours s'exécuter si le storyboard a une ambiance musicale.
Le marqueur entièrement silencieux 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 repères sfx : ni d'audio hôte. Cette combinaison marque le projet comme silencieux —