vibe-video-producer

Production Vibe 知识大赏

Transformer un sujet de connaissance en une courte vidéo visionnable, avec les éléments de publication. Prend en charge la création complète, mais aussi la modification partielle des sous-titres, du rythme, de la musique, de la couverture ou du texte ; en cas de modification partielle, les éléments déjà confirmés sont conservés, et seule la partie demandée est livrée.

Préférences par défaut confirmées

Les valeurs par défaut se trouvent dans assets/defaults.json. Les exigences de l'utilisateur et les paramètres du projet existant sont prioritaires :

• Contenu de vulgarisation en chinois ; format paysage 16:9, 1920×1080, 30 ips ; durée générale de 30 à 45 secondes, déterminée en fonction du contenu et des temps forts de la musique, sans forcer une durée fixe.
• Pas de voix off ni de doublage. Les voix présentes dans la musique originale de l'utilisateur sont conservées ; « pas de voix off supplémentaire » ne signifie pas musique instrumentale seule.
• Grands caractères, phrases courtes, transitions rapides, accent visuel marqué. Fond sombre + vert menthe + orange chaud est un point de départ possible, mais le style circuit n'est pas imposé à tous les sujets.
• Utilisation de la musique fournie par l'utilisateur, à sa vitesse d'origine ; analyse des temps forts pour caler les coupures. Possibilité d'alterner des séquences de 4, 6 ou 8 temps, mais ajustement en fonction du rythme réel de la musique et du temps de lecture.
• Livraison complète : MP4, couverture paysage 4:3, couverture portrait 3:4, titre, description, sujets, et code source modifiable.
• Format de titre par défaut : Vibe知识大赏｜accroche ou question spécifique, puis ajout du nom de la connaissance si nécessaire.
• Le rendu est placé dans un projet indépendant du répertoire de travail courant ; le chemin absolu du fichier est fourni en sortie.

Prise en charge de la tâche

Vérifier d'abord les éléments suivants dans le projet actuel : project.json, storyboard, aperçu, fichier final et les commentaires déjà confirmés par l'utilisateur. Ne pas refaire les parties déjà terminées. Si le thème, la musique, les spécifications ou l'autorisation sont déjà clairs dans la conversation, ne pas redemander. Ne poser de questions que si une information manquante empêche réellement l'avancement, et dans ce cas, avancer d'abord sur les parties qui ne nécessitent pas cette information.

L'entrée minimale est le thème ; la musique peut être ajoutée plus tard. Sans musique, réaliser d'abord le texte et le storyboard, sans inventer de chemin musical ni prétendre que le calage est terminé. Lorsque l'utilisateur dit « à votre discrétion », utiliser les préférences par défaut pour prendre les décisions courantes de manière autonome. L'autorisation pour l'aperçu et l'exportation locale reste valide ; le rendu, les corrections et les nouvelles tentatives déjà autorisées ne nécessitent pas de confirmation répétée. Si l'utilisateur ne souhaite qu'un aperçu, s'arrêter à cette étape ; si l'exportation finale n'est pas encore autorisée, fournir une version révisable et ne demander confirmation qu'une seule fois. Ce processus n'inclut pas la publication automatique sur une plateforme.

Processus de production

