OpenSpec Review: mein neuer Daily Driver für AI Coding

OpenSpec Review: mein neuer Daily Driver für AI Coding

Als ich openspec apply zum ersten Mal für ein echtes Projekt ausführte, trat ich zurück, um meinen Kaffee nachzufüllen, und vergaß es. Zwei Stunden und siebzehn Minuten später kam ich zurück zu einem funktionierenden Dashboard, einer bestandenen Testsuite und einem Ordner

Das ist nicht der beeindruckende Teil. Das Beeindruckende daran ist, was am nächsten Morgen passierte, als ich eine zweite Funktion hinzufügen musste. Ich habe den Code nicht geöffnet. Ich habe den Specs-Ordner geöffnet. Ich habe drei kurze Markdown-Dateien gelesen. Und ich wusste mit einer Klarheit, die ich normalerweise erst nach einer Woche Kontextladen bekomme, genau, wo die neue Funktion eingebunden werden sollte und was sie berühren würde.

In diesem Moment verstand ich, was der OpenSpec

Ich verwende es seit zwei Wochen als Daily Driver für drei Projekte: ein Laravel-Administratortool, das ich für einen Kunden umgestalte, ein Next.js-Nebenprojekt, das ich von Grund auf neu gestartet habe, und eine vorhandene Python-Codebasis, die ich geerbt habe und die ungefähr die Dokumentationshygiene einer Geiselnotiz aufweist. OpenSpec hat sich in allen drei Kategorien seinen Platz verdient. Aber nicht aus den Gründen, die auf den Marketingseiten aufgeführt sind.

Dies ist die vollständige Aufschlüsselung – was OpenSpec ist, wo es sich in der AI coding framework-Landschaft befindet, die genauen Befehle, die ich ausführe, und die ehrlichen Stellen, an denen es nicht hilft. Wenn Sie bereits Stunden damit verbracht haben, zuzusehen, wie in einer Claude Code-Sitzung Code anhand einer Spezifikation generiert wird, die von Anfang an falsch war, werden sich die nächsten 4.000 Wörter persönlich anfühlen.

Die drei Kategorien von AI Coding Frameworks (und warum es wichtig ist)

Bevor OpenSpec einen Sinn ergibt, benötigen Sie die Karte des Territoriums, in dem es lebt. Ich habe diesen Fehler gemacht, als ich es zum ersten Mal bewertet habe – ich habe es mit Tools verglichen, die es nie zu schlagen versuchte, und hätte es aus den falschen Gründen fast verworfen.

Es gibt drei verschiedene Kategorien von AI coding frameworks, die im Jahr 2026 ausgeliefert werden, und sie lösen unterschiedliche Probleme:

Diese Kategorien konkurrieren nicht direkt miteinander. Sie stapeln sich.

Ein echter Produktionsstack sieht eher so aus: Gleiches Problem aus drei Blickwinkeln. Verschiedene Schichten derselben Maschine.

Der Fehler bei den meisten „spec-driven vs. autonomen“ Artikeln besteht darin, dass sie diese als Alternativen behandeln. Das sind sie nicht. Es sind Stufen. Und OpenSpec ist die unterste Ebene – diejenige, die entscheidet, woran die anderen beiden Ebenen arbeiten werden.

Deshalb ist es wichtiger, diese Ebene richtig zu machen, als die Schichten darüber. Eine perfekte Fähigkeit zur TDD-Durchsetzung wird Sie nicht retten, wenn die Spezifikation, die sie durchsetzt, am ersten Tag falsch war. Eine autonome Pipeline, die in einem Sprint 40 PRs versendet, wird einfach 40 falsche PRs versenden. Die Spezifikationsqualität ist der vorgelagerte Engpass. Alles andere verstärkt die dort getroffene Entscheidung – im Guten wie im Schlechten.

Die Frage lautet also nicht „OpenSpec oder BMAD?“ Die Frage lautet: „Ist OpenSpec gut genug, um die Quelle der Wahrheit zu sein, der alles nachgelagerte vertraut?“ Das habe ich getestet.

Was OpenSpec eigentlich ist

OpenSpec ist ein Open-Source-Entwicklungsframework spec-driven, das als npm-Paket @fission-ai/openspec ausgeliefert und von Fission-AI verwaltet wird. Es läuft in jedem Projekt als dünne Schicht über Ihrem AI-Codierungsassistenten – Claude Code, Cursor,

