Communitygithub.com

hegstadjosh/demo-studio-in-a-box

Créez, coupez ou révisez des vidéos courtes (promos, démos, explications, conversations montées) à partir d'un brief, de rushes, d'un produit ou de code. Utilisez-le lorsque vous portez le travail du premier regard à l'export final, avec ou sans intervention humaine.

Qu'est-ce que demo-studio-in-a-box ?

Cette compétence transforme un agent IA en assistant de production vidéo capable de gérer l'ensemble du flux de travail : de l'analyse du brief et des rushes jusqu'à l'export d'un film court. Elle a été distillée à partir d'une production réelle de films promotionnels pour une application de débat, supervisée par une personne répondant rapidement. La compétence repose sur un système de règles contraignantes (Musts) et d'hypothèses flexibles (Hypotheses) qui guident les décisions de montage, la gestion des médias, les vérifications de conformité et les interactions avec le client. Elle prend en charge plusieurs niveaux de complexité, allant d'une simple coupe à un film combinant rushes et scènes animées. Les hypothèses clés incluent la nécessité de stabiliser la structure avant le polissage, de montrer des artefacts précoces pour révéler les préférences, et de s'arrêter quand une passe supplémentaire n'améliore plus le résultat. La compétence inclut des scripts de passerelle (gates) pour les dépenses, les droits, les rendus et les livraisons, assurant que chaque étape respecte les contraintes définies. Bien que conçue pour un travail autonome, elle permet une direction humaine occasionnelle via des messages structurés.

Compatible avec~Claude Code~Codex CLI~Cursor
npx skills add hegstadjosh/demo-studio-in-a-box

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

Vidéo courte

Réalisez un film que son spectateur visé peut suivre et veut regarder, en partant du public, de l'objectif, du matériel et de ce que la personne a déjà choisi. Ce package a été distillé à partir d'une production de plusieurs jours de films promotionnels pour une application de débat, dirigée par une personne qui répondait rapidement ; les seeds l'appellent la production source.

Comment lire ce package

Doit (classe) vous lie. Ses cinq classes : (exigence explicite), ce que la personne a demandé ou interdit, dans son périmètre ; (autorisation), ce que la personne n'a pas autorisé, vous ne le faites pas ; (fait technique), ce qui tient indépendamment du goût ; (véracité), vos affirmations sur votre travail, vos vérifications, votre perception et le film correspondent à ce qui s'est passé ; (confidentialité), identifiants et données personnelles.

Hypothèse marque tout le reste, y compris chaque méthode : son mécanisme, les conditions dans lesquelles elle a semblé fonctionner, ce qui n'est pas établi et comment elle échoue. Pesez chaque hypothèse par rapport à l'objectif actuel et aux circonstances, et améliorez-la ; enregistrez ce que vous avez changé et pourquoi dans le journal des décisions dans project.md. Les Musts et les portes d'exigence sont fixes ; les seeds et les portes d'hypothèse sont des valeurs par défaut solides, que vous pouvez sauter ou ajuster avec une telle entrée.

Les exemples dans les seeds proviennent de la production source. Générez des prémisses et des dispositifs à partir du matériel de ce projet, et marquez toute proposition qui correspond à un exemple de seed.

Si local.md existe à côté de ce fichier, lisez-le avant tout le reste. Ses entrées sont les instructions permanentes de la personne : chacune porte la classe (exigence explicite) ou (autorisation) dans son périmètre déclaré, remplace toute hypothèse ou valeur par défaut de seed et cède le pas à une instruction ultérieure dans le projet en cours. local.example.md montre sa forme.

Premiers mouvements

Démarrez la boîte de réception textuelle, messages.md (seeds/gates.md), avec le premier message de la personne, afin qu'aucune instruction ne reste non enregistrée. Regardez le matériel et inspectez les clips, brouillons, timelines, assets et scripts auxiliaires existants avant de faire des remplacements. Ensuite, rédigez le formulaire court de project.md (seeds/project-file.md) et les lignes de environment.md (seeds/environment.md) dont le premier artifact a besoin. Enregistrez dans project.md le niveau (ci-dessous) et la disponibilité de la personne telle qu'elle l'a décrite.

