OPSX Workflow
Feedback willkommen auf Discord.
Was ist das?
OPSX ist jetzt der Standard-Workflow für OpenSpec.
Es ist ein fließender, iterativer Workflow für OpenSpec-Änderungen. Keine starren Phasen mehr – nur Aktionen, die Sie jederzeit durchführen können.
Warum dies existiert
Der bisherige OpenSpec-Workflow funktioniert, ist aber eingeschränkt:
- Anweisungen sind fest verdrahtet – in TypeScript vergraben, du kannst sie nicht ändern
- Alles oder nichts – ein großer Befehl erstellt alles, einzelne Teile können nicht getestet werden
- Feste Struktur – gleicher Workflow für alle, keine Anpassungsmöglichkeiten
- Blackbox – wenn die KI-Ausgabe schlecht ist, kannst du die Prompts nicht anpassen
OPSX öffnet es. Jetzt kann jeder:
- Mit Anweisungen experimentieren – eine Vorlage bearbeiten und sehen, ob die KI besser wird
- Granular testen – die Anweisungen jedes Artefakts unabhängig validieren
- Workflows anpassen – eigene Artefakte und Abhängigkeiten definieren
- Schnell iterieren – eine Vorlage ändern, sofort testen, kein Neuaufbau
Legacy workflow: OPSX:
┌────────────────────────┐ ┌────────────────────────┐
│ Hardcoded in package │ │ schema.yaml │◄── Du editierst dies
│ (can't change) │ │ templates/*.md │◄── Oder dies
│ ↓ │ │ ↓ │
│ Wait for new release │ │ Instant effect │
│ ↓ │ │ ↓ │
│ Hope it's better │ │ Test it yourself │
└────────────────────────┘ └────────────────────────┘Das ist für alle:
- Teams – Workflows erstellen, die zu deiner tatsächlichen Arbeitsweise passen
- Power-User – Prompts anpassen, um bessere KI-Ausgaben für deine Codebasis zu erhalten
- OpenSpec-Mitwirkende – mit neuen Ansätzen experimentieren, ohne Releases
Wir alle lernen noch, was am besten funktioniert. OPSX lässt uns gemeinsam lernen.
Das Benutzererlebnis
Das Problem mit linearen Workflows: Du bist in der „Planungsphase“, dann in der „Implementierungsphase“, dann „fertig“. Aber echte Arbeit funktioniert nicht so. Du implementierst etwas, stellst fest, dass dein Design falsch war, musst Spezifikationen aktualisieren, implementierst weiter. Lineare Phasen kämpfen gegen die tatsächliche Arbeitsweise.
OPSX-Ansatz:
- Aktionen, nicht Phasen – erstellen, implementieren, aktualisieren, archivieren – jede davon jederzeit
- Abhängigkeiten als Ermöglicher – sie zeigen, was möglich ist, nicht was als Nächstes erforderlich ist
proposal ──→ specs ──→ design ──→ tasks ──→ implementEinrichtung
# Make sure you have openspec installed — skills are automatically generated
openspec initDies erstellt Fähigkeiten in .claude/skills/ (oder Äquivalent), die KI-Coding-Assistenten automatisch erkennen.
Standardmäßig verwendet OpenSpec das core-Workflow-Profil (propose, explore, apply, update, sync, archive). Wenn du die erweiterten Workflow-Befehle (new, continue, ff, verify, bulk-archive, onboard) verwenden möchtest, konfiguriere sie mit openspec config profile und wende sie mit openspec update an.
Während der Einrichtung wirst du aufgefordert, eine Projektkonfiguration (openspec/config.yaml) zu erstellen. Diese ist optional, aber empfohlen.
Projektkonfiguration
Die Projektkonfiguration ermöglicht es dir, Standardwerte festzulegen und projektspezifischen Kontext in alle Artefakte einzufügen.
Konfiguration erstellen
Die Konfiguration wird während openspec init erstellt oder manuell:
# openspec/config.yaml
schema: spec-driven
context: |
Tech stack: TypeScript, React, Node.js
API conventions: RESTful, JSON responses
Testing: Vitest for unit tests, Playwright for e2e
Style: ESLint with Prettier, strict TypeScript
rules:
proposal:
- Include rollback plan
- Identify affected teams
specs:
- Use Given/When/Then format for scenarios
design:
- Include sequence diagrams for complex flowsKonfigurationsfelder
| Feld | Typ | Beschreibung |
|---|---|---|
schema | string | Standardschema für neue Änderungen (z. B. spec-driven) |
context | string | Projektkontext, der in alle Artefakt-Anweisungen eingefügt wird |
rules | object | Regeln pro Artefakt, mit Artefakt-ID als Schlüssel |
So funktioniert es
Schema-Priorität (höchste zu niedrigste):
- CLI-Flag (
--schema <name>) - Änderungs-Metadaten (
.openspec.yamlim Änderungsverzeichnis) - Projektkonfiguration (
openspec/config.yaml) - Standard (
spec-driven)
Kontext-Injektion:
- Der Kontext wird den Anweisungen jedes Artefakts vorangestellt
- In
<context>...</context>-Tags eingefügt - Hilft der KI, die Konventionen deines Projekts zu verstehen
Regel-Injektion:
- Regeln werden nur für passende Artefakte injiziert
- In
<rules>...</rules>-Tags eingefügt - Erscheinen nach dem Kontext, vor der Vorlage
Artefakt-IDs nach Schema
spec-driven (Standard):
proposal— Änderungsvorschlagspecs— Spezifikationendesign— Technisches Designtasks— Implementierungsaufgaben
Validierung der Konfiguration
- Unbekannte Artefakt-IDs in
ruleserzeugen Warnungen - Schema-Namen werden gegen verfügbare Schemas validiert
- Der Kontext hat eine Größenbeschränkung von 50 KB
- Ungültiges YAML wird mit Zeilennummern gemeldet
Fehlerbehebung
„Unbekannte Artefakt-ID in rules: X“
- Überprüfe, ob die Artefakt-IDs zu deinem Schema passen (siehe Liste oben)
- Führe
openspec schemas --jsonaus, um die Artefakt-IDs für jedes Schema zu sehen
Konfiguration wird nicht angewendet:
- Stelle sicher, dass die Datei unter
openspec/config.yamlliegt (nicht.yml) - Überprüfe die YAML-Syntax mit einem Validator
- Konfigurationsänderungen werden sofort wirksam (kein Neustart erforderlich)
Kontext zu groß:
- Der Kontext ist auf 50 KB begrenzt
- Fasse zusammen oder verlinke stattdessen auf externe Dokumentation
Befehle
| Befehl | Was es tut |
|---|---|
/opsx:propose | Erstellt eine Änderung und generiert Planungsartefakte in einem Schritt (Standard-Schnellpfad) |
/opsx:explore | Durchdenken von Ideen, Untersuchen von Problemen, Klären von Anforderungen |
/opsx:new | Startet ein neues Änderungsgerüst (erweiterter Workflow) |
/opsx:continue | Erstellt das nächste Artefakt (erweiterter Workflow) |
/opsx:ff | Schnellvorlauf für Planungsartefakte (erweiterter Workflow) |
/opsx:apply | Implementiert Aufgaben und aktualisiert Artefakte bei Bedarf |
/opsx:update | Überarbeitet die Planungsartefakte einer Änderung und hält sie kohärent |
/opsx:verify | Validiert die Implementierung gegen Artefakte (erweiterter Workflow) |
/opsx:sync | Führt Delta-Spezifikationen in die Hauptspezifikationen zusammen (optional) |
/opsx:archive | Archiviert, wenn abgeschlossen |
/opsx:bulk-archive | Archiviert mehrere abgeschlossene Änderungen (erweiterter Workflow) |
/opsx:onboard | Geführter Durchgang durch eine Ende-zu-Ende-Änderung (erweiterter Workflow) |
Verwendung
Eine Idee erkunden
/opsx:exploreDenke über Ideen nach, untersuche Probleme, vergleiche Optionen. Keine Struktur erforderlich – nur ein Denkpartner. Wenn sich Erkenntnisse kristallisieren, wechsle zu /opsx:propose (Standard) oder /opsx:new//opsx:ff (erweitert).
Eine neue Änderung starten
/opsx:proposeErstellt die Änderung und generiert die Planungsartefakte, die vor der Implementierung benötigt werden.
Wenn du erweiterte Workflows aktiviert hast, kannst du stattdessen Folgendes verwenden:
/opsx:new # scaffold only
/opsx:continue # create one artifact at a time
/opsx:ff # create all planning artifacts at onceArtefakte erstellen
/opsx:continueZeigt, was basierend auf Abhängigkeiten erstellt werden kann, und erstellt dann ein Artefakt. Wiederholt verwenden, um deine Änderung schrittweise aufzubauen.
/opsx:ff add-dark-modeErstellt alle Planungsartefakte auf einmal. Verwende es, wenn du ein klares Bild davon hast, was du baust.
Implementieren (der fließende Teil)
/opsx:applyArbeitet Aufgaben ab und hakt sie ab. Wenn du mehrere Änderungen gleichzeitig bearbeitest, kannst du /opsx:apply <name> ausführen; andernfalls sollte es aus dem Gespräch ableiten und dich zur Auswahl auffordern, wenn es nicht erkennen kann.
Eine Änderung aktualisieren
/opsx:update add-dark-mode - we're storing the theme in a cookie nowÜberarbeitet die vorhandenen Planungsartefakte der Änderung und hält sie kohärent – in jede Richtung (eine Design-Änderung kann sich bis zum Vorschlag auswirken). Nur Planungsartefakte: Es bearbeitet niemals Code und erstellt niemals fehlende Artefakte (das macht /opsx:continue). Jede Bearbeitung wird zuerst mit dir bestätigt. Wenn die Änderung bereits implementiert wurde, empfiehlt es /opsx:apply, damit der Code mit dem überarbeiteten Plan Schritt hält. Wenn deine Überarbeitung die Absicht der Änderung ändert, starte stattdessen neu – siehe Wann aktualisieren vs. neu starten.
Delta-Spezifikationen synchronisieren
/opsx:syncFührt die Delta-Spezifikationen der aktuellen Änderung in deine Haupt-openspec/specs/ zusammen, ohne zu archivieren – die Änderung bleibt aktiv. Es wendet das gesamte Delta an: Eine Anforderung unter ## REMOVED wird aus der Hauptspezifikation gelöscht und eine umbenannte wird direkt umbenannt, während Inhalte, die das Delta nicht erwähnt, unangetastet bleiben. Die Synchronisierung ist optional – die Archivierung fordert dich auf, zuerst zu synchronisieren, wenn du es noch nicht getan hast. Verwende es, wenn du Hauptspezifikationen vor dem Archivieren aktualisiert haben möchtest, wenn eine parallele Änderung auf Spezifikationen aufbauen muss, die diese gerade hinzugefügt hat, oder wenn du die zusammengeführte Hauptspezifikation vor dem Archivieren überprüfen möchtest.
Abschließen
/opsx:archive # Move to archive when done (prompts to sync specs if needed)Wann aktualisieren vs. neu starten
Du kannst deinen Vorschlag oder deine Spezifikationen jederzeit vor der Implementierung bearbeiten. Aber wann wird die Verfeinerung zu „das ist eine andere Arbeit“?
Was ein Vorschlag erfasst
Ein Vorschlag definiert drei Dinge:
- Absicht – Welches Problem löst du?
- Umfang – Was ist innerhalb/außerhalb der Grenzen?
- Ansatz – Wie wirst du es lösen?
Die Frage ist: Was hat sich geändert und wie stark?
Vorhandene Änderung aktualisieren, wenn:
Gleiche Absicht, verfeinerte Umsetzung
- Du entdeckst Randfälle, die du nicht bedacht hast
- Der Ansatz muss angepasst werden, aber das Ziel bleibt unverändert
- Die Implementierung zeigt, dass das Design leicht daneben lag
Umfang wird kleiner
- Du erkennst, dass der volle Umfang zu groß ist, möchtest zuerst ein MVP veröffentlichen
- „Dunkelmodus hinzufügen“ → „Dunkelmodus-Umschalter hinzufügen (Systemeinstellung in v2)“
Lernbasierte Korrekturen
- Die Codebasis ist nicht so strukturiert, wie du dachtest
- Eine Abhängigkeit funktioniert nicht wie erwartet
- „CSS-Variablen verwenden“ → „Stattdessen Tailwinds
dark:-Präfix verwenden“
Eine neue Änderung starten, wenn:
Absicht grundlegend geändert
- Das Problem selbst ist jetzt anders
- „Dunkelmodus hinzufügen“ → „Umfassendes Themesystem mit benutzerdefinierten Farben, Schriftarten, Abständen hinzufügen“
Umfang explodiert
- Die Änderung ist so stark gewachsen, dass es im Wesentlichen eine andere Arbeit ist
- Der ursprüngliche Vorschlag wäre nach Aktualisierungen nicht wiederzuerkennen
- „Login-Fehler beheben“ → „Authentifizierungssystem neu schreiben“
Original ist abschließbar
- Die ursprüngliche Änderung kann als „erledigt“ markiert werden
- Neue Arbeit steht allein, keine Verfeinerung
- „Dunkelmodus-MVP abschließen“ → Archivieren → Neue Änderung „Dunkelmodus erweitern“
Die Heuristiken
┌─────────────────────────────────────┐
│ Is this the same work? │
└──────────────┬──────────────────────┘
│
┌──────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
Same intent? >50% overlap? Can original
Same problem? Same scope? be "done" without
│ │ these changes?
│ │ │
┌────────┴────────┐ ┌──────┴──────┐ ┌───────┴───────┐
│ │ │ │ │ │
YES NO YES NO NO YES
│ │ │ │ │ │
▼ ▼ ▼ ▼ ▼ ▼
UPDATE NEW UPDATE NEW UPDATE NEW| Test | Aktualisieren | Neue Änderung |
|---|---|---|
| Identität | „Gleiche Sache, verfeinert“ | „Andere Arbeit“ |
| Umfangsüberschneidung | >50% Überlappung | <50% Überlappung |
| Abschluss | Kann ohne Änderungen nicht als „erledigt“ markiert werden | Kann das Original abschließen, neue Arbeit steht allein |
| Erzählung | Aktualisierungskette erzählt kohärente Geschichte | Patches würden eher verwirren als klären |
Das Prinzip
Aktualisieren erhält Kontext. Neue Änderung bietet Klarheit.
Wähle Aktualisieren, wenn die Geschichte deines Denkens wertvoll ist. Wähle Neu, wenn ein Neubeginn klarer wäre als Flicken.
Stell es dir wie Git-Branches vor:
- Mach weiter Commits, während du an derselben Funktion arbeitest
- Starte einen neuen Branch, wenn es wirklich neue Arbeit ist
- Manchmal eine partielle Funktion zusammenführen und für Phase 2 neu starten
Was ist anders?
Legacy (/openspec:proposal) | OPSX (/opsx:*) | |
|---|---|---|
| Struktur | Ein großes Vorschlagsdokument | Diskrete Artefakte mit Abhängigkeiten |
| Workflow | Lineare Phasen: Plan → Implementierung → Archivierung | Flexible Aktionen – jederzeit alles tun |
| Iteration | Rückgängigmachen ist umständlich | Artefakte bei neuen Erkenntnissen aktualisieren |
| Anpassung | Feste Struktur | Schema-basiert (definiere deine eigenen Artefakte) |
Die zentrale Erkenntnis: Arbeit verläuft nicht linear. OPSX tut so, als wäre sie es nicht.
Architektur im Detail
Dieser Abschnitt erklärt, wie OPSX intern funktioniert und wie es sich mit dem Legacy-Workflow vergleicht. Die Beispiele in diesem Abschnitt verwenden die erweiterte Befehlsmenge (new, continue usw.); Standardbenutzer von core können denselben Ablauf auf propose → apply → sync → archive abbilden.
Philosophie: Phasen vs. Aktionen
┌─────────────────────────────────────────────────────────────────────────────┐
│ LEGACY WORKFLOW │
│ (Phasen-Gebunden, Alles-Oder-Nichts) │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ PLANNING │ ───► │ IMPLEMENTING │ ───► │ ARCHIVING │ │
│ │ PHASE │ │ PHASE │ │ PHASE │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ /openspec:proposal /openspec:apply /openspec:archive │
│ │
│ • Erstellt ALLE Artefakte auf einmal │
│ • Kann während der Implementierung nicht zurückkehren, um Spezifikationen│
│ zu aktualisieren │
│ • Phasengates erzwingen einen linearen Fortschritt │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────────────┐
│ OPSX WORKFLOW │
│ (Flüssige Aktionen, Iterativ) │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌────────────────────────────────────────────┐ │
│ │ ACTIONS (keine Phasen) │ │
│ │ │ │
│ │ new ◄──► continue ◄──► apply ◄──► archive │ │
│ │ │ │ │ │ │ │
│ │ └──────────┴───────────┴───────────┘ │ │
│ │ beliebige Reihenfolge │ │
│ └────────────────────────────────────────────┘ │
│ │
│ • Artefakte einzeln erstellen oder vorspulen │
│ • Spezifikationen/Design/Aufgaben während der Implementierung aktualisieren│
│ • Abhängigkeiten ermöglichen Fortschritt, Phasen existieren nicht │
│ │
└─────────────────────────────────────────────────────────────────────────────┘Komponentenarchitektur
Der Legacy-Workflow verwendet fest codierte Vorlagen in TypeScript:
┌─────────────────────────────────────────────────────────────────────────────┐
│ LEGACY WORKFLOW KOMPONENTEN │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ Fest codierte Vorlagen (TypeScript-Zeichenketten) │
│ │ │
│ ▼ │
│ Toolspezifische Konfiguratoren/Adapter │
│ │ │
│ ▼ │
│ Generierte Befehlsdateien (.claude/commands/openspec/*.md) │
│ │
│ • Feste Struktur, kein Artefaktbewusstsein │
│ • Änderungen erfordern Codeanpassung + Neukompilierung │
│ │
└─────────────────────────────────────────────────────────────────────────────┘OPSX verwendet externe Schemata und eine Abhängigkeitsgraph-Engine:
┌─────────────────────────────────────────────────────────────────────────────┐
│ OPSX KOMPONENTEN │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ Schema-Definitionen (YAML) │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ name: spec-driven │ │
│ │ artifacts: │ │
│ │ - id: proposal │ │
│ │ generates: proposal.md │ │
│ │ requires: [] ◄── Abhängigkeiten │ │
│ │ - id: specs │ │
│ │ generates: specs/**/*.md ◄── Glob-Muster │ │
│ │ requires: [proposal] ◄── Aktiviert nach Proposal │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ Artefakt-Graph-Engine │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ • Topologische Sortierung (Abhängigkeitsreihenfolge) │ │
│ │ • Statuserkennung (Dateisystemvorhandensein) │ │
│ │ • Umfangreiche Anweisungsgenerierung (Vorlagen + Kontext) │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ Skill-Dateien (.claude/skills/openspec-*/SKILL.md) │
│ │
│ • Editorübergreifend kompatibel (Claude Code, Cursor, Devin) │
│ • Skills fragen CLI für strukturierte Daten ab │
│ • Vollständig anpassbar über Schema-Dateien │
│ │
└─────────────────────────────────────────────────────────────────────────────┘Abhängigkeitsgraph-Modell
Artefakte bilden einen gerichteten azyklischen Graphen (DAG). Abhängigkeiten sind Aktivierer, keine Tore:
proposal
(Wurzelknoten)
│
┌─────────────┴─────────────┐
│ │
▼ ▼
specs design
(erfordert: (erfordert:
proposal) proposal)
│ │
└─────────────┬─────────────┘
│
▼
tasks
(erfordert:
specs, design)
│
▼
┌──────────────┐
│ APPLY PHASE │
│ (erfordert: │
│ tasks) │
└──────────────┘Statusübergänge:
BLOCKIERT ──────────────► BEREIT ──────────────► ERLEDIGT
│ │ │
Fehlende Alle Abh. Datei vorhanden
Abhängigkeiten sind ERLEDIGT im DateisystemInformationsfluss
Legacy-Workflow — Agent erhält statische Anweisungen:
Benutzer: "/openspec:proposal"
│
▼
┌─────────────────────────────────────────┐
│ Statische Anweisungen: │
│ • Erstelle proposal.md │
│ • Erstelle tasks.md │
│ • Erstelle design.md │
│ • Erstelle Delta-Spezifikationsdateien │
│ │
│ Kein Bewusstsein dafür, was existiert │
│ oder Abhängigkeiten zwischen Artefakten│
└─────────────────────────────────────────┘
│
▼
Agent erstellt ALLE Artefakte auf einmalOPSX — Agent fragt nach reichhaltigem Kontext:
Benutzer: "/opsx:continue"
│
▼
┌──────────────────────────────────────────────────────────────────────────┐
│ Schritt 1: Aktuellen Status abfragen │
│ ┌────────────────────────────────────────────────────────────────────┐ │
│ │ $ openspec status --change "add-auth" --json │ │
│ │ │ │
│ │ { │ │
│ │ "artifacts": [ │ │
│ │ {"id": "proposal", "status": "done"}, │ │
│ │ {"id": "specs", "status": "ready"}, ◄── Erstes bereit │ │
│ │ {"id": "design", "status": "ready"}, │ │
│ │ {"id": "tasks", "status": "blocked", │ │
│ │ "missingDeps": ["specs", "design"]} │ │
│ │ ] │ │
│ │ } │ │
│ └────────────────────────────────────────────────────────────────────┘ │
│ │
│ Schritt 2: Reichhaltige Anweisungen für bereites Artefakt erhalten │
│ ┌────────────────────────────────────────────────────────────────────┐ │
│ │ $ openspec instructions specs --change "add-auth" --json │ │
│ │ │ │
│ │ { │ │
│ │ "template": "# Spezifikation\n\n## NEUE Anforderungen...", │ │
│ │ "dependencies": [{"id": "proposal", "path": "...", "done": true}│ │
│ │ "unlocks": ["tasks"] │ │
│ │ } │ │
│ └────────────────────────────────────────────────────────────────────┘ │
│ │
│ Schritt 3: Abhängigkeiten lesen → EIN Artefakt erstellen → Zeigen, was │
│ freigeschaltet wurde │
└──────────────────────────────────────────────────────────────────────────┘Iterationsmodell
Legacy-Workflow — mühsam zu iterieren:
┌─────────┐ ┌─────────┐ ┌─────────┐
│/proposal│ ──► │ /apply │ ──► │/archive │
└─────────┘ └─────────┘ └─────────┘
│ │
│ ├── "Moment, das Design ist falsch"
│ │
│ ├── Optionen:
│ │ • Dateien manuell bearbeiten (unterbricht Kontext)
│ │ • Aufgeben und von vorne beginnen
│ │ • Durchziehen und später korrigieren
│ │
│ └── Kein offizielles "Zurück"-Mechanismus
│
└── Erstellt ALLE Artefakte auf einmalOPSX — natürliche Iteration:
/opsx:new ───► /opsx:continue ───► /opsx:apply ───► /opsx:archive
│ │ │
│ │ ├── "Das Design ist falsch"
│ │ │
│ │ ▼
│ │ Einfach design.md bearbeiten
│ │ und weitermachen!
│ │ │
│ │ ▼
│ │ /opsx:apply nimmt dort auf,
│ │ wo du aufgehört hast
│ │
│ └── Erstellt EIN Artefakt, zeigt was freigeschaltet wird
│
└── Gerüstet Änderung, wartet auf RichtungEigene Schemata
Erstellen Sie eigene Workflows mit den Schema-Verwaltungsbefehlen:
# Neues Schema von Grund auf erstellen (interaktiv)
openspec schema init my-workflow
# Oder ein bestehendes Schema als Ausgangspunkt forken
openspec schema fork spec-driven my-workflow
# Schema-Struktur validieren
openspec schema validate my-workflow
# Prüfen, woher ein Schema aufgelöst wird (hilfreich beim Debuggen)
openspec schema which my-workflowSchemata werden in openspec/schemas/ (projektlokal, versioniert) oder ~/.local/share/openspec/schemas/ (benutzerglobal) gespeichert.
Schema-Struktur:
openspec/schemas/research-first/
├── schema.yaml
└── templates/
├── research.md
├── proposal.md
└── tasks.mdBeispiel schema.yaml:
name: research-first
artifacts:
- id: research # Vor Proposal hinzugefügt
generates: research.md
requires: []
- id: proposal
generates: proposal.md
requires: [research] # Hängt jetzt von research ab
- id: tasks
generates: tasks.md
requires: [proposal]Abhängigkeitsgraph:
research ──► proposal ──► tasksZusammenfassung
| Aspekt | Legacy | OPSX |
|---|---|---|
| Vorlagen | Fest codiertes TypeScript | Externes YAML + Markdown |
| Abhängigkeiten | Keine (alles auf einmal) | DAG mit topologischer Sortierung |
| Status | Phasenbasiertes Denkmodell | Dateisystemvorhandensein |
| Anpassung | Quellcode bearbeiten, neu kompilieren | schema.yaml erstellen |
| Iteration | Phasen-gebunden | Flüssig, alles bearbeitbar |
| Editor-Unterstützung | Toolspezifische Konfiguratoren/Adapter | Ein einzelner Skills-Ordner |
Schemata
Schemata definieren, welche Artefakte existieren und ihre Abhängigkeiten. Derzeit verfügbar:
- spec-driven (Standard): proposal → specs → design → tasks
# List available schemas
openspec schemas
# See all schemas with their resolution sources
openspec schema which --all
# Create a new schema interactively
openspec schema init my-workflow
# Fork an existing schema for customization
openspec schema fork spec-driven my-workflow
# Validate schema structure before use
openspec schema validate my-workflowTipps
- Nutze
/opsx:explore, um eine Idee durchzudenken, bevor du eine Änderung vornimmst /opsx:ff, wenn du weißt, was du willst,/opsx:continuebeim Erkunden- Während
/opsx:apply, wenn etwas falsch ist – korrigiere das Artefakt und fahre dann fort - Aufgaben verfolgen den Fortschritt über Kontrollkästchen in
tasks.md - Status jederzeit prüfen:
openspec status --change "name"
Feedback
Das ist grob. Das ist beabsichtigt – wir lernen, was funktioniert.
Einen Fehler gefunden? Hast du Ideen? Tritt uns auf Discord bei oder eröffne ein Issue auf GitHub.