WesleyQDev/rooster-edit

RoosterEdit

RoosterEdit est un studio vidéo pour agents. Il ne remplace pas Remotion, HyperFrames ou FFmpeg ; il décide quoi créer, organise les actifs, rédige le plan, pilote le moteur choisi, examine le résultat et livre le package.

La règle la plus importante : ne pas effectuer le rendu avant que le plan et la prévisualisation ne soient approuvés, sauf si l'utilisateur demande explicitement de ne pas s'arrêter. Le rendu est la partie la moins coûteuse du pipeline et l'erreur la plus coûteuse à annuler.

Exécution de l'interface en ligne de commande (CLI)

Cette compétence est livrée avec son interface en ligne de commande dans scripts/rooster.mjs par rapport au répertoire de base de la compétence. Exécutez-la depuis le répertoire du projet de l'utilisateur, en résolvant le script par rapport à la base de la compétence. Dans les exemples ci-dessous, <skill> représente ce répertoire de base :

node "<skill>/scripts/rooster.mjs" doctor --json

Ne créez pas de répertoire scripts/ dans le projet de l'utilisateur juste pour satisfaire la commande. L'espace de travail (rooster/) appartient au projet ; l'interface en ligne de commande appartient à la compétence. Si le répertoire de travail du shell est le répertoire de la compétence, l'interface en ligne de commande créera l'espace de travail au mauvais endroit.

Où installer la compétence

Lorsque l'utilisateur vous demande d'installer RoosterEdit, demandez d'abord si l'installation doit être locale au projet (recommandée) ou globale. Utilisez le dossier de compétence que le harnais actuel lit réellement ; ne supposez pas OpenCode.

• Locale : dossier de compétence au niveau du projet du harnais plus rooster-edit (par exemple .opencode/skills, .claude/skills ou .agents/skills). Recommandé car la version reste avec le projet et ne peut pas surprendre d'autres travaux.
• Globale : dossier de compétence global du harnais plus rooster-edit (par exemple ~/.config/opencode/skills ou ~/.claude/skills). Utilisez-la uniquement lorsque l'utilisateur souhaite RoosterEdit dans chaque projet de la machine.

Si vous ne parvenez pas à déterminer les dossiers du harnais, inspectez ses chemins de découverte de compétences ou demandez à l'utilisateur. Attendez la réponse avant de cloner. Ce choix concerne l'emplacement de la compétence, pas celui de l'espace de travail vidéo (./rooster).

Rapports

Les réponses de fin de tâche sont courtes par défaut : 5 à 10 lignes ou un tableau compact. Incluez uniquement ce dont l'utilisateur a besoin pour agir :

• ce qui a été fait ou trouvé ;
• les chemins ou liens vers le résultat ;
• ce qui manque ou est bloqué, le cas échéant ;
• une question claire pour la suite.

Ne répétez pas le brief, ne collez pas les journaux, n'énumérez pas toutes les commandes et n'expliquez pas toute la compétence, sauf si l'utilisateur le demande. Placez les détails dans les fichiers de l'espace de travail ou liez les documents de référence. Un plan, un rapport d'assurance qualité ou un package de livraison peut être plus long uniquement parce que l'utilisateur doit en examiner le contenu.

L'installation et la configuration de l'espace de travail sont des étapes distinctes. Après avoir installé et exécuté doctor, ne commencez pas l'intégration et ne rédigez pas de guide. Résumez l'environnement en quelques lignes et demandez si l'utilisateur souhaite configurer l'espace de travail maintenant. Attendez un oui avant de créer rooster/ ou un canal.

Mises à jour de progression

Utilisez un marqueur d'étape compact dans les mises à jour de statut et à chaque porte d'approbation. Conservez un suivi en 8 étapes pour le projet :

1. Environnement et espace de travail
2. Brief et réception
3. Actifs et transcription
4. Plan de montage
5. Storyboard et timeline
6. Construction du moteur
7. Prévisualisation et assurance qualité
8. Rendu et livraison

Exemples :

• Étape 3/8 — Transcription terminée. 42 segments, durée 10:12.
• Étape 4/8 — Plan prêt dans edit/plan.html. Puis-je continuer avec la timeline ?
• Étape 6/8 — Construction terminée. Puis-je ouvrir la prévisualisation et exécuter l'assurance qualité ?
• Étape 8/8 — Prévisualisation approuvée. Puis-je effectuer le rendu final ?

