OpenSpec: die leichtgewichtige Spec-Schicht, die eine Einigung erzwingt, bevor Code geschrieben wird

OpenSpec ist eine leichtgewichtige Spezifikationsschicht, die Entwickler und ihren Code-Assistenten dazu zwingt, schriftlich zu vereinbaren, was gebaut werden soll, bevor auch nur eine Zeile Code geschrieben wird. Sie ist die wichtigste „leichtgewichtige” Alternative zum spec-driven-Ansatz innerhalb eines Werkzeug-Ökosystems, das ab 2025 rasch wuchs.

Klarstellung zur Begriffsverwirrung: Das Repository heißt auf GitHub OpenSpec (großgeschrieben); die Warteschlangenzeile verwendet openspec. Es gibt mindestens ein nicht verwandtes Projekt mit demselben Namen (ein OpenAPI/Swagger-Explorer unter openspec.vercel.app), aber das hier dokumentierte Repository ist Fission-AI/OpenSpec.

Was OpenSpec ist

OpenSpec ist ein Framework für spezifikationsgetriebene Entwicklung (SDD) für KI-Codierungsassistenten. Es ist kein Modell, keine IDE und kein Server: Es ist ein Node.js-CLI, das Markdown-Dateien innerhalb des Projekts selbst generiert, plus einen Satz von Skills und Slash-Befehlen (/opsx:*), die der KI-Assistent im Chat ausführt.

Sein Zweck ist es, die Einigung über Anforderungen aus dem Chat-Verlauf herauszunehmen. Wenn Anforderungen nur in einem Gespräch existieren, füllt der Assistent Lücken mit Annahmen, und der Fehler wird entdeckt, nachdem der Code bereits existiert. OpenSpec führt einen verifizierbaren Vertrag ein: Jede Änderung wird in einem Ordner mit Vorschlag, Delta-Spezifikationen, Design und Aufgabenliste geplant; der Mensch überprüft den Plan, bevor irgendetwas implementiert wird, und beim Archivieren der Änderung werden die Spezifikationen zur Beschreibung des aktuellen Systemverhaltens.

Das README selbst fasst die Philosophie in fünf Zeilen zusammen: fließend, nicht starr; iterativ, nicht Wasserfall; einfach, nicht komplex; gebaut für Brownfield, nicht nur für neue Projekte; und skalierbar von persönlichen Projekten bis zu Unternehmen.

Der Ursprung

Das Repository wurde am 5. August 2025 von der Organisation Fission-AI auf GitHub erstellt. Die in MAINTAINERS.md erklärten Maintainer sind Tabish Bidiwale (TabishB), Hauptmaintainer, und Clay Good (clay-good), Maintainer, mit Hari Krishnan (harikrishnan83) als technischem Berater. Die offizielle Website, openspec.dev, trägt die Marke „© 2026 Fission”, was darauf hindeutet, dass das Projekt vom Unternehmen Fission unterstützt wird.

Die erzählerische Farbe, die die konsultierten Quellen bieten, ist bescheiden: Es gibt keinen viralen Launch-Post mit Anekdote, anders als bei anderen Werkzeugen derselben Nische. Die dokumentierte Entwicklung ist die eines Projekts, das stetig reifte: Es begann experimentell im August 2025, wurde stabil mit v1.0.0 am 26. Januar 2026 (ein vollständiges Redesign des Ablaufs um ein artefaktbasiertes Aktionssystem, mit Breaking Changes), und hat seitdem fast wöchentliche Versionen veröffentlicht. Der Hauptautor des Projekts, Tabish Bidiwale, veröffentlichte ein Launch-Video und pflegt das Profil @0xTab auf X, das das README für Neuigkeiten verlinkt.

Philosophie und Prinzipien

