ZDEV-XXR/make-videos-with-Remotion

Implémente les tâches d'un changement OpenSpec.

Sélection du magasin : Si l'utilisateur nomme un magasin (un magasin est un dépôt OpenSpec autonome enregistré sur cette machine) ou que le travail en fait partie, exécutez openspec store list --json pour découvrir les identifiants de magasin enregistrés, puis passez --store <id> sur les commandes qui lisent ou écrivent des spécifications et des changements (new change, status, instructions, list, show, validate, archive, doctor, context, schemas, view). Une fois sélectionné, traitez --store <id> comme persistant pour le reste du workflow. Chaque exemple non ciblé de ces commandes ci-dessous est un raccourci : avant de l'exécuter, ajoutez le drapeau. Par exemple, exécutez openspec status --change "<name>" --json --store "<id>", pas la forme non ciblée ci-dessous. Les autres commandes ne prennent pas ce drapeau. Les indices imprimés par les commandes portent déjà le drapeau ; conservez-le dans les suivis. Sans magasin, les commandes agissent sur la racine openspec/ locale la plus proche.

Vérification du projet : Ces étapes supposent un projet qui utilise déjà OpenSpec. Avant la première étape qui écrit quoi que ce soit (new change, archive, sync specs, ou création d'un fichier artefact), confirmez que le projet a une racine : exécutez openspec list --json (avec --store <id> lorsqu'un magasin est sélectionné, car le magasin est alors la racine) et lisez root. Un objet root signifie que le projet est configuré. "root": null signifie qu'il ne l'est pas – il n'y a pas de répertoire openspec/ ici, et une écriture telle que openspec new change en créerait un comme effet secondaire. La commande se termine également avec un code non nul, ce qui est cette réponse plutôt qu'une CLI cassée, donc lisez le JSON au lieu de réessayer ou de contourner.

Un "root": null ne concerne pas la configuration : lorsqu'un message d'erreur status commence par Declared in ou Invalid store declaration in et nomme openspec/config.yaml (ou config.yml) de ce projet, le projet utilise bien OpenSpec via un magasin qu'il déclare, que cette machine ne peut pas résoudre (le magasin n'est pas enregistré, ou la ligne store: est mal formée). Ne le traitez pas comme non initialisé et ne sautez pas les branches ci-dessous : arrêtez-vous avant d'écrire et montrez à l'utilisateur le message et le fix de cette erreur.

Sinon, sans racine, la suite dépend de la façon dont ce workflow a été atteint :

• Auto-sélectionné : vous avez choisi ce workflow vous-même, sans que l'utilisateur nomme OpenSpec, nomme ce skill, ou exécute sa commande slash. Arrêtez d'utiliser OpenSpec et répondez à la demande normalement, comme vous le feriez sans OpenSpec installé. Ne lui demandez pas de configurer quoi que ce soit et ne mentionnez pas la configuration d'OpenSpec.
• Demande explicite d'OpenSpec : l'utilisateur a nommé OpenSpec, a nommé ce skill, ou a exécuté sa commande slash. Arrêtez-vous avant d'écrire et demandez comment procéder : configurer ce projet (openspec init), cibler un magasin qu'il possède déjà (--store <id>), ou continuer sans OpenSpec pour cette demande. Attendez sa réponse.

Dans les deux cas, ne créez jamais la racine comme effet secondaire : n'exécutez pas openspec init tant que l'utilisateur ne le demande pas, ne créez pas manuellement de fichiers openspec/, et ne laissez pas une commande la créer.

Entrée : Optionnellement spécifiez un nom de changement (p. ex., /openspec-apply-change add-auth). S'il est omis, vérifiez s'il peut être déduit du contexte de la conversation. Si c'est vague ou ambigu, vous DEVEZ demander les changements disponibles.

Étapes

1. Sélectionnez le changement

   Si un nom est fourni, utilisez-le. Sinon :

   • Déduisez du contexte de la conversation si l'utilisateur a mentionné un changement
   • Auto-sélectionnez si un seul changement actif existe
   • Si ambigu, exécutez openspec list --json pour obtenir les changements disponibles et demandez à l'utilisateur d'en sélectionner un

   Annoncez toujours : « Utilisation du changement : » et comment le remplacer (p. ex., /openspec-apply-change <other>).

