DoubleWhopperS/video-craft-playbook

Video Craft Playbook

Ceci est un manuel d'artisanat vidéo pour l'Agent de codage, qui vous aide à voir clairement avant de commencer : pour réaliser une vidéo de qualité, quelles capacités visuelles sont à votre disposition ; pour chaque capacité, dans quel type d'expression elle est valable, où elle échoue et ce qu'elle coûte ; comment les cas précédents les ont combinées et quels pièges ils ont rencontrés.

Ce manuel ne dicte pas quel outil choisir. Il n'y a pas d'outil par défaut, ni de recette fixe : pour un même style visuel ou un même type de vidéo, selon les contraintes (budget, documents disponibles, durée, nécessité de physique réaliste, présence d'acteurs réels, nombre de révisions), la combinaison appropriée peut être totalement différente. La sélection relève de votre planification ciblée pour la tâche en cours ; ce manuel ne fournit que des critères de jugement.

Comment l'utiliser

1. Avant de commencer : vérifier les retours en souffrance

python3 ~/.agents/skills/video-craft-playbook/scripts/playbook.py status

status liste les fiches de cas non encore distillées (cases/inbox/), les fiches de capacités ayant dépassé leur date de révision, et le nombre d'entrées dans la couche d'attente (references/lessons-backlog.md) ; lorsqu'un seuil de consolidation est atteint, il invite à lancer consolidate. L'inbox ne contient que les fiches qui, lors de la dernière évaluation, ont été jugées dignes d'être conservées mais qui n'ont pas encore été distillées. S'il y a des retards, prenez d'abord quelques minutes pour les distiller dans le manuel (voir étape 4) avant de commencer une nouvelle vidéo ; si le temps est limité, informez au moins l'utilisateur du nombre d'entrées en attente.

2. Planification : d'abord décomposer les besoins d'expression, puis faire correspondre les capacités

Ne commencez pas par « quel outil utiliser », mais par « sur quoi repose chaque élément de cette vidéo » :

1. Décomposez la vidéo finale en éléments : sujet, environnement, mouvement, plan, texte et graphiques, texture, son, rythme.
2. Pour chaque élément, répondez aux questions dans references/task-lenses.md : d'où vient sa « vérité », nécessite-t-il une précision image par image, combien de révisions, peut-on payer, à quelle vitesse doit-on sortir la vidéo.
3. Dans references/capability-atlas.md, trouvez au moins deux capacités réalisables pour chaque élément : parcourez d'abord le tableau récapitulatif en haut pour sélectionner des candidats, puis lisez les fiches correspondantes ; après comparaison, sélectionnez et notez la raison du choix et les alternatives abandonnées. Les candidats doivent inclure des « documents réels trouvables » (groupe H de l'atlas : index local de documents, bibliothèques ouvertes) ; ne comparez pas seulement la génération et le code. La hiérarchie des sources et la chaîne « texte → description de plan → recherche → vérification de licence → composition » sont détaillées dans la question 11 de task-lenses et dans craft-lessons L60.
4. Lorsque plusieurs capacités sont combinées, définissez d'abord les interfaces : autorité temporelle, fréquence d'images, coordonnées et caméra, alpha, couleur, bus audio (section 3 de task-lenses).
5. Avant de commencer, rédigez un « tableau de répartition des capacités » (modèle dans la section 4 de task-lenses), montrez-le à l'utilisateur dans la première réponse, puis exécutez-le sans attendre confirmation.

Pour les tâches de montage (documents déjà fournis, principalement montage et post-traitement), consultez la section 6 de task-lenses : les techniques sont décomposées en composants universels et en règles « signal → technique », voir references/editing-grammar.md ; les signaux et champs à produire au niveau de la compréhension sont détaillés dans references/edit-signals.md. Ces deux documents sont actuellement des déductions ; utilisez-les comme point de départ et jugez à la fin s'ils peuvent être mis à niveau.