Das README und die Dokumentation erklären folgende Prinzipien, verifizierbar im eigenen Code des Ablaufs: vereinbaren vor dem Bauen (der Assistent und der Mensch richten sich an den Spezifikationen aus, bevor Code geschrieben wird; der Fehler ist billig im Plan, teuer in der Implementierung); fließend, keine starren Phasen (jedes Artefakt — Vorschlag, Specs, Design, Aufgaben — kann jederzeit bearbeitet werden; es gibt keine Phasentore, die den Fortschritt blockieren); einfaches Markdown, keine spezielle Syntax (Spezifikationen sind Anforderungen mit SHALL/MUST-plus-GIVEN/WHEN/THEN-Szenarien, menschenlesbar und CLI-verifizierbar); und Werkzeugneutralität (funktioniert mit über 30 KI-Assistenten, indem das Skill- oder Befehlsformat installiert wird, das jeder verwendet, statt eine einzelne Umgebung zu erzwingen).

Brownfield-first: Die vollständige Anwendung wird nicht im Voraus dokumentiert; eine Spezifikation wird nur für das geschrieben, was jede Änderung berührt, und die Specs wachsen mit der tatsächlichen Arbeit.

Ein zentrales Konzept ist die Delta-Spezifikation: Jede Änderung deklariert nur das, was sie modifiziert (ADDED-, MODIFIED-, REMOVED-Abschnitte), statt die gesamte Spec neu zu schreiben, und beim Archivieren werden diese Deltas in die Hauptspezifikation zusammengeführt. Die archivierte Änderung verbleibt in openspec/changes/archive/ als auditierbare Historie.

Wie es funktioniert

Der dokumentierte Basisablauf (Profil core, standardmäßig):

/opsx:explore ──► /opsx:propose ──► /opsx:apply ──► /opsx:sync ──► /opsx:archive
   (optional)

/opsx:explore (optional): ein unverbindlicher „Denkbegleiter”, der die Codebasis liest, Optionen abwägt, und eine unklare Idee in einen konkreten Plan verwandelt, ohne bereits ein Artefakt zu erstellen.
/opsx:propose <name>: erstellt openspec/changes/<name>/ mit proposal.md (das Warum und der Umfang), specs/ (Deltas mit Anforderungen und Szenarien), design.md (das technische Wie) und tasks.md (Implementierungs-Checkliste). Der Mensch überprüft den Plan.
/opsx:apply: der Agent implementiert die Aufgaben; wenn das Design Anpassungen braucht, werden die Artefakte bearbeitet und die Arbeit fortgesetzt.
/opsx:sync (optional): fusioniert die Deltas in die Hauptspezifikationen vor dem Archivieren, nützlich bei langen Änderungen.
/opsx:archive: wendet die Deltas auf die Hauptspezifikation an und verschiebt die Änderung nach changes/archive/JJJJ-MM-TT-<name>/.

Es gibt ein erweitertes Profil (new, continue, ff, verify, bulk-archive, onboard), das mit openspec config profile aktiviert wird. Das Terminal-CLI ergänzt den Chat mit openspec list, openspec show <change> [--diff], openspec validate [--report findings], openspec status --all, openspec view (interaktives Panel) und openspec feedback.

Außerdem bietet OpenSpec seit der Beta Stores: ein eigenständiges Repository, das ausschließlich der Planung gewidmet ist, mit derselben openspec/-Form (Specs und Changes), die per git push wie jedes andere Repo geteilt wird. Es löst den Fall, in dem eine Funktion drei Repositorys berührt, oder in dem ein Plattform-Team die Anforderungen besitzt und Produktteams sie schreibgeschützt konsumieren. openspec store setup <name> und openspec new change <id> --store <name> sind die Startbefehle.

Das Ökosystem

Repositorys der Organisation Fission-AI

Fission-AI/OpenSpec: das Hauptprojekt (dieser Bericht). Fission-AI/PR-QUEST: eine interaktivere Möglichkeit, Änderungsanfragen zu überprüfen; 25 Sterne (16. Oktober 2025).

Das zugehörige kommerzielle Produkt, dokumentiert im offiziellen Blog, ist der OpenSpec Cloud Agent (Early Access am 28. August 2026): eine immer aktive Schicht, die Pull Requests mit den Anforderungen verbundener Repositorys vergleicht, „Drift” zwischen Code und Specs erkennt, indem sie die exakte Zeile beider zitiert, und korrigierende PRs öffnen kann. Ein Update vom 11. September 2026 zeigt an, dass neue Anmeldungen für das Early-Access-Programm pausiert sind, während das Produkt mit teilnehmenden Teams evaluiert wird.

Community-Werkzeuge