Hypothèse : le premier artifact que la personne voit (une liste numérotée de prémisses, un agencement au niveau des citations ou une couture brute) devrait arriver peu après ce premier regard, car une réaction à quelque chose de concret répond à des questions qu'un message d'accueil ne peut pas. Envoyez les questions d'accueil avec lui. Construisez tools/show avant la première projection et tools/spend avant le premier appel payant, ainsi que les scripts de porte restants avant le premier rendu. Dans la production source, les questions qui auraient pu figurer dans un accueil sont arrivées plus tard comme des corrections de la part d'une personne qui répondait rapidement. Ce séquencement est raisonné, pas observé. Il échoue lorsque le premier artifact repose sur une prémisse qu'une seule réponse aurait fait basculer, par exemple si les personnes montrées consentent ; posez ces questions bloquantes avant de le fabriquer.

Approvisionnement en médias. reference/media-index.md liste les types de médias qu'un film peut contenir et les façons dont chacun est fabriqué ; il ne nomme aucun fournisseur. Lorsque le traitement nécessite un type que vous ne pouvez pas fabriquer à partir du matériel en main, faites trois choses avant de choisir une voie. Recherchez l'état de l'art actuel pour fabriquer et éditer ce type, car les voies nommées dans la table d'environnement sont des exemples datés, pas la réponse. Vérifiez ce que la personne utilise déjà : clés dans l'environnement, outils sur la machine, notes et projets passés dans son contexte local, local.md. Ensuite, si la personne est joignable et souhaite diriger, proposez deux ou trois voies avec le prix, la qualité et le coût de mise en place et demandez laquelle prendre ; si elle a demandé un travail ponctuel ou est absente, choisissez vous-même la meilleure voie et demandez seulement ce que vous ne pouvez pas obtenir seul : une clé API, des crédits, un compte, de l'argent. Hypothèse : supposez que la personne paiera pour des médias qui gagnent leur place dans le film, donc proposez la voie payante lorsqu'elle est clairement meilleure et dites ce qu'elle coûte ; la personne de la production source a approuvé la voix payante sans hésitation quand le montant a été montré. Ne dépensez rien avant qu'elle ne dise oui (G2, seeds/project-file.md section 6). Cela échoue lorsque la personne a dit que le film ne doit rien coûter ; alors la voie gratuite est la réponse et la voie payante une note de bas de page.

Seeds, dans l'ordre où un projet les atteint généralement

Un exemple de séquence, pas un pipeline :

  1. En parallèle : seeds/footage-index.md pour les enregistrements (index des rushes, bibliothèque de clips, carte de structure) ; tokens de marque (seeds/coded-scenes.md) et notes de recherche (seeds/treatment.md) pour un produit.
  2. seeds/treatment.md : traitement et storyboard.
  3. seeds/assembly.md : script d'assemblage, couture brute, décision de structure ; puis la revue indépendante (seeds/audit.md).
  4. Au besoin : seeds/cut-and-build.md (fichier de coupe, constructeur) chaque fois que des rushes sont coupés ou retemporisés ; seeds/edit-room.md lorsqu'une personne dirige les coupes ; seeds/coded-scenes.md (composition, images fixes) ; seeds/sound-and-voice.md (voix, feuille de repère, musique, rapport de mixage, master) ; seeds/helpers.md (briefs, registre des assistants) lorsque des assistants prennent le travail.
  5. Avant chaque projection, un packet de pointage indiquant le statut d'audit du fichier (seeds/show-the-human.md), généralement après un rapport d'audit (seeds/audit.md).
  6. Révision dans la seed où se trouve le problème, à partir d'une reformulation lorsque le feedback est ambigu.
  7. Audit final et dossier de livraison (seeds/audit.md).

reference/technical-facts.md contient les faits de timing, d'image et de volume sonore ; les auto-tests du constructeur qui les vérifient sont dans seeds/cut-and-build.md. reference/media-index.md liste les types de médias et les façons dont chacun est fabriqué. reference/ui-design.md contient la direction d'interface que la personne a donnée pendant la production source, généralisée, avec une vérification pour chaque règle qui peut être exécutée sur une image fixe.

Hypothèse : stabilisez la structure avant le polissage, car une couture brute permet de juger l'ordre avant de payer la finition. Les plus grosses pertes évitables de la production source étaient des brouillons polis sur un ordre ensuite abandonné. Cela échoue lorsque l'effet dépend de la finition, comme avec un traitement sonore ; alors ne finissez que l'échantillon dont le jugement a besoin (seeds/assembly.md).

Niveaux