1. Créer le projet. Utiliser scripts/create_project.py pour créer un projet indépendant, enregistrer le thème/la musique/les spécifications ; si un projet existe déjà, continuer directement. Le script ne fait que créer la structure du projet et enregistrer les entrées, il ne remplace pas la création, le calage ou le rendu.
2. Vérifier les connaissances. Privilégier les sources primaires, déterminer clairement la conclusion principale, les conditions d'application, un exemple calculable et les limites sujettes à confusion, les enregistrer dans sources.md. Les métaphores doivent être clairement délimitées ; ne pas transformer un théorème de physique en loi psychologique. La cohérence mathématique, des circuits, des unités et des signes (+/-) est requise.
3. Rédiger le texte court et le storyboard. Commencer par une question concrète, chaque plan porte un point fort, la conclusion revient à la question. Le titre, la description et les graphiques portent des informations différentes ; éviter d'expliquer plusieurs choses sur un même écran. Déterminer d'abord la charge de lecture, puis organiser le rythme ; ne pas compenser le manque d'impact par le nombre de plans.
4. Musique et planning temporel unifié. Pour le calage des temps forts, lire references/timing-and-render.md. Utiliser scripts/beat_plan.py analyze pour analyser les temps forts, vérifier le BPM, les ambiguïtés de demi-temps/double vitesse, et les attaques fortes. Se baser sur l'extrait choisi par l'utilisateur ou le résultat de l'écoute. Utiliser plan pour convertir le nombre de temps par plan, les mots-clés, les formules et les corrections en un planning temporel unifié (numéros de trame et temps). Les points de coupure de la musique, les scènes, les sous-titres et les effets dynamiques utilisent tous ce planning ; ne pas maintenir plusieurs jeux de secondes saisis manuellement.
5. Réaliser le projet et l'aperçu. Par défaut, privilégier le projet HyperFrames disponible localement. Si nécessaire, lire le hyperframes-vibe-169 disponible et ses contrats de composition, respecter les sous-compositions et les exigences de la timeline GSAP en pause. Utiliser assets/hyperframes-clock.js ou une correction de précision équivalente pour éviter que les six décimales de GSAP ne retardent les coupures d'une trame. En cas de changement de moteur, utiliser le projet existant de l'utilisateur, ne pas le refaire pour exécuter le skill.
6. Vérifier et terminer le rendu. Exécuter la validation du moteur, vérifier chaque plan, les limites des grands textes, la lecture aléatoire, les trames avant/après les temps forts clés, puis exporter localement avec l'autorisation existante. Utiliser scripts/audit_render.py pour vérifier les spécifications réelles du fichier final, le nombre de trames, le décodage complet et le décalage de la piste audio ; vérifier également image par image toutes les coupures et les effets dynamiques clés ; le décodage par script ne remplace pas l'inspection visuelle. En cas de problème, ne relancer que les vérifications concernées et la validation finale du fichier. Voir les détails dans la référence temporelle.
7. Couvertures et éléments de publication. Lire references/visual-and-delivery.md. Utiliser imagegen ou un modèle de couverture existant pour générer deux compositions indépendantes 4:3 et 3:4, vérifier les caractères chinois, les formules, les flèches, les marges et les proportions réelles en pixels. Générer un titre, une description et quelques sujets pertinents cohérents avec le fichier final.
8. Livraison. Après confirmation de l'existence des fichiers, fournir le MP4, les deux couvertures, le texte de publication et le répertoire du projet. Indiquer la durée, les spécifications et les limitations importantes. Si l'exportation a échoué, indiquer clairement « aperçu/code source terminé », ne pas prétendre que le fichier final est terminé. Conserver project.json, sources.md, storyboard.json, beat-map.json, les résultats de validation et le code source pour modifications ultérieures.

Combinaison avec d'autres skills

• hyperframes-vibe-169 : En cas d'utilisation de ce moteur, il est responsable de la composition de la structure, du lint, de l'aperçu, du rendu. Ses exemples de style ne remplacent pas le sujet actuel.
• lemo-opuscar : Utilisé lorsque l'utilisateur le demande ou que le sujet nécessite sa méthode de réalisation/style. Lire le style correspondant uniquement. La révision partielle d'un fichier final existant ne déclenche pas automatiquement un nouveau questionnaire de style.
• painted-animation / Joker-chichi/claude-mv-skill : Utilisé uniquement pour l'animation dessinée à la main, les clips musicaux avec paroles ou lorsque l'outil d'analyse des temps forts est nécessaire. Les vidéos de vulgarisation avec BGM ne nécessitent pas de fichier LRC de la part de l'utilisateur.
• imagegen : Responsable de la génération ou de la modification des couvertures bitmap. Enregistrer l'image finale dans le projet, conserver le prompt ; ne pas considérer la description du skill comme une API d'image directement appelable.
• openfilm / jianying-editor : Utilisé uniquement lorsque l'utilisateur le spécifie ou que le projet existant l'utilise réellement.

Il n'est pas nécessaire d'exécuter tous les skills en même temps pour chaque projet. Si un outil n'est pas disponible, vérifier d'abord l'environnement local existant et les alternatives viables ; ne pas installer silencieusement de grosses dépendances, ne pas remplacer le produit spécifié par l'utilisateur. Conserver les messages d'échec clairs, ne pas masquer les problèmes par des tentatives infinies.

Scripts auxiliaires

Les scripts fonctionnent avec Python 3 ; l'analyse audio et la vérification de synchronisation nécessitent NumPy ; FFmpeg/FFprobe peuvent être fournis via PATH ou un paramètre explicite. Pas de clé API nécessaire, pas de musique, de moteur de rendu ou de binaire tiers inclus. Utiliser le Python/Node découvert sur la machine ; ne pas considérer les chemins absolus d'anciens projets comme des dépendances génériques.

python scripts/create_project.py --workspace <répertoire> --slug <nom_court_du_sujet> --topic <sujet> --music <MP3_optionnel>
python scripts/beat_plan.py analyze --music <musique> --out <JSON_beat> --offset 0 --seconds 50 --ffmpeg <chemin_ffmpeg>
python scripts/beat_plan.py plan --grid <JSON_beat> --story <JSON_storyboard> --out <beat-map.json>
python scripts/audit_render.py --video <MP4> --plan <beat-map.json> --score <fichier_audio_final_optionnel> --out <audit.json>

Le format d'entrée du storyboard, les corrections manuelles des temps forts et la précision du rendu sont expliqués dans la référence temporelle. Les modèles de répertoire, les couvertures et la validation du texte sont expliqués dans la référence visuelle et de livraison. Les sorties numériques des scripts sont des preuves de vérification, pas une garantie automatique de justesse artistique ou scientifique.