Die Kernidee ist in ihrer Einfachheit brutal. Die Spezifikation ist das Artefakt. Der Code ist das Kompilierungsziel. Jede Funktion befindet sich in einer Markdown-Datei in Ihrem Repo, bevor eine einzelne Codezeile geschrieben wird, und diese Datei wird zum Vertrag, den AI-Assistenten ausführen.

Drei Dinge an dieser Idee sind wichtiger als die Idee selbst.

Erstens sind die Spezifikationen in Ihrem Repo verfügbar. Nicht in einem SaaS-Dashboard. Nicht in einem Notion-Dokument, das in dem Moment abweicht, in dem jemand auf „Versenden“ klickt. In einem openspec/-Ordner, in Git, mit Diffs können Sie in PRs wie jede andere Codeänderung überprüfen. Dies ist der Teil, den die meisten Teams unterschätzen, bis sie sechs Monate später rekonstruieren müssen, was eine Funktion leisten sollte. Mit OpenSpec erhalten Sie git log die Spezifikation.

Zweitens handelt es sich bei den Spezifikationen um Deltas. In jedem Vorschlag werden Ergänzungen, Änderungen und Entfernungen explizit gekennzeichnet. Wenn die Änderung ausgeliefert wird, werden die Deltas in die Master-Spezifikation integriert. Das ist die Brownfield-Magie – so bleibt OpenSpec auf älteren Codebasen verwendbar, anstatt Sie zu zwingen, eine 200.000-Zeilen-App neu zu starten, um es zu verwenden.

Drittens ist der Arbeitsablauf fließend, kein Wasserfall. Die offizielle Formulierung von Fission-AI ist „flüssig, nicht starr, iterativ, kein Wasserfall“ – und nach zwei Wochen kann ich bestätigen, dass das kein Marketing ist. Sie können in jeder Phase in den Workflow einsteigen, eine Schleife ausführen, wenn die Implementierung etwas aufdeckt, das die Spezifikation übersehen hat, und Sie können archive ausführen, um eine Teiländerung zu übernehmen und eine neue zu starten. Es fühlt sich weniger wie ein Prozess an, sondern eher wie ein Notizbuch, das zufällig eine Struktur erzwingt.

Der deutlichste Vergleich ist das Spec Kit von GitHub. Ich habe beide getestet. Spec Kit ist umfangreicher – laut der Vergleichsarbeit Hashrocket veröffentlicht umfassen seine Spezifikationen etwa 800 Zeilen pro Feature, im Vergleich zu etwa 250 bei OpenSpec. Spec Kit behandelt jedes Feature als eigene unabhängige Datei. OpenSpec konsolidiert sich zu einer einzigen lebendigen Quelle der Wahrheit, die sich im Laufe der Zeit verändert. Für ein sauberes Greenfield-Unternehmensfeature mit formellen Review-Gates ist der umfangreichere Output von Spec Kit gerechtfertigt. Für alles andere, was ich tue – Refactors, Nebenprojekte, Agenturkundenarbeit – gewinnt der geringere Platzbedarf von OpenSpec, weil ich die Spezifikation tatsächlich noch einmal lesen werde.

Das ist die philosophische Ebene. So sieht es in der Praxis aus.

Installation von OpenSpec und der First-Run-Erfahrung

Das Setup ist ein Befehl. Nicht „ein Befehl, nachdem Sie drei Abhängigkeiten installiert haben“. Ein Befehl.

npm install -g @fission-ai/openspec
cd your-project
openspec init

Knoten 20.19.0 oder höher ist erforderlich. Der Befehl init fragt Sie, welchen AI-Assistenten Sie verwenden – ich habe Claude Code für das Laravel-Projekt, Cursor für Next.js und Codex für die Python-Codebasis ausgewählt – und er schreibt die entsprechenden Slash-Befehlsbindungen in die Konfiguration Ihres Projekts, damit der Assistent weiß, wie er OpenSpec aufruft.

Hier ist mir als erstes aufgefallen, dass ich dem Tool vertrauen konnte. Bei einer Neuinitialisierung wirft OpenSpec Sie nicht vor ein leeres Dokument und sagt „Viel Glück“. Es verfügt über einen Onboarding-Skill, der Sie interaktiv durch Ihr erstes Angebot führt. Sie werden gefragt, was Sie bauen. Es wird gefragt, wer der Benutzer ist. Es wird gefragt, was die Erfolgskriterien sind. Dies geschieht im Markdown, der in Ihrem Repo gespeichert ist. Das erste Artefakt, das Sie haben, ist also kein Tutorial, sondern der Beginn einer echten Spezifikation für eine echte Funktion.

