AmanVarshney01/tcut

Aufgaben aus einem OpenSpec-Change implementieren.

Store-Auswahl: Wenn der Benutzer einen Store nennt (ein Store ist ein eigenständiges OpenSpec-Repository, das auf dieser Maschine 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 Changes lesen oder schreiben (new change, status, instructions, list, show, validate, archive, doctor, context). Andere Befehle benötigen das Flag nicht. Hinweise, die von Befehlen ausgegeben werden, enthalten das Flag bereits; behalte es bei Folgefragen bei. Ohne Store arbeiten die Befehle auf dem nächstgelegenen lokalen openspec/-Stammverzeichnis.

Eingabe: Optional kann ein Change-Name angegeben werden. Fehlt dieser, prüfe, ob er aus dem Gesprächskontext erschlossen werden kann. Bei vagen oder mehrdeutigen Angaben MUSST du mit der AskUserQuestion-Funktion nach verfügbaren Changes fragen.

Schritte

1. Change auswählen

   Wenn ein Name angegeben ist, verwende ihn. Andernfalls:

   • Aus dem Gesprächskontext erschließen, falls der Benutzer einen Change erwähnt hat
   • Automatisch auswählen, wenn nur ein aktiver Change existiert
   • Bei Mehrdeutigkeit openspec list --json ausführen, um verfügbare Changes zu ermitteln, und mit der AskUserQuestion-Funktion den Benutzer auswählen lassen

   Gebe immer bekannt: „Verwende Change: “ und wie man überschreibt (z. B. /opsx:apply <anderer>).

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

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

   Das JSON parsen, um 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 den Status prüfen)

3. Anwendungsanweisungen abrufen

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

   Diese Rückgabe enthält:

   • contextFiles: Artefakt-ID -> Array mit konkreten Dateipfaden (variiert je nach Schema – kann Vorschlag/Spezifikationen/Design/Aufgaben oder Spezifikation/Tests/Implementierung/Dokumentation sein)
   • Fortschritt (gesamt, erledigt, verbleibend)
   • Aufgabenliste mit Status
   • Dynamische Anweisung basierend auf dem aktuellen Zustand

   Zustände behandeln:

   • Wenn state: "blocked" (fehlende Artefakte): Nachricht anzeigen, openspec-continue-change vorschlagen
   • Wenn state: "all_done": gratulieren, Archivierung vorschlagen
   • Andernfalls: mit der Implementierung fortfahren

4. Kontextdateien lesen

   Jede Datei lesen, die unter contextFiles aus der Ausgabe der Anwendungsanweisungen aufgeführt ist. Die Dateien hängen vom verwendeten Schema ab:

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

5. Aktuellen Fortschritt anzeigen

   Anzeigen:

   • 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:

   • Anzeigen, an welcher Aufgabe gearbeitet wird
   • Die erforderlichen Codeänderungen vornehmen
   • Änderungen minimal und fokussiert halten
   • Aufgabe in der Aufgaben-Datei als erledigt markieren: - [ ] → - [x]
   • Mit der nächsten Aufgabe fortfahren

   Anhalten, wenn:

   • Aufgabe unklar ist → um Klarstellung bitten
   • Implementierung ein Designproblem aufdeckt → Aktualisierung der Artefakte vorschlagen
   • Fehler oder Blockade auftritt → melden und auf Anweisung warten
   • Benutzer unterbricht

7. Bei Abschluss oder Pause Status anzeigen

   Anzeigen:

   • In dieser Sitzung erledigte Aufgaben
   • Gesamtfortschritt: „N/M Aufgaben erledigt“
   • Wenn alles erledigt: Archivierung vorschlagen
   • Wenn pausiert: Grund erklären und auf Anweisung warten

Ausgabe während der Implementierung

## Implementierung: <change-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

**Change:** <change-name>
**Schema:** <schema-name>
**Fortschritt:** 7/7 Aufgaben erledigt ✓

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

Alle Aufgaben erledigt! Bereit zur Archivierung dieses Changes.

Ausgabe bei Pause (Problem aufgetreten)

## Implementierung pausiert

**Change:** <change-name>
**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?

Schutzmaßnahmen

• Aufgaben weiterbearbeiten, bis alles erledigt oder blockiert ist
• Vor dem Start immer Kontextdateien lesen (aus der Ausgabe der Anwendungsanweisungen)
• Wenn eine Aufgabe mehrdeutig ist, anhalten und vor der Implementierung fragen
• Wenn die Implementierung Probleme aufdeckt, anhalten und Artefakt-Aktualisierungen vorschlagen
• Codeänderungen minimal und auf jede Aufgabe beschränkt halten
• Aufgaben-Checkbox sofort nach Abschluss jeder Aufgabe aktualisieren
• Bei Fehlern, Blockaden oder unklaren Anforderungen anhalten – nicht raten
• contextFiles aus der CLI-Ausgabe verwenden, keine bestimmten Dateinamen annehmen

Fließende Workflow-Integration

Dieses Skill unterstützt das Modell „Aktionen an einem Change“:

• Kann jederzeit aufgerufen werden: Bevor alle Artefakte fertig sind (falls Aufgaben existieren), nach teilweiser Implementierung, verzahnt mit anderen Aktionen
• Erlaubt Artefakt-Aktualisierungen: Wenn die Implementierung Designprobleme aufdeckt, Aktualisierung der Artefakte vorschlagen – nicht phasengebunden, sondern fließend arbeiten