ZDEV-XXR/make-videos-with-Remotion

Implementiere Aufgaben aus einer OpenSpec-Änderung.

Store-Auswahl: Wenn der Benutzer einen Store nennt (ein Store ist ein eigenständiges OpenSpec-Repo, das auf diesem Rechner registriert ist) oder die Arbeit in einem solchen liegt, führe openspec store list --json aus, um registrierte Store-IDs zu ermitteln, und übergib dann --store <id> bei den Befehlen, die Spezifikationen und Änderungen lesen oder schreiben (new change, status, instructions, list, show, validate, archive, doctor, context, schemas, view). Behandle --store <id> nach der Auswahl für den restlichen Workflow als persistent. Jedes unten stehende, nicht näher bezeichnete Beispiel dieser Befehle ist eine Kurzform: vor der Ausführung muss das Flag angehängt werden. Führe z.B. openspec status --change "<name>" --json --store "<id>" aus, nicht die unten gezeigte Kurzform. Andere Befehle akzeptieren das Flag nicht. Von Befehlen ausgegebene Hinweise enthalten das Flag bereits; behalte es bei Folgeschritten bei. Ohne einen Store agieren die Befehle im nächstgelegenen lokalen openspec/-Stammverzeichnis.

Projektprüfung: Diese Schritte setzen ein Projekt voraus, das bereits OpenSpec verwendet. Bevor der erste Schritt etwas schreibt (new change, archive, sync specs oder das Erstellen einer Artefakt-Datei), bestätige, dass das Projekt ein Stammverzeichnis hat: führe openspec list --json aus (mit --store <id>, wenn ein Store ausgewählt wurde, da der Store dann das Stammverzeichnis ist) und lies root aus. Ein root-Objekt bedeutet, dass das Projekt eingerichtet ist. "root": null bedeutet, dass es nicht eingerichtet ist – es gibt kein openspec/-Verzeichnis, und ein Schreibbefehl wie openspec new change würde eines als Nebeneffekt erstellen. Der Befehl beendet sich auch mit einem Fehlercode ungleich Null, was die Antwort ist und kein defektes CLI darstellt; lese daher das JSON aus, anstatt es erneut zu versuchen oder einen Workaround zu suchen.

Ein "root": null bezieht sich nicht auf die Einrichtung: Wenn eine status-Fehlermeldung mit Declared in oder Invalid store declaration in beginnt und die openspec/config.yaml (oder config.yml) dieses Projekts nennt, dann verwendet das Projekt OpenSpec über einen Store, den es deklariert, der aber von diesem Rechner nicht aufgelöst werden kann (der Store ist nicht registriert oder die store:-Zeile ist fehlerhaft). Behandle dies nicht als nicht initialisiert und überspringe die unten stehenden Verzweigungen: halte vor dem Schreiben an und zeige dem Benutzer die message und den fix dieses Fehlers an.

Andernfalls, wenn kein Stammverzeichnis vorhanden ist, hängt das weitere Vorgehen davon ab, wie dieser Workflow erreicht wurde:

• Automatisch ausgewählt: Du hast diesen Workflow selbst ausgewählt, ohne dass der Benutzer OpenSpec, diesen Skill oder dessen Slash-Befehl genannt hat. Stoppe die Verwendung von OpenSpec und beantworte die Anfrage normal, als ob OpenSpec nicht installiert wäre. Bitte den Benutzer nicht, etwas einzurichten, und erwähne keine OpenSpec-Einrichtung.
• Explizite OpenSpec-Anfrage: Der Benutzer hat OpenSpec, diesen Skill oder dessen Slash-Befehl genannt. Halte vor dem Schreiben an und frage, wie fortgefahren werden soll: Dieses Projekt einrichten (openspec init), einen bereits vorhandenen Store anvisieren (--store <id>) oder für diese Anfrage ohne OpenSpec fortfahren. Warte auf die Antwort.

Erstelle in beiden Fällen niemals das Stammverzeichnis als Nebeneffekt: führe openspec init erst aus, wenn der Benutzer darum bittet, erstelle keine openspec/-Dateien von Hand und lasse keinen Befehl sie erstellen.