UIs und Visualisierer (katalogisiert in speclib/awesome-openspec, 73 Sterne): ToruAI/openspec-ui (Echtzeit-Kanban, 31 Sterne), oioi555/openspec-webui (interaktive Web-UI, 14 Sterne), jixoai/openspecui (Web-UI mit Live-Modus und statischem Export, 113 Sterne), und andere wie fselich/dossier, MusicAdam/openspec-viewer, sflueckiger/specboard, dansreis/speclens, spekhq/spek.

Editor-/Agenten-Integrationen und Plugins: Lumiaqian/openspec-mcp (MCP-Server mit Kanban-Panel), johnnyblabs/intellij-openspec (IntelliJ-Plugin), Octane0411/opencode-plugin-openspec (160 Sterne, OpenCode-Plugin mit „Architect”-Modus), fastknifes/openflow (180 Sterne, kombiniert OpenSpec und Superpowers), und Erweiterungen für Copilot, VS Code/Cursor, Zed, Emacs, und Neovim.

Hybride Abläufe und Community-Schemas: JiangWay/openspec-schemas (222 Sterne, enthält superpowers-bridge), intent-driven-dev/openspec-schemas (94 Sterne), MageByte-Zero/spec-superflow (798 Sterne, Fusion mit Superpowers), rihebty/flow-kit (400 Sterne), SYZ-Coder/superpowers-openspec-team-skills (193 Sterne), sudokar/openspec-plus (190 Sterne), wenqingyu/ralphy-openspec (182 Sterne).

Reverse Engineering und Anleitungen: clay-good/OpenLore (304 Sterne, früher spec-gen, vom Maintainer Clay Good selbst, generiert Specs aus bestehendem Code), ForceInjection/OpenSpec-practise (614 Sterne), sohaha/studyzy-OpenSpec-cn (96 Sterne), und weitere Community-Anleitungen auf Chinesisch.

Offizieller/halboffizieller Status

OpenSpec ist keine Komponente eines Marktplatzes eines großen Anbieters: Es ist ein eigenständiges npm-Paket (@fission-ai/openspec) unter der MIT-Lizenz, gepflegt von Fission-AI. Es gibt drei verifizierbare Statussignale: stabil seit v1.0.0 (26. Januar 2026, mit dem Übergang „von experimentell zu stabil”); De-facto-Adoption in der SDD-Nische (Hacker-News-Threads zeigen OpenSpec neben Spec Kit, Superpowers, und Kiro in Diskussionen über spezifikationsgetriebene Entwicklung genannt); und ein zugehöriges kommerzielles Produkt (der OpenSpec Cloud Agent signalisiert eine Geschäftsabsicht über das OSS-Projekt hinaus).

In der Praxis funktioniert OpenSpec als die leichtgewichtige, werkzeugübergreifende Option des De-facto-Standards „Specs vor Code schreiben”, die direkt mit github/spec-kit (offiziell von GitHub) und Kiro (AWS) konkurriert, wie das README selbst vergleicht.

Schnellstart-Anleitung

Installation und erster Start

Voraussetzung: Node.js 20.19.0 oder neuer.

npm install -g @fission-ai/openspec@latest   # auch pnpm add -g / bun add -g / yarn global add
openspec --version                            # überprüfen
cd dein-projekt
openspec init                                 # interaktiv: wähle die KI-Werkzeuge, die du nutzt

Nicht-interaktive Optionen: openspec init --tools claude,cursor, --tools all, --tools none, --profile core. Mit Nix: nix run github:Fission-AI/OpenSpec -- init.

Beim Abschluss erstellt openspec init die Struktur openspec/ (mit specs/, changes/ und config.yaml), schreibt die Skills und Befehle für jedes gewählte Werkzeug, und druckt eine „Getting started”-Zeile mit der exakten Schreibweise des Befehls für Ihr Werkzeug. Was beim ersten Start zu erwarten ist: zwei Terminalschritte, und dann geschieht alles im Chat des Assistenten. Es gibt keinen separaten „interaktiven Modus”; der Slash-Befehl ist der Einstiegspunkt zu OpenSpec.

Gängige Workflows