Vergleichen Sie das mit meiner Erfahrung, die ich mit Spec Kit gemacht habe. Beim Spec Kit-Onboarding wird davon ausgegangen, dass Sie das Vier-Phasen-Modell (/specify, /plan, /tasks, /implement) bereits kennen, und Sie gelangen direkt zum Schritt /specify. Wenn Sie die spec-driven-Entwicklung noch nie verwendet haben, schreiben Sie eine Spezifikation, deren Form falsch ist, und finden drei Befehle später heraus, dass /tasks Unsinn produziert.

Das Onboarding von OpenSpec macht den Unterschied zwischen Lernen durch Lesen und Lernen dadurch, dass man gleich beim ersten Mal das Richtige tut. Es ist ein kleines Detail. Aus diesem Grund habe ich OpenSpec jetzt auch zwei Freunden empfohlen, die noch nie zuvor mit der Entwicklung von spec-driven in Berührung gekommen waren.

Die Befehlsreferenz: Was jeder tut und wann ich ihn verwende

OpenSpec wird mit einem Basisbefehlssatz und einem erweiterten Befehlssatz namens opsx ausgeliefert, für den Sie sich über openspec config profile entscheiden. Ich habe das erweiterte Profil verwendet, weil ich jedes Tool nutzen möchte, das das Framework bietet. Hier ist die vollständige Tabelle mit den tatsächlichen Verwendungszwecken der einzelnen Elemente in der Produktion:

| /openspec:apply | Implementieren Sie die im Vorschlag definierten Aufgaben | Die Build-Phase – läuft ca. 2 Stunden autonom, 3–4 Stunden mit meinen Unterbrechungen | | /opsx:verify | Validieren Sie die Implementierung anhand der Spezifikation, einschließlich visueller UI-Prüfungen über die Chrome-Integration | Entwerfen Sie Systemmigrationen und UI-lastige Funktionen | | /openspec:archive | Führen Sie die Änderungsdeltas in die Master-Spezifikation ein und übergeben Sie die lebendige Quelle der Wahrheit | Alle ausgelieferten Funktionen, keine Ausnahmen | | /opsx:bulk-archive | Mehrere abgeschlossene Änderungen in einem Durchgang archivieren | Ende eines Sprints, wenn ich 3–5 Features ausgeliefert habe | | /opsx:sync | Synchronisieren Sie den Master-Specs-Ordner mit dem, was sich tatsächlich in der Codebasis befindet | Wenn ich eine Abweichung zwischen Code und Spezifikation vermute | | /opsx:onboard | Führen Sie den interaktiven Onboarding-Skill erneut aus | Einen Teamkollegen oder ein neues Projekt in den OpenSpec-Workflow einbinden |

Die vollständige Befehlsliste befindet sich im offiziellen OpenSpec-Befehlsdokument und die erweiterte Profilreferenz befindet sich im opsx-Dokument. Was nicht in den Dokumenten steht, ist die Reihenfolge, in der ich sie ausführe, oder welche ich überspringe – und das ist der nächste Abschnitt.

Der Workflow, den ich tatsächlich ausführe

Hier ist die genaue Reihenfolge, die ich letzte Woche eingehalten habe, als ich eine „Benutzeraktivitätszeitleiste“-Funktion in das Laravel-Administratortool integriert habe. Das Ganze dauerte etwa vier Stunden, wovon vielleicht vierzig Minuten auf mich entfielen und der Rest OpenSpec im Hintergrund arbeitete.

Schritt 1: Informieren Sie sich, bevor Sie einen Vorschlag machen

Der erste Befehl, den ich bei jeder Änderung über „trivial“ ausführe, ist /opsx:explore. Dies ist die am meisten unterschätzte Funktion im Framework und die einzige Funktion von OpenSpec, die das GitHub Spec Kit ausdrücklich ablehnt.

Beim Design des Spec Kits wird davon ausgegangen, dass Sie beim Betreten von /specify bereits wissen, was Sie bauen möchten. Diese Annahme ist meiner Erfahrung nach in etwa 70 % der Fälle falsch. Was ich normalerweise habe, ist eine vage Vorstellung, drei Einschränkungen, an die ich mich halb erinnern kann, und die Vermutung, dass es eine Komplikation gibt, die mir noch nicht aufgefallen ist. Wenn ich aus diesem Zustand eine Spezifikation schreibe, ist die Spezifikation falsch und ich werde es vier Schritte später herausfinden.