Eingabe: Optional kann ein Änderungsname angegeben werden (z.B. /openspec-apply-change add-auth. Falls nicht angegeben, prüfe, ob er aus dem Gesprächskontext abgeleitet werden kann. Bei vagen oder mehrdeutigen Angaben MUSST du nach den verfügbaren Änderungen fragen.

Schritte

1. Änderung auswählen

   Wenn ein Name angegeben ist, verwende ihn. Andernfalls:

   • Leite ihn aus dem Gesprächskontext ab, wenn der Benutzer eine Änderung erwähnt hat.
   • Wähle automatisch aus, wenn nur eine aktive Änderung existiert.
   • Bei Mehrdeutigkeit führe openspec list --json aus, um verfügbare Änderungen zu erhalten, und bitte den Benutzer, eine auszuwählen.

   Gib immer bekannt: „Verwende Änderung: “ und wie überschrieben werden kann (z.B. /openspec-apply-change <andere>).

2. Status prüfen, um das Schema zu verstehen

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

   Analysiere das JSON, um Folgendes zu verstehen:

   • schemaName: Der verwendete Workflow (z.B. "spec-driven")
   • planningHome, changeRoot und actionContext: Planungsumfang und Bearbeitungseinschränkungen
   • Welches Artefakt die Aufgaben enthält (typischerweise "tasks" bei spec-driven, bei anderen Schemas siehe status)

3. Anweisungen zum Anwenden (apply) holen

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

   Dies gibt zurück:

   • contextFiles: Artefakt-ID -> Array von konkreten Dateipfaden (variiert je nach Schema – kann Vorschlag/Spezifikationen/Design/Aufgaben oder Spezifikation/Tests/Implementierung/Dokumentation sein)
   • Fortschritt (gesamt, vollständig, verbleibend)
   • Aufgabenliste mit Status, Quellpfad und Quellzeile
   • Dynamische Anweisung basierend auf dem aktuellen Zustand
   • Optional context: aktuelle erforderliche Projekteingabe aus dem ausgewählten Stammverzeichnis
   • Optional operationGuidance: aktuelle beratende Anleitung für die Anwendung
   • missingArtifacts (falls vorhanden): erforderliche Artefakt-IDs ohne Ausgabe

   Zustände behandeln:

   • Wenn state: "blocked": Zeige die Nachricht an und pausiere die Implementierung.
     • Wenn missingArtifacts nicht leer ist: Schlage vor, die fehlenden Artefakte zu vervollständigen. Führe openspec status --change "<name>" --json aus, wähle das nächste ready-Artefakt (nicht skipped oder blocked) aus und verwende openspec instructions "<artifact-id>" --change "<name>" --json für dessen Regeln und Vorlage. Behalte das ausgewählte --store <id> bei beiden Befehlen bei.
     • Andernfalls folge der CLI-Anweisung, um die schema-konfigurierte Tracking-Datei aus vorhandenen Planungsartefakten zu erstellen oder zu reparieren. Nimm nicht an, dass ein anderes Artefakt bereit ist, und starte keine Implementierung, während blockiert ist.
   • Wenn state: "all_done": Melde, dass alle verfolgten Aufgaben abgeschlossen sind, und schlage eine Überprüfung oder Verifizierung vor, bevor archiviert wird.
   • Andernfalls fahre mit der Implementierung fort.

   Behandle context als erforderliche Eingabe auf Prompt-Ebene. Lies und berücksichtige ihn und wende relevante Projektfakten, Konventionen und Einschränkungen während der Implementierung an. Behandle operationGuidance als optionale ergänzende Anleitung. Lies und berücksichtige jeden Eintrag und befolge Einträge, die anwendbar und mit dem integrierten Workflow kompatibel sind.

   Halte beide Felder getrennt vom CLI-zurückgegebenen Zustand, fehlenden Artefakten, Aufgaben, Fortschritt, contextFiles und der integrierten instruction. Sie sind kein Nachweis für die Aufgabenerledigung, ersetzen nicht die integrierte Anweisung und erlauben nicht, einen blockierten Zustand zu umgehen. Wenn context mit der integrierten Anweisung, einer expliziten Benutzerentscheidung oder einem CLI-gesteuerten Wert in Konflikt steht, melde den Konflikt und behalte den steuernden Wert bei. Wenn die Anleitung nicht anwendbar ist oder mit diesen steuernden Eingaben in Konflikt steht, befolge sie nicht und erkläre warum. Dies sind Verhaltensverträge auf Prompt-Ebene, keine durchsetzbaren Prüfungen.

4. Kontextdateien lesen

   Lese jede Datei, die unter contextFiles in der Ausgabe der Anwendungsanweisungen aufgeführt ist. Die Dateien hängen vom verwendeten Schema ab:

   • spec-driven: Vorschlag, Spezifikationen, Design, Aufgaben
   • Andere Schemas: Folge den contextFiles aus der CLI-Ausgabe

   Kopiere context oder operationGuidance nicht wörtlich in Implementierungsdateien oder Planungsartefakte, es sei denn, der Benutzer fragt separat nach diesem Inhalt.

5. Aktuellen Fortschritt anzeigen

   Zeige an:

   • Verwendetes Schema
   • Fortschritt: „N/M Aufgaben erledigt“
   • Übersicht der verbleibenden Aufgaben
   • Dynamische Anweisung von der CLI

6. Aufgaben implementieren (Schleife bis erledigt oder blockiert)

   Für jede anstehende Aufgabe:

   • Zeige, an welcher Aufgabe gearbeitet wird
   • Nimm die erforderlichen Codeänderungen vor
   • Halte Änderungen minimal und fokussiert
   • Bestätige vor dem Bearbeiten, dass das Kontrollkästchen am zurückgegebenen sourcePath und line noch mit der Aufgabenbeschreibung übereinstimmt; falls nicht, führe die Anwendungsanweisungen erneut aus und verwende die aktualisierte Position
   • Markiere die Aufgabe an ihrem zurückgegebenen sourcePath und line als erledigt: - [ ] → - [x]
   • Führe die Anwendungsanweisungen erneut aus und bestätige, dass die Aufgabe jetzt erledigt ist und sich der Fortschritt geändert hat
   • Fahre mit der nächsten Aufgabe fort

   Pausiere, wenn:

   • Aufgabe unklar ist → um Klärung bitten
   • Implementierung ein Designproblem offenbart → vorschlagen, Artefakte zu aktualisieren
   • Eine Aufgabe Arbeit erfordert, die über das hinausgeht, was Spezifikation und Aufgaben beschreiben, oder du versucht bist, spezifiziertes Verhalten stillschweigend fallen zu lassen, einzuschränken, zu verschieben oder Ausnahmen zu akzeptieren, um es anzupassen → den zusätzlichen Umfang offenlegen und nachfragen; nicht stillschweigend übernehmen.
   • Fehler oder Blockade auftritt → melden und auf Anweisungen warten
   • Benutzer unterbricht

7. Bei Abschluss oder Pause Status anzeigen

   Zeige an:

   • In dieser Sitzung erledigte Aufgaben
   • Gesamtfortschritt: „N/M Aufgaben erledigt“
   • Wenn alles erledigt ist: Melde, dass alle verfolgten Aufgaben abgeschlossen sind, und schlage eine Überprüfung oder Verifizierung vor, bevor archiviert wird.
   • Wenn pausiert: Erkläre warum und warte auf Anweisungen

Ausgabe während der Implementierung

## Implementierung: <äname> (Schema: <schema-name>)

Arbeite an Aufgabe 3/7: <Aufgabenbeschreibung>
[...Implementierung läuft...]
✓ Aufgabe erledigt

Arbeite an Aufgabe 4/7: <Aufgabenbeschreibung>
[...Implementierung läuft...]
✓ Aufgabe erledigt

Ausgabe bei Abschluss

## Implementierung abgeschlossen

**Änderung:** <änderungsname>
**Schema:** <schema-name>
**Fortschritt:** 7/7 Aufgaben erledigt ✓

### In dieser Sitzung erledigt
- [x] Aufgabe 1
- [x] Aufgabe 2
...

Alle verfolgten Aufgaben sind abgeschlossen. Überprüfe oder verifiziere die Änderung
vor der Archivierung. Du kannst diese Änderung mit `/openspec-archive-change` archivieren.

Ausgabe bei Pause (Problem aufgetreten)

## Implementierung pausiert

**Änderung:** <änderungsname>
**Schema:** <schema-name>
**Fortschritt:** 4/7 Aufgaben erledigt

### Aufgetretenes Problem
<Beschreibung des Problems>

**Optionen:**
1. <Option 1>
2. <Option 2>
3. Anderer Ansatz

Was möchtest du tun?

Leitplanken

• Arbeite Aufgaben durch, bis alles erledigt oder blockiert ist
• Lese immer zuerst die Kontextdateien (aus der Ausgabe der Anwendungsanweisungen)
• Wenn eine Aufgabe mehrdeutig ist, pausiere und frage vor der Implementierung
• Wenn die Implementierung Probleme offenbart, pausiere und schlage Artefakt-Updates vor
• Halte Codeänderungen minimal und auf jede Aufgabe beschränkt
• Aktualisiere das Aufgaben-Kontrollkästchen sofort nach Abschluss jeder Aufgabe
• Pausiere bei Fehlern, Blockaden oder unklaren Anforderungen – rate nicht
• Wenn eine Aufgabe Arbeit erfordert, die über das hinausgeht, was die Spezifikation beschreibt, lege den zusätzlichen Umfang offen und pausiere – verengstille, verschiebe oder vereinfache niemals spezifiziertes Verhalten
• Markiere eine Aufgabe nur dann mit - [x], wenn ihr spezifiziertes Verhalten vollständig implementiert ist, nicht wenn sie teilweise erledigt oder verschoben ist
• Verwende contextFiles aus der CLI-Ausgabe, nimm keine bestimmten Dateinamen an
• Verwende den sourcePath und die line jeder Aufgabe, um ihr genaues Kontrollkästchen zu aktualisieren
• Verwende Kontext oder Betriebsanleitung nicht als Nachweis, dass eine Aufgabe abgeschlossen ist
• Wende relevanten Projektkontext an; melde Konflikte mit steuernden Workflow-Eingaben
• Berücksichtige jeden Anleitungseintrag; erkläre nicht anwendbare oder widersprüchliche Ratschläge
• Kopiere Laufzeitkontext oder Betriebsanleitung nicht in Implementierungsdateien oder Planungsartefakte
• Bewahre das durch die CLI gesteuerte Verhalten bei Blockiert/Bereit/Alles-Erledigt und die Abschlusskriterien

Flüssige Workflow-Integration

Dieser Skill unterstützt das Modell „Aktionen an einer Änderung“:

• Kann jederzeit aufgerufen werden: Bevor alle Artefakte fertig sind (wenn Aufgaben existieren), nach teilweiser Implementierung, gemischt mit anderen Aktionen
• Erlaubt Artefakt-Updates: Wenn die Implementierung Designprobleme offenbart, schlage vor, Artefakte zu aktualisieren – nicht phasengebunden, arbeite fließend