Fähigkeiten
Jede OpenSpec-Fähigkeit: Argumente, was sie erzeugt und was sie antwortet.
Die Fähigkeiten gibt es in zwei Sätzen:
- Kern: standardmäßig installiert, die Hauptplanungsschleife.
- Optional: nur installiert, wenn Sie sie hinzufügen, über Profile.
Jede Fähigkeit erwartet ein Projekt, das bereits OpenSpec verwendet. Vor ihrem ersten Schreibschritt prüft eine Fähigkeit, ob ein aufgelöstes Wurzelverzeichnis existiert. Was passiert, wenn keines vorhanden ist, hängt davon ab, wie die Fähigkeit erreicht wurde:
- Automatisch ausgewählt: Ihr Agent hat die Fähigkeit selbst gewählt, ohne dass Sie OpenSpec genannt haben. Er lässt OpenSpec fallen und beantwortet Ihre Anfrage normal, so wie es ohne installiertes OpenSpec der Fall wäre.
- Explizite OpenSpec-Anfrage: Sie haben OpenSpec genannt, die Fähigkeit genannt oder deren Befehl ausgeführt. Sie stoppt vor dem Schreiben und fragt, wie fortgefahren werden soll:
openspec inithier ausführen, einen Store mit--store <id>ansteuern oder ohne OpenSpec fortfahren. Sie wartet auf Ihre Antwort.
Befehle sind immer der zweite Fall. Ein Projekt, dessen openspec/config.yaml einen Store nennt, den dieser Rechner nicht auflösen kann (nicht registriert oder eine fehlerhafte store:-Zeile), wird nicht als nicht initialisiert behandelt: Die Fähigkeit stoppt und zeigt den Store-Fehler mit dessen Behebung. Keine Fähigkeit erstellt in einem der Fälle selbst ein openspec/-Verzeichnis. Die Einträge unten beschreiben, was jede Fähigkeit tut, sobald ein Wurzelverzeichnis vorhanden ist.
| Fähigkeit | Aufgabe | Typ |
|---|---|---|
| openspec-explore | Eine Idee durchdenken, bevor sie ein Änderungsvorschlag wird | Kern |
| openspec-propose | Einen Änderungsvorschlag mit allen Planungsartefakten in einem Schritt erstellen | Kern |
| openspec-apply-change | Die Aufgaben eines Änderungsvorschlags implementieren | Kern |
| openspec-update-change | Den Plan eines Änderungsvorschlags überarbeiten | Kern |
| openspec-sync-specs | Spezifikationsaktualisierungen eines Änderungsvorschlags in specs/ zusammenführen | Kern |
| openspec-archive-change | Einen abgeschlossenen Änderungsvorschlag ins Archiv verschieben | Kern |
| openspec-new-change | Einen Änderungsvorschlag als leeres Gerüst beginnen | Optional |
| openspec-continue-change | Das nächste Planungsartefakt erstellen, eines nach dem anderen | Optional |
| openspec-ff-change | Einen Änderungsvorschlag mit allen Artefakten erstellen, die die Implementierung braucht, in einem Durchlauf | Optional |
| openspec-verify-change | Prüfen, ob die Implementierung dem Plan entspricht | Optional |
| openspec-bulk-archive-change | Mehrere Änderungsvorschläge auf einmal archivieren | Optional |
| openspec-onboard | Den Workflow durch ein echtes Änderungsvorschlag von Anfang bis Ende lernen | Optional |
Jeder Eintrag unten nennt die Fähigkeit, die den nächsten Schritt besitzt. Wenn Ihr Profil diese Fähigkeit auslässt, nennen die installierten Dateien sie nie: Die Übergabe wird zum äquivalenten openspec-Befehl oder einer einfachen Aufforderung an Sie, und eine Zeile, die nur darauf zeigt, eine fehlende Fähigkeit anzusprechen, wird gar nicht erst geschrieben. Die Fähigkeiten, die Sie haben, übergeben also immer an Fähigkeiten, die Sie haben. Welchen Satz Sie erhalten, erfahren Sie unter Profile.
openspec-explore
Eine Idee durchdenken, bevor sie zu einem Änderungsvorschlag wird.
| Vertrag | Beschreibung |
|---|---|
| Argumente | Ein Thema: eine Idee, ein Problem, ein Vergleich oder der Name eines bestehenden Änderungsvorschlags, der im Kontext untersucht werden soll. Ohne Angabe wird der Erkundungsmodus gestartet. |
| Erstellt | Standardmäßig nichts. Es liest und untersucht nur. Auf Anfrage erfasst es Erkenntnisse: einen neuen Änderungsvorschlag unter openspec/changes/<name>/ oder Aktualisierungen am Vorschlag, Design, den Specs oder den Aufgaben eines bestehenden. Niemals Code. |
| Antwort | Eine offene Unterhaltung ohne erforderliche Ausgabe. Wenn sich das Denken verfestigt, fasst es das Problem, den Ansatz, offene Fragen und nächste Schritte zusammen und bietet an, diese zu erfassen. Sie entscheiden. Die Implementierung beginnt hier niemals. |
openspec-propose
Einen Änderungsvorschlag erstellen und alle seine Planungsartefakte in einem Schritt generieren.
| Vertrag | Beschreibung |
|---|---|
| Argumente | Ein Kebab-Case-Name (add-dark-mode) oder eine einfache Beschreibung. Fragt nach, wenn Sie keines davon angeben. |
| Erstellt | openspec/changes/<name>/ mit jedem Artefakt, das das Schema definiert, in Abhängigkeitsreihenfolge (spezifikationsgetrieben: Vorschlag, Spec-Deltas, Design, Aufgaben). Niemals Code. |
| Antwort | Die erstellten Artefakte, bereit zur Überprüfung, und der nächste Schritt. Stoppt dort; die Implementierung wartet auf openspec-apply-change. |
openspec-apply-change
Die Aufgaben eines Änderungsvorschlags implementieren, die Liste durcharbeiten bis zum Abschluss oder bis zu einer Blockade.
| Vertrag | Beschreibung |
|---|---|
| Argumente | Ein Änderungsvorschlagname (add-auth), optional. Wenn das Ziel mehrdeutig ist, listet es die aktiven Änderungsvorschläge auf und bittet Sie, eines auszuwählen. |
| Erstellt | Code: die minimalen Änderungen, die jede Aufgabe erfordert, in Ihren Projektdateien. Im Änderungsvorschlag hakt es jede abgeschlossene Aufgabe ab (- [ ] zu - [x]) in der verfolgten Datei, identifiziert durch sourcePath und einbasiertem line. Ein Schema kann Aufgaben über mehrere Dateien hinweg verfolgen. |
| Antwort | Fortschritt pro Aufgabe, dann eine Gesamtzahl (N/M Aufgaben abgeschlossen). Alles erledigt: schlägt openspec-archive-change vor. Blockiert durch fehlende Artefakte: verweist auf openspec-continue-change oder auf openspec status und openspec instructions, wenn dieser Skill nicht installiert ist (das Kernprofil lässt ihn weg). Unklare Aufgaben oder Fehler: pausiert und fragt nach. |
openspec-update-change
Bestehende Planungsartefakte eines Änderungsvorschlags überarbeiten und sie untereinander konsistent halten.
| Vertrag | Beschreibung |
|---|---|
| Argumente | Ein Änderungsvorschlagname, optional, plus die gewünschte Überarbeitung. Ohne angegebene Überarbeitung führt es eine Kohärenzprüfung durch: Artefakte werden untereinander auf Widersprüche, Lücken und Duplikate überprüft. |
| Erstellt | Bearbeitet Artefaktdateien, die bereits existieren. Eine Ausnahme: Für ein Artefakt, das als Glob geschrieben ist, wie specs/**/*.md, das bereits mindestens eine Datei hat, kann es eine fehlende Begleitdatei hinzufügen, sobald Sie den Pfad bestätigen. Ein Artefakt ohne Dateien ist die Aufgabe von openspec-continue-change. Ohne diesen Skill (das Kernprofil lässt ihn weg) verweist es stattdessen auf openspec status und openspec instructions. Niemals Code. |
| Antwort | Zeigt jede vorgeschlagene Überarbeitung und schreibt sie erst nach Ihrer Bestätigung, ein Artefakt nach dem anderen. Endet mit dem, was überarbeitet wurde, und dem nächsten Schritt; die Implementierung wartet auf openspec-apply-change. |
openspec-sync-specs
Spec-Updates eines Änderungsvorschlags in specs/ zusammenführen, ohne ihn zu archivieren.
| Vertrag | Beschreibung |
|---|---|
| Argumente | Ein Änderungsvorschlagname, optional. Sie können auch eine Teilmenge seiner Delta-Specs benennen, und nur diese werden synchronisiert. |
| Erstellt | Bearbeitet oder erstellt openspec/specs/<capability-path>/spec.md für jedes Delta-Spec und führt hinzugefügte, geänderte, entfernte und umbenannte Anforderungen in die Hauptspezifikation zusammen. Niemals Code. |
| Antwort | Eine Zusammenfassung pro Capability der hinzugefügten, geänderten, entfernten oder umbenannten Anforderungen, nachdem die aktualisierten Specs validiert wurden. Der Änderungsvorschlag bleibt aktiv; das Archivieren wartet auf openspec-archive-change. |
openspec-archive-change
Einen abgeschlossenen Änderungsvorschlag ins Archiv verschieben.
| Vertrag | Beschreibung |
|---|---|
| Argumente | Ein Änderungsvorschlagname, optional. |
| Erstellt | Verschiebt den Änderungsvorschlagordner nach openspec/changes/archive/YYYY-MM-DD-<name>/ (kein Datum hinzugefügt, wenn der Name bereits mit einem beginnt). Mit Ihrer Zustimmung synchronisiert es zuerst ausstehende Delta-Specs. Wenn openspec-sync-specs installiert ist, führt es diesen Workflow aus. Andernfalls führt es die Delta-Specs selbst in die Hauptspezifikationen zusammen. Niemals Code. |
| Antwort | Warnt und fragt vor dem Archivieren bei unvollständigen Artefakten oder Aufgaben nach und fragt, ob synchronisiert werden soll, wenn Delta-Specs existieren. Endet mit einer Zusammenfassung: Name, Schema, Archivort, Spec-Synchronisierungsstatus und etwaige Warnungen. |
openspec-new-change
Einen Änderungsvorschlag als leeres Gerüst beginnen.
| Vertrag | Beschreibung |
|---|---|
| Argumente | Ein Kebab-Case-Name (add-user-auth) oder eine einfache Beschreibung, plus ein Schema-Name nur für einen nicht standardmäßigen Workflow. Fragt, was Sie bauen möchten, wenn Sie keines davon angeben. |
| Erstellt | openspec/changes/<name>/ als leeres Gerüst: noch keine Artefakte, niemals Code. |
| Antwort | Name und Ort des Gerüsts, die Artefaktsequenz des Workflows, Status (0/N abgeschlossen) und die Vorlage des ersten Artefakts. Das Erstellen von Artefakten wartet auf openspec-continue-change. |
openspec-continue-change
Das nächste Planungsartefakt in einem Änderungsvorschlag erstellen, eines nach dem anderen.
| Vertrag | Beschreibung |
|---|---|
| Argumente | Ein Änderungsvorschlagname, optional. Wenn er immer noch mehrdeutig ist, bittet es Sie, aus den zuletzt geänderten auszuwählen. |
| Erstellt | Das einzelne nächste bereite Artefakt in der Sequenz des Schemas, geschrieben in den Änderungsvorschlagordner. Ein Artefakt pro Ausführung, niemals Code. |
| Antwort | Das erstellte Artefakt, Fortschritt (N von M abgeschlossen) und welche Artefakte dadurch freigeschaltet wurden. Wenn die Planung abgeschlossen ist, teilt es dies mit; die Implementierung geht über zu openspec-apply-change. |
openspec-ff-change
Einen Änderungsvorschlag und jedes für die Implementierung benötigte Planungsartefakt in einem Durchgang erstellen.
| Vertrag | Beschreibung |
|---|---|
| Argumente | Ein Kebab-Case-Name oder eine einfache Beschreibung. Fragt nach, wenn Sie keines davon angeben. Wenn der benannte Änderungsvorschlag bereits existiert, schlägt es vor, stattdessen fortzufahren. |
| Erstellt | openspec/changes/<name>/ und jedes Planungsartefakt, das die Implementierung erfordert, in Abhängigkeitsreihenfolge (spezifikationsgetrieben: Vorschlag, Specs, Design, Aufgaben), wobei nur Artefakte ausgelassen werden, die als übersprungen oder bedingt markiert sind. Niemals Code. |
| Antwort | Name und Ort des Änderungsvorschlags, jedes erstellte Artefakt und jedes bedingte Artefakt, das übersprungen wurde, sowie der Grund. Stoppt dort; die Implementierung wartet auf openspec-apply-change. |
openspec-verify-change
Prüfen, ob die Implementierung mit den Artefakten des Änderungsvorschlags übereinstimmt.
| Vertrag | Beschreibung |
|---|---|
| Argumente | Ein Änderungsvorschlagname, optional. Bei Mehrdeutigkeit fragt es nach und listet Änderungsvorschläge, die ein Aufgaben-Artefakt haben. |
| Erstellt | Nichts. Es liest die Artefakte des Änderungsvorschlags und die Codebasis. Die Verifikation ist nur berichtsgebend. |
| Antwort | Ein Bericht: eine Scorecard für Vollständigkeit, Korrektheit und Kohärenz, dann CRITICAL-, WARNING- und SUGGESTION-Probleme mit Empfehlungen und eine abschließende Bewertung der Archivierungsbereitschaft. Es ändert nichts und archiviert nicht. |
openspec-bulk-archive-change
Mehrere Änderungsvorschläge gleichzeitig archivieren.
| Vertrag | Beschreibung |
|---|---|
| Argumente | Keine. Es listet die aktiven Änderungsvorschläge auf und bittet Sie, beliebig viele auszuwählen, mit einer Option für alle. Wenn keine aktiv sind, teilt es dies mit und stoppt. |
| Erstellt | openspec/changes/archive/YYYY-MM-DD-<name>/ pro archiviertem Änderungsvorschlag (bereits datierte Namen behalten ihr Präfix). Die Spec-Deltas jedes einzelnen werden zuerst über openspec-sync-specs synchronisiert. Niemals Code. |
| Antwort | Eine Statustabelle pro Änderungsvorschlag und eine Bestätigung für den gesamten Batch, dann eine Zusammenfassung der archivierten, übersprungenen und fehlgeschlagenen sowie der Spec-Synchronisierungsergebnisse. Wenn zwei Änderungsvorschläge denselben Spec betreffen, prüft es die Codebasis und synchronisiert implementierte Deltas in der Reihenfolge von alt nach neu. |
openspec-onboard
Den Workflow durch einen echten Änderungsvorschlag von Anfang bis Ende erlernen.
| Vertrag | Beschreibung |
|---|---|
| Argumente | Keine. Es scannt Ihre Codebasis nach kleinen Einstiegsaufgaben und bittet Sie, eine auszuwählen oder Ihre eigene zu beschreiben. |
| Erstellt | Einen echten Änderungsvorschlag für die gewählte Aufgabe, ein Artefakt nach dem anderen, dann echten Code, sobald Sie die Implementierung bestätigen. Archiviert den Änderungsvorschlag am Ende. |
| Antwort | Ein erzählter Rundgang durch den vollständigen Zyklus mit Pausen für Ihre Eingabe: erkunden, erstellen, jedes Artefakt bauen, implementieren, archivieren. Endet mit einer Zusammenfassung und einem Hinweis auf openspec-propose. Dauert etwa 15 bis 20 Minuten. |