OpenSpec

Glossar ​

Jeder OpenSpec-Begriff an einem Ort, in verständlicher Sprache definiert. Einmal durchgelesen, liest sich der Rest der Dokumentation schneller.

Die Begriffe sind thematisch gruppiert und innerhalb jeder Gruppe alphabetisch sortiert.

Die zentralen Substantive ​

Spezifikation. Ein Dokument, das beschreibt, wie ein Teil Ihres Systems funktioniert. Spezifikationen befinden sich in openspec/specs/, sind nach Domäne organisiert und bestehen aus Anforderungen und Szenarien. Die Spezifikation ist die vereinbarte Antwort auf die Frage „Was tut diese Software?" Siehe Konzepte.

Single Source of Truth. Der gesamte openspec/specs/-Ordner. Er enthält das aktuelle, vereinbarte Verhalten Ihres Systems. Änderungen schlagen Bearbeitungen vor; das Archivieren wendet sie an.

Änderung. Eine Arbeitseinheit, verpackt als Ordner unter openspec/changes/<name>/. Eine Änderung enthält alles zu dieser Arbeit: ihren Vorschlag, das Design, die Aufgaben und die Spezifikationsänderungen, die sie einführt. Eine Änderung, eine Funktion oder ein Fehlerfix.

Artefakt. Ein Dokument innerhalb einer Änderung. Die Standard-Artefakte sind der Vorschlag, die Delta-Spezifikationen, das Design und die Aufgaben. Sie werden in Abhängigkeitsreihenfolge erstellt und fließen ineinander ein.

Delta-Spezifikation. Eine Spezifikation innerhalb einer Änderung, die nur beschreibt, was sich ändert, mit ADDED-, MODIFIED- und REMOVED-Abschnitten, anstatt die gesamte Spezifikation neu zu formulieren. Dadurch kann OpenSpec bestehende Systeme sauber bearbeiten. Siehe Konzepte.

Domäne. Eine logische Gruppierung für Spezifikationen, wie auth/, payments/ oder ui/. Sie wählen Domänen, die zu Ihrer Vorstellung Ihres Systems passen.

Innerhalb einer Spezifikation ​

Anforderung. Ein einzelnes Verhalten, das das System aufweisen muss, in der Regel mit einem RFC-2119-Schlüsselwort formuliert: „Das System SHALL Sitzungen nach 30 Minuten ablaufen lassen." Anforderungen beschreiben das Was, nicht das Wie.

Szenario. Ein konkretes, testbares Beispiel einer Anforderung in Aktion, typischerweise in Given/When/Then-Form. Szenarien machen eine Anforderung überprüfbar: Sie könnten daraus einen automatisierten Test schreiben.

RFC-2119-Schlüsselwörter. Die Wörter MUST, SHALL, SHOULD und MAY, die standardisierte Bedeutungen hinsichtlich der Strenge einer Anforderung tragen. MUST und SHALL sind absolut. SHOULD ist empfohlen, mit Raum für Ausnahmen. MAY ist optional. Der Name stammt aus dem Internetstandard-Dokument, das sie definiert hat.

Die Artefakte ​

Vorschlag (proposal.md). Das Warum und Was einer Änderung: ihre Absicht, ihr Umfang und der grobe Ansatz. Das erste Artefakt, das Sie erstellen.

Design (design.md). Das Wie: technischer Ansatz, Architekturentscheidungen und die Dateien, die Sie anfassen werden. Für einfache Änderungen optional.

Aufgaben (tasks.md). Die Implementierungs-Checkliste mit Kontrollkästchen. Die KI arbeitet während /opsx:apply durch sie hindurch und hakt Punkte ab, während sie voranschreitet.

Der Lebenszyklus ​

Archivieren. Der Vorgang, eine Änderung abzuschließen. Ihre Delta-Spezifikationen werden in die Hauptspezifikationen übernommen, und der Änderungsordner wird nach openspec/changes/archive/YYYY-MM-DD-<name>/ verschoben. Nach dem Archivieren beschreiben Ihre Spezifikationen die neue Realität. Siehe Konzepte.

Synchronisieren. Das Übernehmen der Delta-Spezifikationen einer Änderung in die Hauptspezifikationen ohne die Änderung zu archivieren. In der Regel automatisch (Archivieren bietet es an), aber auch eigenständig als /opsx:sync für langlaufende Änderungen verfügbar. Siehe Befehle.

Arbeitsablauf und Befehle ​

OPSX. Der aktuelle Standard-OpenSpec-Arbeitsablauf, aufgebaut auf fließenden Aktionen statt starren Phasen. Seine Slash-Befehle beginnen alle mit /opsx:. Siehe OPSX-Arbeitsablauf.

Slash-Befehl. Ein Befehl, den Sie in den Chat Ihres KI-Assistenten eingeben, wie /opsx:propose. Slash-Befehle steuern den Arbeitsablauf. Sie sind keine Terminalbefehle. Siehe So funktionieren Befehle.

