williamsnieves/landing-factory

Aufgaben aus einem OpenSpec-Change implementieren.

Store-Auswahl: Wenn der Benutzer einen Store benennt (ein Store ist ein eigenständiges OpenSpec-Repository, 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 Changes lesen oder schreiben (new change, status, instructions, list, show, validate, archive, doctor, context, schemas, view). Nach der Auswahl behandle --store <id> als klebrig für den Rest des Arbeitsablaufs. Jedes nicht abgegrenzte Beispiel dieser Befehle unten ist eine Kurzform: Führe sie mit dem angehängten Flag aus. Führe beispielsweise openspec status --change "<name>" --json --store "<id>" aus, nicht die nicht abgegrenzte Form. Andere Befehle akzeptieren das Flag nicht. Von Befehlen ausgegebene Hinweise enthalten das Flag bereits; behalte es bei Folgefragen bei. Ohne einen Store agieren die Befehle im nächstgelegenen lokalen openspec/-Verzeichnis.

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

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, verwendet das Projekt OpenSpec über einen Store, den es deklariert, der aber auf 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 folgenden Verzweigungen: Halte vor dem Schreiben an und zeige dem Benutzer die message und den fix dieses Fehlers.

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

• Automatisch ausgewählt: Du hast diesen Arbeitsablauf selbst gewählt, ohne dass der Benutzer OpenSpec, diesen Skill oder dessen Schrägstrich-Befehl genannt hat. Höre auf, OpenSpec zu verwenden, und beantworte die Anfrage normal, als ob OpenSpec nicht installiert wäre. Bitte den Benutzer nicht, etwas einzurichten, und erwähne die OpenSpec-Einrichtung nicht.
• Explizite OpenSpec-Anfrage: Der Benutzer hat OpenSpec, diesen Skill oder dessen Schrägstrich-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 seine Antwort.

Erstelle in beiden Verzweigungen niemals das Root-Verzeichnis als Nebeneffekt: Führe openspec init erst aus, wenn der Benutzer danach fragt, erstelle keine openspec/-Dateien manuell und lasse keinen Befehl sie erstellen.

Eingabe: Gib optional einen Change-Namen an (z. B. /opsx:apply add-auth. Wenn nicht angegeben, prüfe, ob er aus dem Gesprächskontext abgeleitet werden kann. Bei vagen oder mehrdeutigen Angaben MUSST du nach verfügbaren Changes fragen.

Schritte

1. Change auswählen

   Wenn ein Name angegeben ist, verwende ihn. Andernfalls:

   • Leite ihn aus dem Gesprächskontext ab, wenn der Benutzer einen Change erwähnt hat
   • Wähle automatisch aus, wenn nur ein aktiver Change existiert
   • Bei Mehrdeutigkeit führe openspec list --json aus, um verfügbare Changes zu erhalten, und frage den Benutzer, einen auszuwählen

   Gib immer bekannt: „Verwende Change: “ und wie überschrieben werden kann (z. B. /opsx:apply <anderer>).

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

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

   Analysiere das JSON, um zu verstehen:

   • schemaName: Der verwendete Arbeitsablauf (z. B. "spec-driven")
   • planningHome, changeRoot und actionContext: Planungsumfang und Bearbeitungseinschränkungen
   • Welches Artefakt die Aufgaben enthält (normalerweise "tasks" bei spec-driven, für andere Status prüfen)

3. Anwendungsanweisungen abrufen

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

   Dies gibt zurück:

   • contextFiles: Artefakt-ID -> Array konkreter Dateipfade (variiert je nach Schema – kann Vorschlag/Spezifikationen/Design/Aufgaben oder Spezifikation/Tests/Implementierung/Dokumentation sein)
   • Fortschritt (gesamt, abgeschlossen, verbleibend)
   • Aufgabenliste mit Status, Quellpfad und Quellzeile
   • Dynamische Anweisung basierend auf dem aktuellen Zustand
   • Optional context: aktuelle erforderliche Projekteingabe aus dem ausgewählten Root
   • Optional operationGuidance: aktuelle beratende Hinweise für die Anwendung
   • missingArtifacts (wenn 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) 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 befolge die CLI-Anweisung, um die schema-konfigurierte Tracking-Datei aus vorhandenen Planungsartefakten zu erstellen oder zu reparieren. Gehe nicht davon aus, dass ein anderes Artefakt bereit ist, und beginne nicht mit der Implementierung, während der Status blockiert ist.
   • Wenn state: "all_done": Melde, dass alle verfolgten Aufgaben abgeschlossen sind, und schlage vor der Archivierung eine Überprüfung oder Verifizierung vor, je nach Bedarf.
   • Andernfalls fahre mit der Implementierung fort.

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

   Halte beide Felder getrennt von CLI-zurückgegebenem Status, fehlenden Artefakten, Aufgaben, Fortschritt, contextFiles und der integrierten instruction. Sie sind kein Beleg für die Aufgabenerledigung, ersetzen nicht die integrierte Anweisung und erlauben nicht, einen blockierten Zustand zu umgehen. Wenn der Kontext 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 jeden Dateipfad, der 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: 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 abgeschlossen“
   • Übersicht der verbleibenden Aufgaben
   • Dynamische Anweisung von der CLI

6. Aufgaben implementieren (Schleife, bis fertig oder blockiert)

   Für jede anstehende Aufgabe:

   • Zeige an, an welcher Aufgabe gearbeitet wird
   • Nimm die erforderlichen Codeänderungen vor
   • Halte Änderungen minimal und fokussiert
   • Bestätige vor der Bearbeitung, dass die Checkbox 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 als abgeschlossen an ihrem zurückgegebenen sourcePath und line: - [ ] → - [x]
   • Führe die Anwendungsanweisungen erneut aus und bestätige, dass diese Aufgabe jetzt abgeschlossen ist und sich der Fortschritt geändert hat
   • Fahre mit der nächsten Aufgabe fort

   Pausiere bei:

   • Aufgabe ist unklar → bitte um Klärung
   • Implementierung offenbart ein Designproblem → schlage vor, Artefakte zu aktualisieren
   • Eine Aufgabe erfordert Arbeiten, die über die Beschreibung der Spezifikation und Aufgaben hinausgehen, oder du bist versucht, spezifiziertes Verhalten fallenzulassen, einzuschränken, zu verschieben oder Ausnahmen zu akzeptieren, um es anzupassen → zeige den hinzugefügten Umfang auf und frage; nimm ihn nicht stillschweigend auf
   • Fehler oder Blockierer aufgetreten → melde und warte auf Anleitung
   • Benutzer unterbricht

7. Bei Abschluss oder Pause Status anzeigen

   Zeige an:

   • In dieser Sitzung abgeschlossene Aufgaben
   • Gesamtfortschritt: „N/M Aufgaben abgeschlossen“
   • Wenn alles erledigt: Melde, dass die verfolgten Aufgaben abgeschlossen sind, und schlage vor der Archivierung eine Überprüfung oder Verifizierung vor, je nach Bedarf
   • Wenn pausiert: Erkläre warum und warte auf Anleitung

Ausgabe während der Implementierung

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

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

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

Ausgabe bei Abschluss

## Implementierung abgeschlossen

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

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

Alle verfolgten Aufgaben sind abgeschlossen. Überprüfe oder verifiziere den Change
vor der Archivierung. Du kannst diesen Change mit `/opsx:archive` archivieren.

Ausgabe bei Pause (Problem aufgetreten)

## Implementierung pausiert

**Change:** <change-name>
**Schema:** <schema-name>
**Fortschritt:** 4/7 Aufgaben abgeschlossen

### Aufgetretenes Problem
<Beschreibung des Problems>

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

Was möchtest du tun?

Schutzmaßnahmen

• Arbeite Aufgaben weiter durch, bis alle erledigt oder blockiert sind
• Lese Kontextdateien immer vor Beginn (aus der Ausgabe der Anwendungsanweisungen)
• Wenn eine Aufgabe mehrdeutig ist, pausiere und frage vor der Implementierung
• Wenn die Implementierung Probleme offenbart, pausiere und schlage Aktualisierungen der Artefakte vor
• Halte Codeänderungen minimal und auf jede Aufgabe beschränkt
• Aktualisiere das Aufgaben-Kontrollkästchen sofort nach Abschluss jeder Aufgabe
• Pausiere bei Fehlern, Blockierern oder unklaren Anforderungen – rate nicht
• Wenn eine Aufgabe Arbeiten erfordert, die über die Beschreibung der Spezifikation hinausgehen, zeige den hinzugefügten Umfang auf und pausiere – schränke spezifiziertes Verhalten niemals stillschweigend ein, verschiebe es oder vereinfache es weg
• Markiere eine Aufgabe nur dann als - [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 für jede Aufgabe den sourcePath und die line, um ihr genaues Kontrollkästchen zu aktualisieren
• Verwende Kontext oder Betriebsanleitung nicht als Beweis dafür, dass eine Aufgabe abgeschlossen ist
• Wende relevanten Projektkontext an; melde Konflikte mit steuernden Arbeitsablaufeingaben
• Berücksichtige jeden Anleitungseintrag; erkläre nicht anwendbare oder widersprüchliche Ratschläge
• Kopiere Laufzeitkontext oder Betriebsanleitung nicht in Implementierungsdateien oder Planungsartefakte
• Behalte das CLI-gesteuerte Verhalten bei blockiert/bereit/alles-erledigt und die Kriterien für den Abschluss bei

Integration in einen fließenden Arbeitsablauf

Dieser Skill unterstützt das Modell "Aktionen an einem Change":

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