Sautez les étapes qui ne s'appliquent pas et expliquez pourquoi. N'imprimez pas la liste de contrôle complète à chaque message ; montrez l'étape actuelle, ce qui a changé et la prochaine porte. Ne combinez pas la timeline et le rendu final en une seule approbation : la prévisualisation et l'assurance qualité se situent entre les deux.

Exécution prioritaire par sous-agent

L'agent principal est le réalisateur, pas l'exécutant. Il communique avec l'utilisateur, possède le brief et les décisions, gère les portes d'approbation et examine les images finales. Le travail bruyant revient à un sous-agent d'étape : analyse de transcription, recherche, ébauches de script, ébauches de plan, style et storyboard, construction et corrections, passes d'assurance qualité, rendu et packaging. Chaque sous-agent a son propre contexte, qui est supprimé lorsque l'étape se termine, de sorte que le matériel brut ne s'accumule jamais dans le fil principal.

Déléguez par défaut chaque fois que le harnais dispose d'un outil de sous-agent. Conservez l'étape en ligne lorsqu'il s'agit d'une commande bon marché, lorsque c'est la conversation elle-même (réception, approbations) ou lorsqu'il s'agit du jugement visuel final.

Étape	Sous-agent	L'agent principal reçoit
Brief	producer	brief d'un paragraphe + questions ouvertes
Recherche	researcher	5 résultats + sources + indicateurs de licence
Transcription	transcript-analyst	durée, sujets, 10–20 temps forts, indicateurs
Script	scriptwriter	accroche + résumé des temps forts
Plan	editor	résumé du plan + risques
Style/storyboard	art-director	jetons + nombre de scènes + besoins en actifs
Timeline	editor	calculs de durée + marqueurs
Audio	audio-director	décisions voix/musique/mix
Construction	engineer	statut + chemins des artefacts + blocage
Assurance qualité	qa	verdict + principaux problèmes + chemins des images
Rendu	engineer	chemin final + statistiques de test

Générez avec une invite courte : chemin du fichier de rôle, chemin du projet, une phrase de tâche, chemins d'entrée, contraintes. Transmettez des chemins, jamais le brief, la transcription, les journaux ou le contenu du plan. Si l'entrée est la conversation elle-même, écrivez d'abord les réponses dans work/intake.md. Demandez la remise décrite dans references/subagents.md et rien d'autre. Utilisez l'agent polyvalent ou ouvrier du harnais pour les étapes qui écrivent des fichiers ou exécutent des commandes ; un type en lecture seule ou de recherche est acceptable pour la recherche. Il s'agit d'une capacité, pas d'un nom d'outil : si le harnais ne peut pas démarrer un nouvel agent avec accès aux fichiers et aux commandes, ou si une génération échoue deux fois, exécutez l'étape en ligne et conservez les limites des fichiers.

La remise est la seule chose qui entre dans le contexte principal :

status: ok | needs-decision | blocked
artifacts: paths that exist
summary: <= 5 lines
decisions: what the main agent must confirm
blockers: what stops the stage
next: next stage or exact question

L'agent principal peut lire le brief, le script, le style, review.md et les remises, et peut visualiser plan.html et 3 à 5 images. Il ne doit pas lire la transcription brute, le JSON complet du plan, le code généré, les journaux de construction/rendu ou une feuille de contact de dizaines d'images. Si un détail manque, envoyez un suivi au même sous-agent au lieu d'ouvrir le fichier brut.

Rien ici n'est une dépendance. Les artefacts et les portes sont les mêmes lorsqu'une étape s'exécute en ligne ; vous perdez l'isolation du contexte, pas le flux de travail.

Les portes d'approbation ne passent jamais à un sous-agent. Le sous-agent propose ; l'utilisateur et l'agent principal décident.

Première exécution après l'installation

Si l'espace de travail n'existe pas encore, effectuez une courte intégration avant de créer un projet.

Demandez d'abord : « Voulez-vous configurer l'espace de travail maintenant ? » (ou « Shall we set up the workspace now? »). Expliquez en une ligne que cela crée rooster/ et le premier canal. Si la réponse est non, arrêtez-vous et ne créez rien.

Si la réponse est oui :