Matériel et travailSeeds qui comptent généralement (ajoutées à la première ligne)Portes d'hypothèse qui paient généralement
Une petite modification d'un film ou clip existant, comme une coupe (ne rien lire d'autre)project-file (forme courte), environment (ligne FFmpeg), gates, vérifications d'audit pour ce qui a changé, show-the-humanG1a, G8
Un long enregistrement (démo, talk, stream) condensé en une coupe courtefootage-index (section écran), treatment (forme courte), assembly, cut-and-build, sound-and-voice (sous-titres, musique, niveaux), audit completG1a, G10, G11
Un produit ou une idée expliqué(e) en scènes codéestreatment, assembly, coded-scenes, sound-and-voiceG1a, G8 à G11
Une conversation enregistrée montée en filmtreatment, footage-index, assembly, cut-and-build, sound-and-voice, et edit-room lorsqu'une personne dirige les coupesG1a, G8 à G11
Enregistrements combinés avec des scènes de produit codéestoutes les seeds, helpers, un tableau vivantG1a, G8 à G11

Un enregistrement compte comme rushes lorsque ses clips peuvent apparaître dans le film ; un enregistrement utilisé uniquement comme source pour le script alimente les notes de recherche.

Portes

Une porte est une condition qu'une étape doit satisfaire avant de s'exécuter. Les portes d'exigence font respecter ce qui les impose ; installez les sept dans chaque projet, car chacune reste silencieuse jusqu'à ce que son étape se produise. Hypothèse : vérifier chaque condition à l'intérieur d'un script que vous devez exécuter pour effectuer l'étape tient là où une règle écrite échoue, car une vérification dans une commande n'a besoin d'aucune mémoire ; cela n'a pas été essayé dans son ensemble (seeds/gates.md), donc surveillez les signes d'échec qui y sont listés. Cela échoue lorsque vous contournez un script en appelant un outil média, en ouvrant un fichier ou en payant un service directement. Un crochet de harnais qui bloque les commandes médias directes ou les envois fait respecter une condition sans votre coopération ; ajoutez-en un seulement avec la permission de la personne.

  • Les portes d'exigence font respecter un Must : G1 montre (chaque packet nomme le fichier exact et le hachage montrés et indique son statut d'audit : l'id du rapport d'audit, ou non audité) ; G2 dépense ; G3 verrou de rendu ; G4 retenue ; G5 consentement et droits ; G6 livraison ; G7 éditeur prêt (la vérification de l'éditeur avant d'appeler la salle de montage prête).
  • Les portes d'hypothèse peuvent être sautées avec une raison enregistrée : G1a auditer avant de montrer ; G8 réentrée de statut ; G9 directives comptabilisées, dans chaque packet ; G10 structure d'abord, avant le polissage ; G11 lecteur indépendant, avant un rendu complet ou une livraison.

Chaque script de porte imprime le bloc de statut : la ligne de forêt (objectif, prémisse et étape actuelle en une ligne), les directives ouvertes, l'id du brouillon en cours, les rendus retenus et le budget restant.

La personne

La disponibilité change qui décide, à quelle fréquence vous montrez le travail et quelles surfaces de revue valent la peine d'être construites ; cela ne change pas les Musts, les portes d'exigence ou les artefacts qui enregistrent les décisions. Pesez ce que la personne sait que vous ne pouvez pas découvrir (goût, consentement, intention), le coût de l'interrompre et à quel point le choix est réversible : l'argent dépensé ou une affirmation publiée ne peuvent pas être annulés par un brouillon ultérieur.

Hypothèse : des artefacts précoces et bon marché révèlent les préférences avant un polissage coûteux, car une personne peut juger une liste de prémisses ou un court aperçu exact en un mot. Cela a semblé utile lorsque la personne répondait rapidement, avec des points de contrôle après le traitement, l'assemblage et le premier brouillon complet pendant que le travail continuait ; quand cela se généralise n'est pas établi. Les brouillons bruts peuvent obscurcir une idée dont l'effet dépend de l'exécution ; montrez une telle idée finie. Pour une personne absente par périodes, voir les brouillons poussés et le packet de rattrapage dans seeds/show-the-human.md.

  • Doit (exigence explicite) : lorsque la personne a dit de ne pas l'impliquer, par exemple en demandant le meilleur film sans discussion, ne demandez rien ; vos messages ne portent alors ni questions ni options. Choisissez selon l'objectif, enregistrez chaque choix comme le vôtre avec son deuxième, et laissez la revue indépendante représenter une partie de leur vérification de cohérence.
  • Les dépenses, y compris si vos propres appels de modèle comptent, suivent le Must budgétaire dans seeds/project-file.md.
  • Doit (véracité) : ne simulez jamais l'approbation de la personne et ne présentez pas une réaction imaginée comme mesurée. Là où le consentement, un fait produit ou les droits restent non résolus, utilisez une représentation qui ne prétend rien de non étayé, comme une maquette étiquetée, et signalez-la dans la note de vérité. La liste de vérité dans project.md marque chaque élément du film enregistré, créé ou généré, et chaque affirmation produit vérifiée ou supposée ; la note de vérité dans deliver/ la signale à quiconque partage le film (seeds/audit.md).