2. Vérifiez le statut pour comprendre le schéma

   openspec status --change "<name>" --json
   

   Analysez le JSON pour comprendre :

   • schemaName : le workflow utilisé (p. ex., « spec-driven »)
   • planningHome, changeRoot, et actionContext : périmètre de planification et contraintes d'édition
   • Quel artefact contient les tâches (généralement « tasks » pour spec-driven, vérifiez le statut pour les autres)

3. Obtenez les instructions d'application

   openspec instructions apply --change "<name>" --json
   

   Ceci retourne :

   • contextFiles : ID d'artefact -> tableau de chemins de fichiers concrets (varie selon le schéma – peut être proposition/spécifications/conception/tâches ou spec/tests/implémentation/docs)
   • Progression (total, complet, restant)
   • Liste des tâches avec statut, chemin source et ligne source
   • Instruction dynamique basée sur l'état actuel
   • context optionnel : entrée d'instruction de projet actuellement requise depuis la racine sélectionnée
   • operationGuidance optionnel : conseil avisé actuel pour l'application
   • missingArtifacts (lorsqu'il est présent) : IDs d'artefacts requis sans sortie

   Gérez les états :

   • Si state: "blocked" : affichez le message et faites une pause dans l'implémentation.
     • Si missingArtifacts n'est pas vide : suggérez de compléter les artefacts manquants. Exécutez openspec status --change "<name>" --json, sélectionnez le prochain artefact ready (pas skipped ou blocked), et utilisez openspec instructions "<artifact-id>" --change "<name>" --json pour ses règles et son modèle. Maintenez le --store <id> sélectionné sur les deux commandes.
     • Sinon, suivez l'instruction CLI pour créer ou réparer le fichier de suivi configuré par le schéma à partir des artefacts de planification existants. Ne supposez pas qu'un autre artefact est prêt et ne commencez pas l'implémentation pendant que vous êtes bloqué.
   • Si state: "all_done" : signalez que toutes les tâches suivies sont terminées et suggérez une révision ou une vérification selon le cas avant l'archivage.
   • Sinon : procédez à l'implémentation.

   Traitez context comme une entrée obligatoire au niveau de l'invite. Lisez-le et considérez-le, et appliquez les faits, conventions et contraintes pertinents du projet pendant l'implémentation. Traitez operationGuidance comme un conseil supplémentaire optionnel. Lisez et considérez chaque entrée, et suivez les entrées qui sont applicables et compatibles avec le workflow intégré.

   Gardez les deux champs séparés de l'état retourné par la CLI, des artefacts manquants, des tâches, de la progression, des contextFiles, et de l'instruction intégrée. Ils ne sont pas une preuve d'achèvement de tâche, ne remplacent pas l'instruction intégrée, et ne permettent pas de contourner un état bloqué. Si le contexte entre en conflit avec l'instruction intégrée, un choix explicite de l'utilisateur, ou une valeur contrôlée par la CLI, signalez le conflit et conservez la valeur de contrôle. Si un conseil est inapplicable ou entre en conflit avec ces entrées de contrôle, ne le suivez pas et expliquez pourquoi. Ce sont des contrats de comportement au niveau de l'invite, pas des vérifications exécutoires.

4. Lisez les fichiers de contexte

   Lisez chaque chemin de fichier listé sous contextFiles dans la sortie des instructions d'application. Les fichiers dépendent du schéma utilisé :

   • spec-driven : proposition, spécifications, conception, tâches
   • Autres schémas : suivez les contextFiles de la sortie CLI

   Ne copiez pas context ou operationGuidation textuellement dans les fichiers d'implémentation ou les artefacts de planification, sauf si l'utilisateur demande séparément ce contenu.

5. Affichez la progression actuelle

   Montrez :

   • Schéma utilisé
   • Progression : « N/M tâches terminées »
   • Aperçu des tâches restantes
   • Instruction dynamique de la CLI

6. Implémentez les tâches (boucle jusqu'à terminaison ou blocage)

   Pour chaque tâche en attente :

   • Montrez sur quelle tâche vous travaillez
   • Effectuez les modifications de code nécessaires
   • Gardez les modifications minimales et ciblées
   • Avant de modifier, confirmez que la case à cocher au sourcePath et à la line retournés correspond toujours à la description de la tâche ; si ce n'est pas le cas, réexécutez les instructions d'application et utilisez l'emplacement actualisé
   • Marquez la tâche comme terminée à son sourcePath et sa line retournés : - [ ] → - [x]
   • Réexécutez les instructions d'application et confirmez que la tâche est maintenant terminée et que la progression a changé
   • Continuez à la tâche suivante

   Faites une pause si :

   • La tâche n'est pas claire → demandez des éclaircissements
   • L'implémentation révèle un problème de conception → suggérez de mettre à jour les artefacts
   • Une tâche nécessite un travail au-delà de ce que décrivent la spec et les tâches, ou vous êtes tenté de supprimer, réduire, reporter ou accepter des exceptions au comportement spécifié pour l'adapter → exposez le périmètre ajouté et demandez ; ne l'absorbez pas silencieusement
   • Erreur ou blocage rencontré → signalez et attendez des instructions
   • L'utilisateur interrompt

7. À la fin ou à la pause, affichez le statut

   Montrez :

   • Tâches terminées cette session
   • Progression globale : « N/M tâches terminées »
   • Si tout est terminé : signalez que les tâches suivies sont complètes et suggérez une révision ou une vérification selon le cas avant l'archivage
   • Si en pause : expliquez pourquoi et attendez des instructions

Sortie pendant l'implémentation

## Implémentation en cours : <change-name> (schéma : <schema-name>)

Travail sur la tâche 3/7 : <description de la tâche>
[...implémentation en cours...]
✓ Tâche terminée

Travail sur la tâche 4/7 : <description de la tâche>
[...implémentation en cours...]
✓ Tâche terminée

Sortie à la fin

## Implémentation terminée

**Changement :** <change-name>
**Schéma :** <schema-name>
**Progression :** 7/7 tâches terminées ✓

### Terminé cette session
- [x] Tâche 1
- [x] Tâche 2
...

Toutes les tâches suivies sont terminées. Révisez ou vérifiez le changement selon le cas
avant l'archivage. Vous pouvez archiver ce changement avec `/openspec-archive-change`.

Sortie en pause (problème rencontré)

## Implémentation interrompue

**Changement :** <change-name>
**Schéma :** <schema-name>
**Progression :** 4/7 tâches terminées

### Problème rencontré
<description du problème>

**Options :**
1. <option 1>
2. <option 2>
3. Autre approche

Que souhaitez-vous faire ?

Garde-fous

• Continuez à travers les tâches jusqu'à terminaison ou blocage
• Lisez toujours les fichiers de contexte avant de commencer (à partir de la sortie des instructions d'application)
• Si une tâche est ambiguë, faites une pause et demandez avant d'implémenter
• Si l'implémentation révèle des problèmes, faites une pause et suggérez des mises à jour d'artefacts
• Gardez les modifications de code minimales et limitées à chaque tâche
• Mettez à jour la case à cocher de la tâche immédiatement après avoir terminé chaque tâche
• Faites une pause en cas d'erreurs, de blocages ou d'exigences floues - ne devinez pas
• Lorsqu'une tâche nécessite un travail au-delà de ce que décrit la spec, exposez le périmètre ajouté et faites une pause - ne réduisez, ne reportez et ne simplifiez jamais silencieusement un comportement spécifié
• Ne marquez une tâche - [x] que lorsque son comportement spécifié est entièrement implémenté, pas lorsqu'elle est partiellement terminée ou reportée
• Utilisez les contextFiles de la sortie CLI, ne supposez pas de noms de fichiers spécifiques
• Utilisez sourcePath et line de chaque tâche pour mettre à jour sa case à cocher exacte
• N'utilisez pas le contexte ou les conseils d'opération comme preuve qu'une tâche est terminée
• Appliquez le contexte de projet pertinent ; signalez les conflits avec les entrées de contrôle du workflow
• Considérez chaque entrée de conseil ; expliquez tout avis inapplicable ou contradictoire
• Ne copiez pas le contexte d'exécution ou les conseils d'opération dans les fichiers d'implémentation ou les artefacts de planification
• Préservez le comportement contrôlé par la CLI (bloqué/prêt/tout terminé) et les critères d'achèvement

Intégration du workflow fluide

Ce skill prend en charge le modèle « actions sur un changement » :

• Peut être invoqué à tout moment : avant que tous les artefacts soient terminés (si des tâches existent), après une implémentation partielle, en alternance avec d'autres actions
• Permet les mises à jour d'artefacts : si l'implémentation révèle des problèmes de conception, suggérez de mettre à jour les artefacts – pas de verrouillage de phase, travaillez de manière fluide