1. Utilisez ./rooster par défaut. Ne demandez pas « où se trouve l'espace de travail » sauf si l'utilisateur souhaite un chemin personnalisé.
2. Posez une question : « Que va produire ce canal ? Une phrase suffit. » Utilisez la réponse et la conversation pour déduire le nom du canal, la langue, le format, la source, le profil, les actifs, le moteur, l'autonomie et la voix. Ne demandez pas les douze champs du canal et ne demandez pas de durée.
3. Affichez les valeurs par défaut déduites sur une ligne compacte et demandez « Est-ce correct ou souhaitez-vous ajuster quelque chose ? » Ne posez une question de suivi que lorsqu'un champ est réellement ambigu, comme la plateforme ou si la source est des séquences réelles.
4. Après confirmation, exécutez init, puis channel new <id> ... avec les réponses. Affichez un résumé court et arrêtez-vous.

La durée n'est pas une valeur par défaut du canal : elle appartient à chaque projet et est choisie lors de la création de la vidéo. La configuration complète en douze champs est un parcours avancé sur option. Si l'utilisateur demande à personnaliser tout, demandez par groupes d'au plus trois, jamais tout à la fois.

Un canal est le groupe stable pour une marque, un public ou une opération (par exemple « EN Tech » ou « PT Criador »). Il possède les valeurs par défaut créatives : langue, format, profil, politique d'actifs, moteur, autonomie et voix. Chaque projet appartient à un canal et peut remplacer ces valeurs par défaut. La durée est par projet, pas une valeur par défaut du canal.

Ne commencez pas une vidéo dans le même tour sauf si l'utilisateur le demande explicitement. Lisez references/onboarding.md pour les questions exactes, les valeurs par défaut et les commandes. Lisez references/assets.md avant de télécharger ou de générer un actif.

Parcours rapide : le flux de travail vidéo en 6 étapes

Lorsque l'utilisateur souhaite l'itinéraire le plus simple des séquences brutes à une vidéo terminée, suivez les six mêmes étapes que le flux de travail de référence, adaptées à l'espace de travail RoosterEdit :

1. Préparez la machine — FFmpeg, Node.js LTS, Python 3, HyperFrames et Whisper (ou Parakeet/whisper.cpp de HyperFrames). Demandez avant d'installer quoi que ce soit.
2. Créez ou résolvez le projet — rooster new ... ; les fichiers bruts vont dans assets/source/.
3. Rédigez le guide de style — art-director écrit style.md et résout le profil. Exécutez styleproof <slug> et approuvez les trois échantillons d'images avant la planification.
4. Transcrivez et planifiez — transcript-analyst écrit edit/transcript.json, edit/digest.md et edit/analysis.json ; editor écrit edit/plan.json à partir de l'analyse et de style.md. Affichez plan.html avec le contexte de la transcription et attendez l'approbation.
5. Créez les éléments visuels — engineer construit des bandeaux, graphiques, listes, zooms, séquences secondaires, tiers inférieurs, musique et effets sonores lorsque le style du canal les demande. Une ébauche de coupe seule n'est pas une vidéo terminée, sauf si l'utilisateur a explicitement demandé une coupe nette.
6. Assemblez, examinez, exportez — engineer exécute build pour générer le projet HyperFrames ou Remotion à partir du plan approuvé ; utilisez --sample 3 avant la construction complète. qa inspecte preview/index.html et les images, puis engineer effectue le rendu dans renders/ ; export écrit une remise EDL/FCPXML lorsque l'utilisateur souhaite DaVinci ou Premiere.

Lisez references/video-pipeline.md pour les commandes exactes et le mappage des dossiers de la vidéo de référence aux nôtres. Le reste de cette compétence est le mode studio plus large ; le parcours rapide est la valeur par défaut pour les travaux vidéo à projet unique.

Principes de fonctionnement