Erkunden (/opsx:explore). Der Denkpartner-Befehl. Er liest Ihren Code, vergleicht Optionen und macht eine vage Idee zu einem konkreten Plan, ohne Artefakte zu erstellen und ohne Code zu schreiben. Der empfohlene Einstiegspunkt, wann immer Sie ein Problem, aber noch keinen Plan haben. Siehe Erst erkunden.

CLI. Das openspec-Programm, das Sie in Ihrem Terminal ausführen. Es richtet Projekte ein, listet und validiert Änderungen, öffnet das Dashboard und archiviert. Die Terminal-Hälfte von OpenSpec. Siehe CLI.

Skill. Ein Ordner mit Anweisungen (.../skills/openspec-*/SKILL.md), den Ihr KI-Assistent automatisch erkennt und befolgt. Skills sind der sich entwickelnde Querschnittsstandard für die Bereitstellung des OpenSpec-Arbeitsablaufs an Ihren Assistenten.

Befehlsdatei. Eine tool-spezifische Slash-Befehlsdatei (.../commands/opsx-*). Der ältere Bereitstellungsmechanismus, der weiterhin neben Skills unterstützt wird. Sie greifen selten direkt darauf zu.

Profil. Der Satz der in Ihrem Projekt installierten Slash-Befehle. Core (Standard) umfasst propose, explore, apply, update, sync, archive. Der erweiterte Satz fügt new, continue, ff, verify, bulk-archive, onboard hinzu. Ändern Sie es mit openspec config profile.

Bereitstellung. Ob OpenSpec für Ihre Tools Skills, Befehlsdateien oder beides installiert. Global konfiguriert und angewendet mit openspec update.

Anpassung ​

Schema. Die Definition, welche Artefakte ein Arbeitsablauf hat und wie sie voneinander abhängen. Das eingebaute Standard-Schema ist spec-driven (Vorschlag → Spezifikationen → Design → Aufgaben). Sie können es forken oder Ihr eigenes schreiben. Siehe Anpassung.

Vorlage. Eine Markdown-Datei innerhalb eines Schemas, die bestimmt, was die KI für ein bestimmtes Artefakt generiert. Das Bearbeiten einer Vorlage ändert die KI-Ausgabe sofort, ohne erneute Kompilierung.

Projekt-Konfiguration (openspec/config.yaml). Projekt-spezifische Einstellungen: das Standard-Schema, der in jeden Planungsanfrage injizierte context: und artefakt-spezifische rules:. Der einfachste Weg, OpenSpec über Ihren Stack und Ihre Konventionen zu informieren. Siehe Anpassung.

Kontextinjektion. Das Hinterlegen von Projekt-Hintergrundinformationen im context:-Feld von config.yaml, damit sie automatisch zu jedem von der KI generierten Artefakt hinzugefügt werden. Zuverlässiger als darauf zu hoffen, dass die KI eine separate Datei liest.

Abhängigkeitsgraph. Der gerichtete Graph, der durch die requires:-Beziehungen der Artefakte gebildet wird. Es handelt sich um einen DAG (gerichteter azyklischer Graph: Pfeile zeigen nur vorwärts, nie in einer Schleife), und OpenSpec nutzt ihn, um zu wissen, was Sie als Nächstes erstellen können.

Enabler, keine Hürden. Das Prinzip, dass Artefakt-Abhängigkeiten zeigen, was als Nächstes möglich wird, nicht was als Nächstes erforderlich ist. Sie können jedes Artefakt jederzeit erneut besuchen und bearbeiten. Siehe Kernkonzepte auf einen Blick.

Koordination über Repos hinweg (Beta) ​

Diese Begriffe gelten nur, wenn Ihre Planung mehr als ein Repo umfasst. Sie befinden sich in der Beta. Die meisten Benutzer können sie ignorieren. Siehe den Stores-Benutzerleitfaden.

Store. Ein eigenständiges Repo, dessen einziger Zweck die Planung ist. Es hat dieselbe openspec/-Struktur, die Sie bereits kennen (Spezifikationen und Änderungen), plus eine kleine Identitätsdatei. Sie registrieren es einmal auf Ihrem Rechner, nach Namen, und danach kann jeder OpenSpec-Befehl von überall aus darin arbeiten.

Referenz. Eine Deklaration in der openspec/config.yaml eines Code-Repos, die einen Store angibt, auf den dieses Repo zurückgreift. Referenzen sind schreibgeschützt: Das Repo behält seinen eigenen Root, und openspec instructions erhält einen Index der Spezifikationen des referenzierten Stores, jeweils mit dem exakten Befehl zum Abrufen.

Arbeitskontext. Was openspec context für das aktuelle Repo zusammenstellt: seinen OpenSpec-Root plus jeden Store, auf den er verweist, jeweils mit der Abrufmethode. Die Antwort auf die Frage „Womit arbeite ich?"

Workset. Ein persönlicher, lokal auf dem Rechner gespeicherter Satz von Ordnern, die Sie gemeinsam öffnen (ein Store neben den Code-Repos, an denen Sie arbeiten). Explizit erstellt mit openspec workset create; nichts über diese lokalen Pfade wird im gemeinsamen Planungs-Repo committet.

Siehe auch ​