Um eine bereits klare Funktion vorzuschlagen: im Chat des Assistenten /opsx:propose add-dark-mode ausführen; openspec/changes/add-dark-mode/ wird mit proposal.md, specs/, design.md und tasks.md erstellt. Den Plan vor dem Fortfahren überprüfen.
Um eine unklare Idee zu durchdenken, bevor man sich festlegt: /opsx:explore ausführen, das Problem erklären, und der Agent erkundet den Code, stellt Fragen, und schlägt einen Umfang vor; danach an /opsx:propose übergeben.
Um zu implementieren: /opsx:apply ausführen; der Agent arbeitet die Checkliste ab und hakt jede Aufgabe ab. Bei Kontextverlust eine neue Sitzung öffnen und /opsx:apply erneut ausführen: liest die Artefakte und setzt bei der ersten nicht abgehakten Aufgabe fort.
Um vom Terminal aus zu überprüfen und zu validieren: openspec list (aktive Änderungen), openspec show <change> --diff (nur die geänderten Zeilen), openspec validate <change> (validiert das Spec-Format). Am Ende fusioniert /opsx:archive die Deltas in openspec/specs/ und archiviert die Änderung.

Wesentliche Konfiguration

openspec/config.yaml: der Schlüssel context: injiziert Text in jede Planungsanfrage; hier deklariert man den eigenen Tech-Stack und die Konventionen.
Befehlsprofil (openspec config profile): core (standardmäßig) oder das erweiterte Profil (fügt new, continue, ff, verify, bulk-archive, onboard hinzu).
Sprache der Artefakte: openspec init --language <language> generiert die Specs in einer anderen Sprache (die Überschriften und die Wörter SHALL/MUST bleiben auf Englisch).
Telemetrie: standardmäßig aktiviert (nur Befehlsnamen und Version; in CI automatisch deaktiviert). Opt-out: openspec config set telemetry.enabled false.
Stores (Beta): openspec store setup <name> für Multi-Repo-Planung.

Häufige Fallstricke und Lösungen

/opsx:propose im Terminal eingeben: der am häufigsten dokumentierte Fehler. openspec ...-Befehle laufen im Terminal; /opsx:...-Befehle werden im Chat des Assistenten eingegeben.
Die Syntax stimmt nicht mit Ihrem Werkzeug überein: /opsx:propose ist /opsx-propose in Cursor und GitHub Copilot, @opsx-propose in Amazon Q, $openspec-propose in Codex, und /skill:openspec-propose in Kimi Code. Immer die von openspec init gedruckte Form verwenden.
Befehl erscheint nicht: normalerweise sind die Dateien nicht installiert. openspec update aktualisiert nur bestehende Dateien; wenn openspec init nie ausgeführt wurde, ausführen und den Assistenten neu starten.
Alte Version im PATH: nach dem Aktualisieren des Pakets, wenn openspec --version eine ältere Version zeigt, maskiert eine frühere Kopie die neue im PATH.
Code von Hand bearbeiten und die Spec desynchronisieren: das Archivieren macht Ihre Specs zum Register der Wahrheit; vor dem Archivieren abgleichen. /opsx:verify und openspec show --diff helfen, Diskrepanzen zu erkennen.
Yarn 2+ hat kein global: stattdessen mit npm, pnpm, oder bun installieren.

Integrationen und Migration

Der Ordner openspec/ sollte als Quellcode committet werden. Für CI: openspec validate --archived prüft, dass alle archivierten Änderungen alle Aufgaben in tasks.md abgehakt haben; openspec validate --report findings gibt einen reinen Befundbericht für Pipelines aus. openspec init --copilot-cloud generiert Dateien, damit der Code-Agent von GitHub das CLI nutzen kann. Der Community-Server Lumiaqian/openspec-mcp exponiert das CLI als MCP-Werkzeuge. Zur Migration von Versionen vor 1.0 wurden die alten Befehle entfernt; openspec init ausführen, um zu aktualisieren — aktive Änderungen, archivierte, und Specs bleiben erhalten.

Aktuelle Kennzahlen

Messung: 14. September 2026, GitHub-API und npm-Register.

