OpenSpec ist ein Open Source Framework für Spec Driven Development mit KI Coding Agents. Bevor Code entsteht, einigen sich Entwickler und KI auf eine kurze Spezifikation mit Proposal, Design, Aufgabenliste und Spec Deltas. Diese Dateien liegen als Markdown direkt im Repository und bleiben die gemeinsame Quelle der Wahrheit.
Entwickelt wird OpenSpec von Fission AI unter MIT Lizenz. Das Projekt braucht weder API Key noch MCP Server und arbeitet mit über 30 KI Tools zusammen, darunter OpenCode, Claude Code, Codex, Cursor, Zed und Kimi Code. Auf GitHub steht es bei rund 67.000 Stars. Seit dem Sommer 2026 erscheinen fast wöchentlich neue Releases, Ende September kam die Linie 1.13.
Der Kern ist einfach: Ein Chat Prompt verschwindet irgendwann aus dem Kontext, eine Spec bleibt im Repository. Wer mit KI Agenten in bestehenden Projekten arbeitet, bekommt so pro Änderung einen prüfbaren Plan, den Mensch und Agent vor der Umsetzung gemeinsam lesen.
Ein Tag inhouse mit Benjamin Klein für Developer, Tester und Admins. Context Engineering, Harness, ADRs und zwei Hands on Blöcke mit KI Agenten in eurem Setup.
Spec Driven Development gehört bei Never Code Alone zur täglichen Arbeit mit OpenCode. Wir schreiben Change Proposals und Specs mit OpenSpec, bewusst auf Englisch, damit Agents und Validierung sauber zusammenspielen. Dazu kommen Quality Gates mit statischer Analyse, Unit Tests und Cypress E2E Tests, damit der Plan am Ende auch geprüft wird. Roland Golla arbeitet seit über 20 Jahren an Softwarequalität und ist Cypress Ambassador.
Passend dazu gibt es die Vibe Coding Beratung für Teams, das NCA Agentic AI Coding Guardrails Setup für bestehende Projekte und den NCA KI Workshop für Developer. Zur Einordnung helfen unsere Artikel zur Dokumentenkette ADR, PRD und BDD und zu Kiro als Spec Driven IDE.
OpenSpec hat seit dem Frühjahr 2026 ein hohes Tempo. Die wichtigsten Neuerungen in der Reihenfolge ihres Erscheinens:
Wer OpenSpec schon im Einsatz hat, aktualisiert mit openspec update und lässt danach einmal openspec validate --all laufen. So siehst du sofort, ob bestehende Specs mit den strengeren Prüfungen kollidieren.
Wer regelmäßig mit KI Coding Agents arbeitet, kennt das Muster: Die erste Implementierung sieht gut aus, bei Änderungen entstehen Inkonsistenzen. Die KI vergisst frühere Entscheidungen, interpretiert Anforderungen anders oder schreibt Code, der nicht zum bestehenden System passt.
Die Ursache ist fehlender Kontext. Chat Prompts verschwinden aus dem Kontextfenster, sobald die Session länger wird. Ohne feste Referenz kann die KI nicht prüfen, ob ihre Umsetzung den ursprünglichen Anforderungen entspricht. Mehr dazu beim Context Window Management.
OpenSpec setzt genau hier an: mit einer versionierten Spezifikation im Repository, die für jede KI Interaktion die verbindliche Referenz bleibt. Den Ansatz dahinter, seine Stufen und die anderen Frameworks erklärt unsere Seite zu Spec Driven Development.
OpenSpec besteht aus zwei Hälften: einer CLI im Terminal und Slash Commands im KI Agent. Der Ablauf hat drei Stationen.
Propose: Mit /opsx:propose entsteht für jede Änderung ein eigener Ordner mit proposal.md, design.md, tasks.md und den Spec Deltas. Mensch und Agent lesen denselben Plan, bevor Code entsteht. Mit /opsx:explore lässt sich vorher offen recherchieren, ohne dass der Agent ungefragt Dateien schreibt.
Apply: Der Agent arbeitet die Aufgabenliste ab und hakt erledigte Schritte ab. Jede Aufgabe muss sagen, woran man erkennt, dass sie fertig ist, etwa an einem Test oder einem Befehl.
Archive: Nach der Umsetzung fließen die Deltas in die Hauptspezifikation, der Change wandert ins Archiv. Mit /opsx:update passt du einen Plan unterwegs an, ohne neu anzufangen.
Das Kernkonzept von OpenSpec sind Delta Specs, also Differenz Spezifikationen, die zeigen, was sich ändert. Statt die gesamte Spezifikation zu überschreiben, markieren sie ausdrücklich:
Das macht Code Reviews einfacher und verhindert versehentliche Regressionen. Seit Version 1.11 zeigt openspec show mit --diff nur die Zeilen, die sich wirklich ändern. Und openspec validate meldet, wenn ein MODIFIED Block ein bestehendes Szenario verlieren würde.
# Delta for Auth
## ADDED Requirements
### Requirement: Two-Factor Authentication
The system MUST require a second factor during login.
## MODIFIED Requirements
### Requirement: Session Timeout
The system SHALL expire sessions after 30 minutes.
## REMOVED Requirements
### Requirement: Remember Me
(Deprecated in favor of 2FA)
Ein wesentlicher Unterschied zu anderen SDD Frameworks: OpenSpec ist brownfield first gebaut. Es funktioniert vor allem in bestehenden Codebasen, dort, wo die meiste Arbeit tatsächlich stattfindet. Die Spezifikation kann den Ist Zustand Schritt für Schritt erfassen, eine komplette Neudokumentation braucht es nicht.
Bei gewachsenem Legacy Code gilt trotzdem unsere Reihenfolge: erst Quality Gates mit statischer Analyse, Unit Tests, funktionalen Tests und Cypress E2E, dann Änderungen. Oft ist der bessere Weg aus dem Legacy ein paralleles neues Projekt, für das OpenSpec die Anforderungen sauber festhält. Mehr dazu bei AI Code Refactoring.
OpenSpec ist eine Node.js CLI und wird global über npm installiert. Bei openspec init erkennt das Tool vorhandene Agent Verzeichnisse und schlägt passende Integrationen vor. Für OpenCode, Claude Code, Codex und viele weitere Tools legt es Skills und Slash Commands an.
# Installation
npm install -g @fission-ai/openspec@latest
# Projekt initialisieren und Tools auswaehlen
cd your-project
openspec init
# Gezielt fuer OpenCode einrichten
openspec init --tools opencode
# Changes ansehen
openspec list
openspec show add-dark-mode --diff
# Alles pruefen
openspec validate --all
# Auf neue Version aktualisieren
openspec update
Für die Planung lohnen sich starke Reasoning Modelle, für die Umsetzung reicht oft eine schnellere Variante. In OpenCode wechselst du dafür einfach die Modellvariante. Die anonyme Telemetrie von OpenSpec lässt sich über telemetry.enabled: false in der Konfiguration abschalten.
Im Bereich Spec Driven Development gibt es mehrere Ansätze:
Die Wahl hängt vom Kontext ab. Für GitHub zentrierte Enterprise Teams liegt Spec Kit nahe. Wer freie Tool Wahl und geringen Overhead will, ist mit OpenSpec gut aufgehoben. Wie sich Specs zu Skills und PRDs verhalten, steht in Skill vs PRD.
… agree on what to build before any code is written.
OpenCode im Praxistest: Open Source Coding Agent mit über 200.000 GitHub Stars, v1.18 und v2, Sicherheitsupdate, 75 Provider, MCP und Varianten
Mehr erfahrenWir setzen OpenSpec zusammen mit OpenCode ein. Der größte Gewinn liegt für uns im Review vor der Umsetzung: Ein Proposal mit klaren Aufgaben und prüfbaren Kriterien zeigt früh, ob der Agent das Richtige bauen will. Das spart mehr Zeit als jedes schnellere Modell.
Zwei Dinge haben sich bewährt. Specs schreiben wir auf Englisch, auch wenn das Team deutsch spricht, weil Schlüsselwörter wie SHALL und MUST und die Validierung darauf ausgelegt sind. Und jede Aufgabe bekommt ein Prüfkriterium, das in unseren CI/CD Pipelines automatisch läuft.
Wo wir helfen: im Vibe Coding Consulting, beim Aufbau von Quality Gates für KI Code, beim Einordnen der BMAD Method und von Everything Claude Code und im Vibe Coding Training für Teams. Verwandte Werkzeuge erklärt das NCA Glossar für KI Tools.
Roland Golla ist Entwickler aus Leidenschaft – seit über 20 Jahren. Er hat hunderte Projekte begleitet, von Legacy-Refactoring bis KI-Integration. Bei Vibe Coding verbindet er das Beste aus beiden Welten: Die Geschwindigkeit von KI-generiertem Code mit der Qualität professioneller Softwareentwicklung. Kein Bullshit, keine Agentur-Floskeln – direkte Hilfe von jemandem, der selbst täglich im Code steckt.
Die wichtigsten Fragen zum Spec Driven Development Framework, Stand Oktober 2026.
OpenSpec ist ein Open Source Framework für Spec Driven Development mit KI Coding Agents. Vor jeder Änderung entsteht ein kurzer Plan aus Proposal, Design, Aufgaben und Spec Deltas, der als Markdown im Repository liegt. Mensch und Agent lesen denselben Plan, bevor Code entsteht. Entwickelt wird OpenSpec von Fission AI unter MIT Lizenz.
Spec Driven Development ist ein Ansatz, bei dem eine Spezifikation die Quelle der Wahrheit für die Entwicklung ist. Die KI setzt Code auf Basis dieser Spec um, nicht auf Basis flüchtiger Chat Prompts. Das macht Ergebnisse nachvollziehbar, prüfbar und über lange Projekte hinweg konsistent, gerade wenn mehrere Agents oder Teammitglieder beteiligt sind.
OpenSpec arbeitet mit über 30 KI Tools zusammen, darunter OpenCode, Claude Code, Codex, Cursor, GitHub Copilot, Zed, Kimi Code, Hermes Agent und Antigravity. Beim Initialisieren erkennt OpenSpec vorhandene Tool Verzeichnisse und legt passende Skills oder Slash Commands an. Ein herstellerneutrales Ziel unter .agents/skills bedient alle Agents, die AGENTS.md lesen.
Seit dem Sommer 2026 kamen unter anderem /opsx:update zum Überarbeiten laufender Pläne, Support für Zed und Kimi Code, Specs in anderen Sprachen über init --language, openspec show --diff für echte Änderungen und openspec status --all dazu. Die Linie 1.13 im September brachte klarere Validierungsmeldungen und eine Migration von project.md zu config.yaml.
Ja. OpenSpec ist vollständig Open Source unter MIT Lizenz und kostenlos nutzbar. Es braucht weder API Key noch MCP Server. Kosten entstehen nur bei den KI Modellen, die dein Agent für Planung und Umsetzung nutzt. Mit kleinen lokalen Modellen über Ollama lassen sich einfache Changes sehr günstig umsetzen.
Delta Specs sind Differenz Spezifikationen, die Änderungen ausdrücklich markieren: ADDED für neue Anforderungen, MODIFIED für geänderte und REMOVED für entfernte. Beim Archivieren fließen sie in die Hauptspezifikation ein. Seit Version 1.11 zeigt openspec show mit --diff nur die Zeilen, die sich wirklich ändern, das erleichtert Reviews deutlich.
Brownfield first heißt, dass OpenSpec vor allem für bestehende Projekte gebaut ist. Es unterstützt schrittweise Änderungen an vorhandenem Code, ohne dass das ganze System vorher neu dokumentiert werden muss. Die Spezifikation wächst mit jedem Change. Bei Legacy Code setzen wir trotzdem zuerst Quality Gates auf, bevor ein Agent Änderungen umsetzt.
Ja. Seit Version 1.10 setzt openspec init --language die Sprache der erzeugten Dokumente. Überschriften und die Schlüsselwörter SHALL und MUST bleiben Englisch, damit die Validierung funktioniert. Wir schreiben Specs trotzdem bewusst auf Englisch, weil Agents und Prüfungen damit am zuverlässigsten arbeiten und gemischte Sprachen im Repository Verwirrung stiften.
GitHub Spec Kit ist umfassend dokumentiert und stark auf GitHub ausgerichtet, aber aufwändiger in der Einrichtung. OpenSpec ist leichtgewichtiger, bei der Tool Wahl offen und bringt mit Delta Specs und Archiv einen klaren Ablauf für bestehende Projekte mit. Für Teams mit gemischten Agents ist OpenSpec meist die schnellere Wahl.
Installiere OpenSpec global über npm und richte es im Projekt mit openspec init --tools opencode ein. Danach stehen die Workflows als Skills und Slash Commands in OpenCode bereit, zum Vorschlagen, Umsetzen und Archivieren von Changes. Planung lohnt sich mit einem starken Reasoning Modell, die Umsetzung oft mit einer schnelleren Variante.
OpenSpec sammelt anonyme Nutzungsstatistiken wie Command Namen und Version, keine Inhalte, Pfade oder persönlichen Daten. Seit Version 1.8 lässt sich die Telemetrie über telemetry.enabled: false in der Konfiguration abschalten, das stoppt auch die Update Prüfung. Umgebungsvariablen und CI Erkennung schalten sie ebenfalls ab.
NCA richtet OpenSpec zusammen mit OpenCode, Quality Gates und CI Pipeline ein, damit Plan und Prüfung zusammenpassen. Wir zeigen, wie gute Proposals aussehen, wie Aufgaben prüfbare Kriterien bekommen und wie Specs in bestehenden Projekten mitwachsen. Das kostenlose Kennenlernen klärt, wo dein Team gerade steht.