/opsx:explore gibt mir die Möglichkeit, mich laut zu irren. Der Agent stellt mir klärende Fragen. Es untersucht die Codebasis. Es bringt Unklarheiten zum Vorschein, von denen ich nicht wusste, dass sie existieren. Bei der Funktion „Aktivitätszeitleiste“ hat die Erkundung drei Dinge aufgedeckt, die mir entgangen wären, wenn ich direkt zu einem Vorschlag gesprungen wäre: Die vorhandene Prüfprotokolltabelle wies eine Spaltenmehrdeutigkeit auf, die zu Abfragekollisionen geführt hätte, zwei meiner „Benutzeraktionen“ waren tatsächlich zwei verschiedene Ereignisse, die ich geistig zusammengebrochen hatte, und die UI-Anforderung implizierte eine Echtzeitkomponente, die ich nicht eingeplant hatte.

Das sind ungefähr zwei Tage Nacharbeit, die durch die Erkundung in fünfzehn Minuten verhindert wurden.

Wenn ich ehrlich bin, habe ich /opsx:explore in den ersten drei Tagen fast nie verwendet. Es fühlte sich an wie über Kopf. Dann habe ich es mit einem Refactor ausprobiert, bei dem sich herausstellte, dass es eine versteckte Abhängigkeit von einer veralteten Cache-Ebene gibt, und habe es seitdem nicht mehr übersprungen. Das Muster, das ich verinnerlicht habe: Wenn ich die Änderung nicht ohne Einschränkungen in einem Satz erklären kann, führe ich zuerst explore aus.

Schritt 2: Vorschlagen, fortfahren oder vorspulen

Sobald die Erkundung den Nebel verzogen hat, führe ich abhängig von der Änderungsgröße einen von drei Befehlen aus:

• /openspec:propose für kleine, weitreichende Änderungen, bei denen alles in einem Durchgang generiert werden soll.
• /opsx:continue für größere Änderungen möchte ich in vertikale Abschnitte aufteilen – zuerst den Vorschlag, dann die Spezifikation, dann die Aufgaben, mit jeweils einem Review-Gate dazwischen.
• /opsx:ff, wenn die Erkundung gründlich war und ich möchte, dass OpenSpec schnell durch die verbleibenden Schritte des Vorschlags/spec/tasks vorspult, ohne dass ich durch jedes Gate klicken muss.

Die Ausgabe ist jeweils die gleiche: ein changes/[change-name]/-Ordner mit proposal.md (das Warum und Was),

Dies ist der Moment im Arbeitsablauf, in dem die Spezifikation nicht mehr mir gehört, sondern dem Team gehört. Auch wenn das Team nur aus mir besteht. Der Vorschlag kann in einer PR überprüft werden. Das design.md erfasst die architektonischen Entscheidungen in einer Sprache, die ein zukünftiges Ich verstehen kann. Der specs/-Ordner ist der Teil, den der AI-Assistent während der Implementierung als Vertrag behandelt – und vor allem ist es der Teil, der die Änderung überlebt und in der Master-Spezifikation im Archiv zusammengeführt wird.

Ein Hinweis dazu, was die OpenSpec-Spezifikationen unterscheidet. Jede Spezifikation beschreibt Funktionsszenarien – gegebene Erzählungen im /when/then-Stil, die das Verhalten beschreiben. Keine Implementierungsdetails. Nicht „der Controller ruft das Repository auf.“ Verhalten. Dies ist die Form, die Codebasisänderungen überlebt. Wenn ich die Persistenzschicht in sechs Monaten umgestalte, ist die Spezifikation immer noch korrekt, da es in der Spezifikation nie darum ging, wie die Persistenzschicht funktioniert. Es ging darum, was der Benutzer sah und tun konnte.

Schritt 3: Bewerben (Oder: Wie ich aufgehört habe, den Bau anzuschauen)

/openspec:apply ist der Befehl, der die Funktion erstellt. Hier verbleibt der größte Teil der Laufzeit – etwa zwei Stunden autonome Arbeit an der Aktivitätszeitleistenfunktion, drei bis vier Stunden, wenn ich mitten im Build unterbreche, um Dinge zu klären.