Kennzahl	Wert
Sterne	68.216
Forks	4.689
Offene Issues laut API	283
Commits (Branch `main`, ungefähr)	≈843
Hauptsprache	TypeScript
Lizenz	MIT
Erstellt	5. August 2025
Letzter Push	14. September 2026
Neuestes Release	`v1.13.0`, 9. September 2026
npm-Downloads (Woche)	378.332
npm-Downloads (Monat)	1.768.196

Top-Contributors, nach Beiträgen: TabishB (518), clay-good (125), openspec-release-bot[bot] (23), github-actions[bot] (20) und dependabot[bot] (16). Vorbehalte: open_issues_count kann offene Pull Requests einschließen; die Commit-Zahl ist ungefähr; und watchers_count aus der Repository-Antwort spiegelt das Sterne-Feld wider, weshalb sie nicht separat gemeldet wird.

Community-Resonanz

Die gesammelten Belege zeigen anhaltende Begeisterung, aber auch konkrete, wiederholte Einwände.

Im Thread 47419539 („Get Shit Done”, 17. März 2026) schrieb recroad: „I use openspec and love it. I’m doing 5-7x with close to 100% of code AI generated, and shipping to production multiple times a day. I work on a large sass app with hundreds of customers.” gbrindisi fügte hinzu: „I like openspec, it lets you tune the workflow to your liking and doesn’t get in the way.” In 46692578 („Ask HN: Do you have any evidence that agentic coding works?”, 20. Januar 2026) zitierte recroad OpenSpec erneut: „Works pretty great for me… Easily 5x speed minimum.” In 48774782 („Superpowers 6”, 3. Juli 2026) schrieb wejick: „SDD with openspec hit the right balance for me.”

Die artikuliertste Kritik erscheint im großen Thread 47994012 („Specsmaxxing”, 287 Punkte und 295 Kommentare, 3. Mai 2026). jochem9, der es „seit ein paar Monaten” nutzte, warnte, dass „wenn sich eine Spec ändert, die KI den relevanten Code finden muss, um ihn zu ändern… in einer großen Codebasis ist es sehr leicht, etwas zu übersehen”. alasano war härter: „Ich genieße das Format von OpenSpec, aber ich glaube nicht, dass es sich lohnt, die Haupt-Specs zu pflegen. Ich habe komplett damit aufgehört… Wenn man den Sync-Prozess durchführt, driftet es weiter, bis man Duplikation und Widersprüche zwischen Specs hat.” gnatolf, in 47019109 („Breaking the spell of vibe coding”, 14. Februar 2026), formulierte den Skalierungseinwand: „Sobald das Projekt auf eine relevante Komplexitätsgröße wächst, ist die Pflege der Specs genauso schwierig wie das Problem, das sie löst.”

Der Entwickler Dan Clarke veröffentlichte am 8. Mai 2026 eine Rezension nach einem Monat Nutzung: Er wählte es, weil ihm Spec Kit „etwas schwerfällig” vorkam, hebt den Explore-Modus als Schlüsselfunktion hervor, merkt aber an, dass es in seiner Erfahrung „nicht wirklich spec-driven ist… Specs sind ein Artefakt des Ablaufs, nicht der Ausgangspunkt”.

Vergleich mit ähnlichen Projekten

Vorschlag	Verifizierbare Überschneidung	Verifizierbarer Unterschied
`github/spec-kit` (136.644 Sterne, Python)	Offizielles GitHub-Kit für SDD mit CLI, Vorlagen, und Integrationen.	Das README von OpenSpec beschreibt es als „umfassend, aber schwer: starre Phasentore, viel Markdown, Python-Konfiguration”.
Kiro (AWS)	AWS’ agentische IDE, die natürliche Sprache in strukturierte Specs verwandelt.	Das README: „mächtig, aber man ist an ihre IDE gebunden und auf Claude-Modelle beschränkt”; OpenSpec funktioniert mit den 30+ bestehenden Werkzeugen.
`obra/superpowers`	Prozessdisziplin für Code-Agenten, mit komponierbaren Skills.	Superpowers erzwingt die Ausführungsmethodik (TDD, Review, Worktrees); OpenSpec regelt die vorherige Einigung über Anforderungen. Die Community kombiniert beide über Schemas.
`bmad-code-org/BMAD-METHOD`	KI-gesteuerte agile Methodik, die formale Specs als einzige Quelle der Wahrheit nutzt.	Team-Ansatz mit Rollen und formalen Artefakten; OpenSpec ist leichter und über Schemas anpassbarer.

