sugarforever/studio-video-boring

Boring video

Orchestrer le développement du contenu et un projet HyperFrames progressivement affiné en une seule chaîne. Le contenu est établi avant d'être adapté pour la parole ou les visuels ; la direction de scène établit des preuves visuelles rendues, le storyboard planifie des images constructibles, et HyperFrames gère la production et la revue jouable.

Prise en charge

Résoudre les décisions existantes à partir de la demande et des fichiers du projet. Classer d'abord l'entrée :

• Piloté par le contenu : recherche, évaluation, analyse, opinion, tutoriel, actualité, profil, ou autre œuvre narrée dont la valeur dépend d'un argument complet et qui peut également devenir un article de blog.
• Production directe : script verrouillé, promotion de produit, démonstration UI, pièce dirigée par la musique, court graphisme animé, ou autre œuvre qui n'a pas besoin d'un article pour établir son sens.

Résoudre les paramètres par défaut de production réutilisables à partir des directives explicites du projet, de la série, de la marque ou de l'équipe avant de demander des choix ponctuels. Créer le workflow BRIEF.md lors de la prise en charge et y enregistrer chaque défaut adopté, sa source et sa portée afin que chaque compétence en amont puisse le lire avant de prendre des décisions de contenu ou de voix ; reporter le même brief dans le projet HyperFrames lors de sa création. Une demande en cours remplace un défaut réutilisable. Les défauts peuvent couvrir la structure récurrente, la langue et la voix, la vérité de design, les ratios de couverture, les cibles de publication ou la présentation terminale, mais ne doivent pas être déduits d'un profil personnel indisponible. Garder les conventions spécifiques au projet dans les fichiers du projet plutôt que de les universaliser dans cette compétence.

Pour un travail piloté par le contenu, localiser le premier artefact de contenu approuvé manquant. Un article fourni ne compte que lorsque l'utilisateur confirme explicitement qu'il s'agit du maître du contenu. Le stocker ou l'adapter sous content/ARTICLE.md avec cette provenance :

---
source: externe
origin: <URL ou chemin>
origin_revision: <révision Git, digest source ou horodatage de capture>
status: approuvé
approved_at: AAAA-MM-JJ
approved_digest: sha256:<digest>
voice:
  language: ...
  skills: []
  documents: []
  unavailable: []
  status: resolved | assumed
---

Calculer approved_digest comme SHA-256 du fichier complet après avoir supprimé uniquement la ligne approved_digest:. Ne pas fabriquer un article juste pour satisfaire la chaîne pour un travail en production directe ; charger /hyperframes et laisser sa couche d'intention actuelle gérer la prise en charge et la sélection du workflow.

Lorsque cette prise en charge crée ou adapte content/ARTICLE.md, lire references/markdown-review.md et présenter ce Markdown faisant autorité avant de démarrer /to-spec-beats.

Pour un travail piloté par le contenu, poser une question compacte pour tout choix de production manquant :

1. Présentation : sans visage, images d'archives, capture d'écran, tête parlante ou média mixte ?
2. Collaboration : revues de storyboard ou production exécutée par l'agent avec prévisualisation finale ?
3. Voix : voix HyperFrames, TTS ListenHub, enregistrement utilisateur ou pas de narration ?
4. Design : vérité de design existante, direction nommée ou direction proposée par l'agent ?
5. Publication : quelles couvertures, adaptations de plateforme, variantes blog/article, sous-titres ou copies sociales sont demandées, le cas échéant ?

Enregistrer les réponses et les paramètres de production adoptés dans le workflow BRIEF.md. Dans le travail exécuté par l'agent, proposer et enregistrer une direction de design lorsque l'utilisateur la laisse ouverte. Pour un travail en production directe, passer les paramètres résolus et toute demande de publication dans le BRIEF.md géré par /hyperframes plutôt que de répéter les questions de la chaîne de contenu.

Chaîne

Avant que /to-scenes ne démarre le projet rendable, lire references/hyperframes-review-project.md. Transmettre son identité de projet et son état de révision via SCENES.md, STORYBOARD.md et le manifeste du projet HyperFrames ; les compétences en aval consomment ces artefacts plutôt que cette référence interne.

Pour un travail piloté par le contenu, commencer au premier artefact manquant ou explicitement révisé :

1. /develop-topic → content/RESEARCH.md, rapports d'expérimentation et content/TOPIC.md approuvé
2. /to-article → content/ARTICLE.md approuvé
3. /to-spec-beats → BEATS.md
4. /to-narration → NARRATION.md
5. /to-scenes → SCENES.md, projet HyperFrames partagé et preuves visuelles rendues référencées depuis le Markdown
6. /to-storyboard → STORYBOARD.md natif HyperFrames
7. /to-video → continuation de la production et revue Studio dans ce projet

Terminer le critère d'achèvement de chaque compétence avant de passer à la suivante. Un résultat en aval revient à l'artefact qui possède la décision, puis se propage vers l'avant.

Lorsque des sorties de publication ont été demandées pour un travail piloté par le contenu, ouvrir une branche de publication après que l'article, la narration et la direction de scène sont stables. Dériver la direction de couverture de la vérité de design approuvée et des preuves de scène ; dériver les copies de plateforme, les adaptations blog/article, les sous-titres et les copies sociales du contenu et de la narration approuvés. Pour un travail en production directe, ce wrapper possède la même branche à côté de /hyperframes : l'ouvrir après que la source verrouillée et la direction de design HyperFrames sont stables, en dérivant les copies de cette source et les couvertures de cette direction de design. Enregistrer les sorties demandées, les digest sources, les plateformes ou ratios cibles et les chemins de sortie dans PUBLISHING.md. La production vidéo peut continuer pendant que cette branche est préparée, mais aucune branche ne peut inventer silencieusement de nouvelles affirmations ou une identité visuelle concurrente.

Lorsque l'utilisateur commence avec un article complet approuvé, recalculer son digest avant de commencer à /to-spec-beats. Lorsqu'il commence avec des artefacts ultérieurs pilotés par le contenu, recalculer chaque digest d'artefact présent, exiger que chaque enfant porte le digest actuel de son parent immédiat, et vérifier que la chaîne remonte à un content/ARTICLE.md approuvé ; puis reprendre à la première étape manquante. L'existence d'un artefact seul n'est pas un état reprisable. Les entrées en production directe contournent cette chaîne de contenu et commencent à /hyperframes ; ne jamais réinterpréter un script verrouillé comme une permission d'inventer un article, une thèse ou des affirmations.

Transfert

Présentation et workflow sont des décisions séparées. Recueillir l'intention de présentation sans sélectionner un workflow de mémoire. Pour un travail piloté par le contenu, /to-video lit le contrat actuel de /hyperframes et effectue l'acheminement. Le travail en production directe reste dans /hyperframes ; ce wrapper ne reprend que pour produire toute branche de publication demandée.

Terminé

La planification pilotée par le contenu est terminée lorsque les artefacts de contenu approuvés applicables, les quatre artefacts de planification et les preuves visuelles référencées s'accordent et satisfont leurs propriétaires. Une exécution du wrapper en mode contenu est terminée lorsque /to-video continue le projet HyperFrames révisé avec la branche vocale confirmée à travers le workflow de production sélectionné, que HyperFrames Studio possède la revue de la timeline jouable, et que toute branche de publication demandée a des sorties liées à la source enregistrées dans PUBLISHING.md. Une exécution en production directe est terminée lorsque son workflow /hyperframes possède la revue jouable et que ce wrapper a enregistré toutes les sorties de publication demandées dans PUBLISHING.md.