Was ich hier lernen musste, ist, wann man unterbricht und wann man weggeht. Mein erster Instinkt war, die Bewerbungsphase zu betreuen, so wie ich eine Claude Code-Sitzung betreue: jeden Unterschied lesen, jede Dateiänderung genehmigen, jede Entscheidung noch einmal überdenken. Dieser Instinkt ist bei OpenSpec falsch. Die Spezifikation hat meine Entscheidungen bereits kodiert. In der Bewerbungsphase wird lediglich der Vertrag ausgeführt. Wenn ich unterbrechen möchte, um „eine andere Wahl zu treffen“, besteht der richtige Schritt fast immer darin, die Bewerbung abzubrechen, zum Vorschlag zurückzukehren, die Spezifikation zu korrigieren und erneut zu bewerben.

Nachdem ich das verinnerlicht hatte, begann ich, die Bewerbungsphase im Hintergrund laufen zu lassen, während ich an etwas anderem arbeitete. Lasche geöffnet, Terminal sichtbar, aber ich starre nicht darauf. Das erste Mal, als ich das tat, war unangenehm. Beim fünften Mal war es das normale Muster. Beim zehnten Mal ertappte ich mich dabei, dass ich zwei Funktionen parallel ausgeliefert hatte, indem ich apply in zwei Terminals gegen zwei verschiedene Vorschläge ausgeführt hatte.

Dies ist der Moment, der mein mentales Modell der AI-Codierung verändert hat. Der Engpass war nicht mehr die Ausführung. Es wurde zur Spezifikationsqualität. Das bedeutet, dass meine Zeit damit begann, sich auf den Teil der Arbeit zu konzentrieren, der tatsächlich menschliches Urteilsvermögen erfordert, und der Rest auf den Agenten verlagert wurde.

Schritt 4: Überprüfen (das unterschätzte Killer-Feature)

/opsx:verify ist der Befehl, über den niemand spricht, und er ist derjenige, der OpenSpec im Next.js-Nebenprojekt unersetzlich gemacht hat.

Das Next.js-Projekt umfasste die Migration eines alten Designsystems auf ein neues – dieselben Komponenten, neue Token, neue Abstandsskala, neue Typografie. Dies ist eine Albtraumklasse für AI-Codierungstools, da der Code technisch korrekt und optisch völlig falsch sein kann. Eine Schaltfläche kann rendern. Eine Schaltfläche kann auch in der falschen Größe, in der falschen Schriftart oder mit dem falschen Rahmenradius gerendert werden und jeden von Ihnen geschriebenen Test bestehen.

/opsx:verify wird mit einer Chrome-Erweiterungsintegration geliefert, die visuelle Genauigkeitsprüfungen anhand der Spezifikation durchführt. Es lädt die Seite, erfasst den gerenderten Zustand und vergleicht ihn mit der in der Spezifikation kodierten Designabsicht. Bei der Migration des Designsystems wurden sieben visuelle Regressionen festgestellt, die der Testsuite entgangen waren. Abstandsinkonsistenzen. Eine falsche Schriftstärke bei einer Überschriftenvariante. Eine Komponente, die einen Spielraum vom alten System übernommen hatte und ihre Gitterzelle an bestimmten Haltepunkten überfüllte.

Dies ist die Funktion, die es in keinem anderen von mir getesteten AI coding framework gibt. Spec Kit hat es nicht. BMAD hat es nicht. Obra Superpowers kann erzwingen, dass Sie Tests geschrieben haben, kann Ihnen jedoch nicht sagen, dass der Test bestanden wurde, während die Seite falsch aussieht. Für UI-intensive Arbeiten, insbesondere Designsystemmigrationen, ist /opsx:verify der Unterschied zwischen Versand und korrektem Versand.

Der ehrliche Vorbehalt: Es ist keine Zauberei. Für die Chrome-Erweiterung muss Ihr Entwicklungsserver ausgeführt werden. Die visuellen Prüfungen sind nur so gut wie die Designabsicht, die Sie in der Spezifikation festgelegt haben. Und es kann keine Interaktionsfehler erkennen – nur statische Rendering-Probleme. Aber für die Art von Fehlern, die es fängt, gibt es nichts anderes.

Schritt 5: Archivieren (Der Trick mit der lebendigen Dokumentation)

Dies ist der Schritt, den ich in der ersten Woche fast übersprungen hätte. Es ist auch der Schritt, der in aller Stille der wichtigste ist.