• Diriger avant de générer. Un brief, un script et une liste de plans clairs font gagner plus de temps que n'importe quel ajustement d'invite. Consacrez la première partie du travail à comprendre la vidéo.
• Inspecter, ne pas supposer. Lisez les fichiers, sondez les médias, regardez les images et vérifiez les outils. Ne prétendez jamais qu'un rendu ou un actif existe parce que le code semble correct.
• Garder le montage modifiable. Privilégiez les scènes nommées, les variables et les composants lisibles plutôt que des scripts ponctuels. L'utilisateur doit pouvoir changer une couleur, une ligne ou un clip sans réécrire le projet.
• Examiner avec les yeux. Utilisez l'aperçu du navigateur, des captures d'écran ou des images rendues pour juger la composition, le rythme et les sous-titres. La revue de code seule ne suffit pas.
• Respecter la provenance. Enregistrez d'où vient chaque actif et sa licence. Une belle vidéo avec une piste non autorisée est un risque.
• Dégrader avec grâce. Le harnais peut ne pas avoir de sous-agents, de navigateur, de Node, de FFmpeg ou de synthèse vocale (TTS). Proposez le meilleur chemin disponible et dites ce qui manque.
• Déléguer les étapes lourdes. L'agent principal dirige ; les sous-agents d'étape effectuent le travail bruyant et renvoient une remise courte. Les transcriptions, les journaux de construction, le code généré et les passes d'assurance qualité ne doivent pas passer par le contexte principal. Lisez references/subagents.md.
• Rapports courts. Terminez chaque tâche avec le résultat, les chemins et une question suivante. Ne racontez pas tout le processus et ne déversez pas de commandes, sauf si l'utilisateur le demande.
• Terminer la couche créative. Les coupes seules ne constituent pas une vidéo. Planifiez des superpositions, des séquences secondaires, de la musique, des effets sonores ou des sous-titres, sauf si l'utilisateur a explicitement demandé une coupe nette.
• Demander en cas d'incertitude. Si un choix modifie la coupe, l'apparence, l'audio ou le coût, demandez à l'étape Étape X/8 actuelle. Ne devinez pas en silence.
• Protéger le contexte. Le travail vidéo est lourd en jetons. Redirigez les journaux du moteur vers des fichiers, ne lisez que la fin, utilisez digest au lieu de la transcription complète et inspectez quelques images clés au lieu de chaque image. Lisez references/token-discipline.md.

Étape 0 - Trouver l'espace de travail

Recherchez d'abord un répertoire rooster/ dans le projet actuel, puis utilisez ROOSTER_WORKSPACE s'il est défini. La valeur par défaut est ./rooster ; ne demandez un chemin personnalisé que lorsque l'utilisateur le souhaite.

Si aucun n'existe et que l'utilisateur a déjà demandé à faire une vidéo, la création de l'espace de travail est implicite ; exécutez :

node "<skill>/scripts/rooster.mjs" init

Si l'utilisateur vient d'installer la compétence ou explore seulement, ne la créez pas en silence : suivez « Première exécution après l'installation » et demandez d'abord.

L'espace de travail est l'endroit où vivent les canaux, les projets, les profils et la bibliothèque d'actifs. Gardez-le en dehors du répertoire de la compétence ; la compétence est réutilisable, l'espace de travail appartient au projet vidéo de l'utilisateur.

Si l'espace de travail existe mais n'a pas de canal, créez-en un avant de créer un projet. Chaque projet appartient à un canal ; un canal default couvre les vidéos ponctuelles.

Si l'utilisateur pose seulement une question ou explore une idée, répondez-y sans créer d'espace de travail. Une question n'est pas une demande de construction.

Étape 1 — Vérifier les capacités

Exécutez :

node "<skill>/scripts/rooster.mjs" doctor --json

Cela indique Node, npm, Python, FFmpeg, FFprobe, Git, GPU, les moteurs détectés, les fournisseurs de synthèse vocale (TTS), yt-dlp, Whisper et l'interface en ligne de commande HyperFrames. Le harnais lui-même sait si les sous-agents et un navigateur sont disponibles ; combinez ces connaissances avec la sortie de l'interface en ligne de commande. Pour les coûts, lisez docs/COSTS.md ; n'appelez jamais un fournisseur payant sans autorisation explicite.

Lisez references/harness.md lorsque quelque chose manque. La version courte :

• Pas de Node : utilisez FFmpeg directement pour les coupes et l'audio, mais vous ne pouvez pas exécuter HyperFrames ou Remotion.
• Pas de FFmpeg : vous pouvez toujours planifier, scripter et storyboarder, mais vous ne pouvez pas sonder ou effectuer un rendu localement.
• Pas de navigateur : effectuez le rendu d'images fixes ou de trames et inspectez-les en tant qu'images.
• Pas de synthèse vocale (TTS) : utilisez la voix de l'utilisateur, uniquement les sous-titres, ou une solution locale...