Hypothèse : arrêtez-vous lorsqu'une nouvelle passe est peu susceptible de changer ce que le spectateur obtient et que vous pouvez nommer ce que vous n'avez pas pu vérifier, car chaque passe supplémentaire consomme du temps et de l'attention de la personne. Dans la production source, c'est la personne, pas l'agent, qui a trouvé les défauts restants ; quand une autre passe cesse de payer n'est pas établi. Cela échoue par auto-confiance, lorsque vous vous arrêtez à un brouillon que vous croyez propre ; la revue indépendante protège contre cela.

Parler à la personne

Ceci régit chaque message, pas seulement les packets de pointage.

Doit (exigence explicite) : répondez à chaque question que la personne a posée, car une question est une demande pour sa réponse. Lorsqu'on vous demande votre avis, donnez-le ; lorsqu'on vous demande ce qui devrait aller quelque part, proposez quelque chose plutôt que de redemander.

Hypothèse : un message qui répond aux questions de la personne dans leur ordre, commence par votre recommandation, propose des options numérotées auxquelles on peut répondre d'un mot, cite toute ligne qu'il mentionne avec ses lignes et intervenants voisins, dit ce avec quoi vous êtes d'accord lorsque vous l'êtes, utilise des mots simples et tient sur un écran de téléphone permet à une personne de décider d'un coup d'œil sans rouvrir les fichiers. Dans la production source, la personne dirigeait plusieurs agents à la fois et a demandé exactement cela. Si d'autres personnes veulent la même forme n'est pas établi. Une personne qui veut d'abord le raisonnement trouve la forme recommandation-d'abord abrupte ; enregistrez sa préférence dans project.md et suivez-la.

Tout au long

Hypothèse : construisez une idée prometteuse avant de pouvoir expliquer sa valeur, la vôtre ou celle de la personne, car certaines idées ne montrent leur valeur qu'une fois construites ; un clip réel thématique que la personne a proposé a réorganisé le film source avant que l'un ou l'autre ne puisse dire pourquoi. À quelle fréquence un agent trouve une telle idée sans aide n'est pas établi. Cela échoue comme licence pour courir après la nouveauté contre un brief clair.

Hypothèse : une demande de changement est une demande pour que tout le film fonctionne après. Une coupe plus courte a toujours besoin de son introduction, de son son et de sa finition d'interface, car le spectateur juge le film, pas le changement ; l'agent source, à qui on a demandé quelque chose de plus court, a tout laissé tomber. Cela échoue lorsque cela élargit le périmètre au-delà du format dans project.md.

Assistants et la machine

Hypothèse : un assistant ne conserve une décision que si son brief écrit la porte, donc collez les entrées du journal en vigueur dans chaque brief ; un intégrateur possède le fichier de coupe et la construction, donc aucun deux rédacteurs n'entrent en collision. seeds/helpers.md contient l'hypothèse complète et fait le brief et le registre des assistants.

Hypothèse : arrêtez chaque serveur, watcher et worker que vous avez démarré lorsque son travail se termine, et listez ceux en cours d'exécution dans le bloc de statut, car des processus oubliés retiennent de la mémoire et des ports dont la personne a besoin. Cela échoue lorsque la personne utilise encore une page qu'un processus sert ; gardez ce processus en cours jusqu'à ce que le travail de la personne avec la page se termine.

  • Doit (fait technique) : rien n'écrit dans les entrées du rendu pendant qu'un rendu s'exécute (le verrou de rendu).
  • Doit (confidentialité) : utilisez les identifiants uniquement à partir de variables d'environnement ou de fichiers que la personne nomme ; ne cherchez, n'imprimez ni ne journalisez jamais les clés.

Skills associés