/openspec:archive übernimmt die Änderung, die Sie gerade versendet haben, und führt ihre Deltas im Master-Ordner specs/ zusammen. Der Vorschlag wird in ein changes/archive/-Verzeichnis verschoben. In die Master-Spezifikation – die lebendige Quelle der Wahrheit – werden die neuen Funktionen eingebunden, die Änderungen angewendet und die Entfernungen entfernt.

Das Ergebnis ist, dass Ihr Repo nach jeder ausgelieferten Funktion eine aktuelle, genaue und maschinenlesbare Beschreibung des Verhaltens des gesamten Systems enthält. Keine veraltete README-Datei. Keine Confluence-Seite, die seit achtzehn Monaten nicht berührt wurde. Der tatsächliche aktuelle Zustand.

Ich habe sechs Tage nach der Verwendung von OpenSpec getestet, was das bedeutet, indem ich Claude Code gebeten habe, dem Laravel-Projekt eine neue Funktion hinzuzufügen – ohne ihm einen Kontext zu geben. Ich sagte ihm: „Lesen Sie openspec/specs/ und schlagen Sie dann eine Änderung vor, die X hinzufügt.“ Es wurden die technischen Daten gelesen. Es wurde eine Änderung vorgeschlagen, die zwei vorhandene Funktionen korrekt identifizierte, mit denen interagiert werden musste. Dies geschah ohne meine Aufforderung zur Codebasis-Architektur, da die Architektur bereits in der Spezifikation enthalten war.

Dies ist das erste Mal, dass ich sehe, dass „lebende Dokumentation“ tatsächlich ein tragender Teil eines AI-Codierungsworkflows ist und nicht nur ein „nice-to-have“. Bei den meisten Projekten verbringen Sie die ersten fünf Minuten jeder Claude Code-Sitzung damit, den Kontext neu zu laden. Bei OpenSpec lädt sich der Kontext selbst.

Wenn sich archive jemals wie ein Overhead anfühlt, kann ich Ihnen versprechen, dass dies nicht der Fall ist. Durch das Überspringen des Archivs verrotten spec-driven-Projekte. Jedes Team, mit dem ich über die aufgegebene spec-driven-Entwicklung gesprochen habe, hat es getan, weil ihre Spezifikationen vom Code abwichen. Archiv ist die Disziplin, die Drift verhindert. Behandeln Sie es als Teil von „Funktion erledigt“, nicht als optionalen Bereinigungsschritt.

Wo OpenSpec zu kurz kommt (Der ehrliche Abschnitt)

Ich bin seit zwei Wochen dabei und ein Fan, aber ein Fan, der dies in drei Projekten mit sehr unterschiedlichen Formen durchgeführt hat. Hier hilft es nicht.

Kleine Änderungen. Wenn die Änderung „Diesen Tippfehler beheben“ oder „Diese Variable umbenennen“ lautet, verursacht der OpenSpec-Workflow einen Overhead. Machen Sie keinen Vorschlag für eine einzeilige Lösung. Das Framework behauptet nichts anderes – Fission-AI rät ausdrücklich davon ab –, aber ich habe gesehen, wie Neulinge jede Änderung durch den Vorschlagsfluss erzwingen und am Ende einen changes/-Ordner erhalten, der wie ein Friedhof trivialer PRs aussieht. Verwenden Sie OpenSpec für Dinge, über die man nachdenken sollte. Überspringen Sie es für Dinge, bei denen dies nicht der Fall ist.

Solo-Codierungssitzungen, bei denen Sie wirklich nicht wissen, was Sie wollen. Wenn Sie sich im reinen Erkundungsmodus befinden – Skizzieren, Prototyping, Code an die Wand werfen – wird Sie die Vorschlagsphase verlangsamen. Das richtige Muster besteht hier darin, zuerst Vibe-Code zu erstellen. Wenn Sie dann wissen, was Sie erstellt haben, schreiben Sie die Spezifikation nachträglich und archive als ersten Vorschlag. OpenSpec ist mit diesem Ablauf einverstanden. Aber der Versuch, etwas zu spezifizieren, das Sie noch nicht entworfen haben, ist das Schlimmste aus beiden Welten.