La grammaire du mouvement au niveau du plan (ouverture, transition, carte de texte, apparition d'interface, fermeture) peut être consultée, après avoir choisi Remotion, via l'index de recettes externes references/shot-vocabulary.md : cherchez des fiches par créneau fonctionnel et énergie, puis lisez la fiche complète et le code de démonstration dans le dépôt ; il provient du contexte des bandes-annonces de produits, non vérifié localement.

references/composition-patterns.md enregistre comment les cas historiques ont réellement combiné les capacités ; il peut être utilisé pour inspirer des idées et estimer les coûts. Ce sont des solutions pour les tâches de l'époque, pas des modèles : avant de les copier, vérifiez que vos contraintes sont identiques.

3. Exécution : savoir-faire et pièges

• Les pratiques valables pour tous les outils (validation en premier, une seule autorité temporelle, l'image comme pure fonction de t, calques de révision, les trois éléments payants, normes audio, etc.) se trouvent dans references/craft-lessons.md.
• Les pièges connus, regroupés par outil, se trouvent dans references/pitfalls.md. Avant d'utiliser un outil, parcourez d'abord son groupe.
• Les modalités d'appel spécifiques aux outils sont régies par le Skill correspondant (chaque fiche de l'atlas indique le point d'entrée) ; ce manuel ne répète pas leurs détails de commandes.

4. Fin : d'abord juger s'il faut consolider, puis décider de réécrire

Le manuel se développe grâce aux cas, mais tous les cas ne doivent pas être réécrits : seules les informations qui se répètent avec des entrées existantes ou qui ne sont valables que pour un seul cas dilueraient le manuel. Lors de la livraison de la vidéo (ou de l'abandon de la tâche), selon la section 1 de references/writeback.md, listez les candidats, passez les trois portes (réutilisable, non déductible, coût), et ne comptez que ceux qui passent avec des preuves ; si une information peut être intégrée dans une entrée existante, n'en créez pas de nouvelle.

• S'il y a une ou plusieurs entrées valables : suivez la section 2 de writeback : new-case pour créer une fiche de cas → distillez dans le fichier correspondant (si la couche permanente est pleine, écrivez dans references/lessons-backlog.md) → check → close. Si vous n'avez pas le temps de distiller, laissez la fiche dans inbox ; status vous le rappellera la prochaine fois.
• Aucune entrée valable : sautez la réécriture, ne créez pas de fiche de cas, n'enregistrez pas dans le registre. Ignorez également si l'utilisateur dit de ne pas réécrire.

Dans la note de livraison finale, écrivez une ligne Réécriture du Playbook indiquant la conclusion : quels fichiers ont été modifiés, ou fiche de cas en attente de distillation, ou « Ignoré : ».

Principe de neutralité (à respecter lors de l'écriture et de l'utilisation du manuel)

• Les fiches de capacités n'écrivent que des faits : ce qu'elles maîtrisent, ce qu'elles ne maîtrisent pas, le coût, la certitude, la source de validation. N'écrivez pas de mots de classement tels que « par défaut », « préféré », « recommandé », « priorisé » ; playbook.py check les interceptera.
• L'ordre des fiches suit la catégorie de média, pas le classement.
• Si un outil est bien utilisé dans un cas, notez-le comme « sous quelles contraintes et pourquoi cela a fonctionné », ne le transformez pas en « utilisez-le pour ce type de vidéo ».
• Les capacités non vérifiées dans des cas locaux doivent également être incluses, avec la mention « installé non vérifié » ou « déduction » ; ne les omettez pas parce qu'elles n'ont pas été utilisées, et ne les exagérez pas parce qu'elles l'ont été.
• La longueur est également un parti pris : les champs des fiches ont une longueur fixe ; les listes de fonctionnalités et les détails d'implémentation n'entrent pas dans les fiches. Un outil plus utilisé n'occupe pas plus d'espace pour autant.
• Si une entrée existante introduit un parti pris (par exemple, une note d'espace de travail indique « choisir par défaut X »), lors de la réécriture, transformez-la en une phrase conditionnelle : sous quelles contraintes il est approprié.