Der nützlichste Vergleich erfolgt nicht nach Popularität: Spec Kit ist das Projekt mit den meisten Sternen in der Nische (136k gegenüber 68k von OpenSpec), aber das README und die Community-Kommentare positionieren OpenSpec als die Option, wenn man Leichtigkeit, Iterationsfreiheit, und Portabilität zwischen Assistenten will, statt eines vorschreibenden Kits.

Wie man beiträgt

CONTRIBUTING.md dokumentiert einen vierstufigen Prozess, bemerkenswert dafür, den eigenen Ablauf des Projekts auf sich selbst anzuwenden: zuerst eine Diskussion oder ein Issue eröffnen (jede Änderung beginnt dort; „PRs ohne verlinktes Issue oder vorherige Diskussion können geschlossen werden”); entscheiden, ob ein Änderungsvorschlag nötig ist (ein Fix geht direkt zum PR; neue Funktionalität erfordert zuerst einen genehmigten OpenSpec-Vorschlag); die Änderung vornehmen (Node 20.19+ und pnpm; pnpm install, pnpm build, pnpm test, pnpm exec tsc --noEmit, pnpm lint); und den PR öffnen (Titel im Stil eines Conventional Commit, das Issue verlinken, und falls ein Code-Agent den Code geschrieben hat, welchen angeben).

Anwendungsfälle

Einzelentwickler, die mit Claude Code, Codex, Cursor, Gemini CLI oder einem der 30+ anderen Assistenten arbeiten, können den Ablauf „vager Prompt → unerwarteter Code” durch explore → propose → apply → archive ersetzen.
Multi-Repo-Teams (Plattform + Produkt) können Stores (Beta) nutzen, damit ein Team die Anforderungen in einem gemeinsamen Planungs-Repository besitzt, was das desynchronisierte Wiki eliminiert.
Teams, die eine Spec↔Code-Drift befürchten, können openspec validate --archived und --report findings als Pre-Commit-/CI-Hooks aktivieren und den Cloud Agent für Drift-Erkennung in PRs evaluieren.
Große Brownfield-Projekte profitieren vom Brownfield-first-Design, mit clay-good/OpenLore, um erste Specs aus bestehendem Code zu generieren.
Teams, die bereits Superpowers oder ein anderes Disziplin-Framework nutzen, können beide über Community-Schemas kombinieren (superpowers-bridge, spec-superflow, openflow), wobei die Artefakt-Governance von OpenSpec und die disziplinierte Ausführung des anderen erhalten bleiben.
Teams, die Portabilität wünschen, finden Wert in der Werkzeugneutralität: derselbe Spec-Ablauf funktioniert über 30+ Assistenten hinweg.

Ressourcen

Repository: https://github.com/Fission-AI/OpenSpec
Dokumentation: https://github.com/Fission-AI/OpenSpec/blob/main/docs/README.md · Website: https://openspec.dev/
Rezensionen: https://www.danclarke.com/openspec/ (Dan Clarke, 8. Mai 2026)
Community / Discord: https://discord.gg/YctCnvvshC
Video-Tutorials: Launch-Video von Tabish Bidiwale https://youtu.be/N-MftbmnmMo
Relevante HN-Threads: https://news.ycombinator.com/item?id=47994012 (Specsmaxxing) · https://news.ycombinator.com/item?id=48221805
Paketregister: npm https://www.npmjs.com/package/@fission-ai/openspec
Offizieller Blog: https://openspec.dev/blog · Releases: https://github.com/Fission-AI/OpenSpec/releases
Kuratierte Community-Liste: https://github.com/speclib/awesome-openspec

Hinweis: Dieser Artikel kombiniert das README und die offizielle Dokumentation (docs/), MAINTAINERS.md und CONTRIBUTING.md, die Versionshinweise, den offiziellen Blog von openspec.dev, die GitHub-API, das npm-Register, die Liste speclib/awesome-openspec und Hacker-News-Threads, konsultiert am 14. September 2026. Zahlen ändern sich mit der Zeit.