Die Anwendungslaufzeit von zwei Stunden ist real. Die meisten Anwendungsläufe liegen für nicht triviale Funktionen im Bereich von 90 bis 180 Minuten. Wenn Sie eine Funktion innerhalb von zwanzig Minuten benötigen, ist OpenSpec nicht das richtige Tool. Dies ist kein Fehler – die Spezifikationsqualität macht die Anwendungsphase zuverlässig, und die Kodierung und Ausführung dieser Qualität erfordert Zeit. Aber gehen Sie mit Ihren Erwartungen um. OpenSpec ist ein Tool für den richtigen Versand, nicht für den schnellen Versand.

Brownfield-Onboarding hat Ecken und Kanten. Bei der geerbten Python-Codebasis führte mein erster Versuch, OpenSpec einzuführen, zu einer Master-Spezifikation, die etwa 40 % genau mit dem tatsächlichen Code übereinstimmte. Das Framework versuchte, Spezifikationen aus Code abzuleiten, der keine Leitprinzipien hatte, und die Schlussfolgerungen waren notwendigerweise unscharf. Der Fix bestand darin, /opsx:onboard ordnungsgemäß auszuführen, sich Zeit zu nehmen, die Master-Spezifikation für die Kernflüsse manuell zu schreiben und dann OpenSpec für neue Änderungen zu verwenden. Wenn Sie damit rechnen, OpenSpec auf eine Legacy-Codebasis zu übertragen und die Codebasis bis Freitag zu verstehen, werden Sie enttäuscht sein. Planen Sie eine echte Onboarding-Woche.

Die Community ist klein. Verglichen mit der GitHub-Präsenz von BMAD oder der Unternehmensunterstützung von Spec Kit ist OpenSpec das kleinere Ökosystem. Die Dokumente sind gut. Der Veröffentlichungsrhythmus ist gesund. Aber es gibt noch keinen umfassenden Stapel an Tutorials, Plugins oder Integrationen von Drittanbietern. Wenn Sie etwas benötigen, was das Framework nicht von Haus aus kann, schreiben Sie es selbst. Für mich ist das in Ordnung – ich hätte lieber ein kleines, fokussiertes Werkzeug als ein großes, aufgeblähtes –, aber es ist wissenswert.

Wo OpenSpec jetzt in meinen Stack passt

Nach zwei Wochen steht OpenSpec ganz oben in meinem AI-Codierungsworkflow – über Claude Code, über den Agentenfähigkeiten, die ich ausführe, über den Planungsnotizen, die ich früher in Obsidian aufbewahrt habe. Es ist das Erste, was ich bei einer nicht trivialen Änderung berühre, und das Letzte, was ich berühre, wenn ich sie versende.

Der vollständige Stapel sieht folgendermaßen aus:

1. OpenSpec schreibt und pflegt die Spezifikation – den Vertrag für das, was erstellt wird
2. Claude Code mit Obra Superpowers führt die Spezifikation mit TDD-Erzwingung während der Anwendungsphase aus
3. Standard-Git-Review fängt ein, was TDD übersehen hat
4. Archivieren sperrt die Änderung in der lebenden Spezifikation, bereit für die nächste Iteration

Jedes Werkzeug macht das, was es am besten kann. OpenSpec versucht nicht, TDD durchzusetzen – das ist die Aufgabe von Superpowers. Superpowers versucht nicht, die Spezifikation zu verwalten – das ist die Aufgabe von OpenSpec. Claude Code versucht nicht, sich an alles zu erinnern, was erstellt wurde – das ist die Aufgabe der Master-Spezifikation.

Diese Trennung der Belange macht den Stapel tatsächlich skalierbar. Wenn etwas kaputt geht, weiß ich, welche Ebene ich debuggen muss. Wenn ich ein Teil aufrüsten möchte, kann ich es austauschen, ohne die anderen neu bauen zu müssen. Die Zusammensetzbarkeit ist der Sieg.

Sollten Sie OpenSpec verwenden?

Drei Fragen, die Sie ehrlich beantworten sollten:

Versenden Sie Funktionen, die mehr als zwei Stunden konzentrierter Arbeit erfordern? Wenn ja, amortisiert sich OpenSpec durch die zweite Funktion. Wenn Sie nur Mikroänderungen versenden, überspringen Sie dies.

Kehren Sie jemals nach zwei Wochen zu einem Projekt zurück und müssen den Kontext neu laden? Wenn ja, sparen Sie mit der Living-Spezifikation jeden Monat Stunden. Wenn Ihre Projekte alle aktuell sind und Ihr Gedächtnis perfekt ist, ist der Wert niedriger.

Vertrauen Sie Ihrem AI-Assistenten mehr, wenn er einen klaren Vertrag zur Ausführung hat? Wenn ja, ist OpenSpec die Vertragsschicht. Wenn Sie lieber nur mit dem Assistenten chatten und Schritt für Schritt steuern möchten, wird sich der Angebotsfluss wie Reibung anfühlen.

Ich habe alle drei Fragen mit „Ja“ beantwortet, und OpenSpec war die folgenreichste Ergänzung meines Workflows, seit ich angefangen habe, Claude Code zu verwenden. Nicht weil es irgendetwas deutlich besser macht als die Alternativen, sondern weil es jedes andere Tool in meinem Stack zuverlässiger macht. Die Spezifikation ist der stromaufwärts gelegene Drosselpunkt. OpenSpec hat die Drosselstelle sauber gemacht.

Häufig gestellte Fragen

Wofür wird OpenSpec verwendet?

OpenSpec ist ein spec-driven-Entwicklungsframework für AI-Codierungsassistenten. Sie schreiben eine Markdown-Spezifikation einer Funktion und das Framework stimmt sich mit Ihrem AI-Assistenten (Claude Code, Cursor, Codex und mehr als 20 andere) ab, um die Spezifikation zu implementieren, das Ergebnis zu validieren und die Änderung in einer lebendigen Quelle der Wahrheit zusammenzuführen. Es wird am häufigsten für mittlere bis große Features in Brownfield-Codebasen verwendet, bei denen die Spezifikationsqualität einen entscheidenden Wert hat.

Wie unterscheidet sich OpenSpec vom GitHub Spec Kit?

OpenSpec konsolidiert Spezifikationen in einem einzigen lebenden Dokument mit deltabasierten Änderungen, während Spec Kit separate Spezifikationsdateien pro Feature verwaltet. OpenSpec erstellt leichtere Spezifikationen (ca. 250 Zeilen gegenüber 800 Zeilen im Spec Kit), unterstützt nativ Brownfield-Codebasen und bietet einen iterativen Workflow mit der /opsx:explore-Phase. Das umfangreichere Vier-Phasen-Modell von Spec Kit eignet sich besser für die formelle Unternehmensarbeit auf der grünen Wiese. Eine ausführlichere Aufschlüsselung finden Sie oben unter „Was OpenSpec tatsächlich ist“.

Funktioniert OpenSpec mit Claude Code?

Ja – Claude Code ist einer von über 20 unterstützten AI-Codierungsassistenten. Während openspec init wählen Sie Claude Code als Ihren Assistenten aus und OpenSpec schreibt die entsprechenden Slash-Befehlsbindungen in Ihr Projekt. Cursor, Codex, Windsurf, Continue, GitHub Copilot, Amazon Q, Gemini CLI und andere werden ebenfalls vollständig unterstützt.

Wie lange dauert ein OpenSpec-Anwendungslauf?

Ein typischer openspec apply-Lauf dauert bei autonomer Ausführung nicht trivialer Funktionen im Bereich von 90 bis 180 Minuten. Durch das Hinzufügen menschlicher Kontrollpunkte und Klärungen während des Baus verlängert sich die Arbeitszeit auf 3–4 Stunden. Die meiste Zeit arbeitet der AI-Assistent und wartet nicht – Sie können ihn im Hintergrund laufen lassen, während Sie an etwas anderem arbeiten.

Kann OpenSpec BMAD oder Obra Superpowers ersetzen?

Nein, und Sie sollten nicht versuchen, es zu schaffen. OpenSpec ist ein spec-driven-Framework. BMAD ist ein autonomer Pipeline-Orchestrator. Obra Superpowers ist eine SDLC-Durchsetzungsebene. Sie lösen verschiedene Probleme und lassen sich gut kombinieren: OpenSpec schreibt die Spezifikation, Superpowers erzwingt TDD während des Builds, BMAD orchestriert Multi-Feature-Pipelines. Eine vollständige Aufschlüsselung dieser drei Kategorien finden Sie in der Vergleichstabelle oben in diesem Artikel.

Lasst uns zusammenarbeiten

Möchten Sie AI-Systeme aufbauen, Arbeitsabläufe automatisieren oder Ihre technische Infrastruktur skalieren? Ich würde gerne helfen.

• Fiverr (benutzerdefinierte Builds und Integrationen): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (Unternehmenslösungen): ramlit.com
• ColorPark (Design & Branding): colorpark.io
• xCyberSecurity (Sicherheitsdienste): xcybersecurity.io