Spec Kit vs. OpenSpec: Was passt zu Ihrem KI-Coding-Workflow

Spec Kit und OpenSpec sind beide Open-Source-Werkzeuge unter MIT-Lizenz und zielen auf dasselbe Problem: Wenn Anforderungen nur im Chatverlauf stehen, ist das Ergebnis eines KI-Coding-Assistenten schwer vorherzusagen. Also schreibt man die Spezifikation auf und lässt Mensch und KI sich einigen, bevor Code entsteht. Sie unterscheiden sich im Gewicht des Prozesses, in der Organisation der Spezifikationen und in der Werkzeugkette.

Zuerst unsere Position

Der eigene Workflow von HagiCode basiert auf OpenSpec, wir haben also eine Vorliebe. Die folgenden Fakten stammen aus der offiziellen Dokumentation beider Projekte, geprüft am 26.10.2026, und unsere Meinung ist als solche gekennzeichnet. Beide Projekte entwickeln sich schnell, lesen Sie vor der Entscheidung daher die jeweils aktuelle Dokumentation.

Was verglichen wird

• Spec Kit: von GitHub. Die Kommandozeile ist specify (das Python-Paket specify-cli); Installation und Nutzung finden Sie unter Spec Kit installieren.
• OpenSpec: von Fission AI. Die Kommandozeile ist openspec (das npm-Paket @fission-ai/openspec); siehe die Einführung in OpenSpec.

Wichtigste Unterschiede

Dimension	Spec Kit	OpenSpec
Laufzeit	Python 3.11+, Installation mit uv oder pipx	Node.js 20.19.0+, Installation mit npm oder Homebrew
Installationsbefehl	uv tool install specify-cli	npm install -g @fission-ai/openspec@latest
Initialisierung	specify init my-project --integration claude	openspec init im Projekt
Befehlspräfix	/speckit-*	/opsx:* (in manchen Assistenten /opsx-*, in Codex $openspec-*)
Hauptablauf	constitution → specify → clarify → plan → checklist → tasks → analyze → implement → converge; der kürzeste Weg ist specify → plan → tasks → implement → converge	Das Standardprofil hat propose, explore, apply, update, sync und archive; das erweiterte Profil ergänzt new, continue, ff, verify und mehr
Artefakte pro Feature	spec.md, plan.md, tasks.md sowie Checklisten und Analyseergebnisse	Ein Änderungsordner mit proposal.md, specs/, design.md und tasks.md
Organisation der Spezifikationen	Eine vollständige Spezifikation rund um ein einzelnes Feature	Aufgebaut auf Delta-Spezifikationen: ADDED und MODIFIED beschreiben die Änderung und werden beim Archivieren in die langlebigen Spezifikationen übernommen
Erweiterbarkeit	Erweiterungen und Presets; offiziell gibt es unter anderem bug und assess	Eigene Schemas und Community-Schemas
Mehrere Repositories	Im Kernablauf der offiziellen Dokumentation haben wir keine eigene Repository-übergreifende Unterstützung gefunden	Stores (Beta) halten die Planung in einem eigenen Repository und teilen sie mit mehreren Code-Repositories
Unterstützte Assistenten	Die offizielle Dokumentation listet Dutzende Integrationen	Die offizielle Dokumentation nennt mehr als 30 Werkzeuge
Lizenz	MIT	MIT

Prozessgewicht: der am häufigsten genannte Unterschied

Das README von OpenSpec fasst Spec Kit als gründlich, aber schwergewichtig zusammen, mit starren Phasen-Gates, viel Markdown und einem Python-Setup, und positioniert sich selbst als leichter, weil jedes Artefakt jederzeit überarbeitet werden kann. Das ist die Beschreibung von OpenSpec selbst.

Fairerweise: Der Schnellstart von Spec Kit nennt selbst einen Fünf-Schritte-Kurzweg, bei dem constitution, clarify, checklist und analyze optional sind, und auch das erweiterte Profil von OpenSpec hat reichlich Befehle. Der eigentliche Unterschied liegt nicht in der Zahl der Befehle, sondern in der Grundhaltung. Spec Kit liest sich eher wie eine Pipeline von der Spezifikation bis zur Umsetzung, die am Ende konvergiert, während OpenSpec betont, dass jede Änderung ein eigener Ordner ist, den Sie jederzeit bearbeiten können.

Nach Szenario wählen

Die folgenden Hinweise sind unsere Einschätzung, kein offizielles Fazit eines der beiden Projekte.

Ihre Situation	Bessere Wahl	Warum
Ein neues Projekt mit einem vollständigen Ablauf von der Spezifikation bis zur Umsetzung	Spec Kit	Ein vollständiger Ablauf, eine constitution, die das ganze Projekt bindet, und converge, das den Kreis gegen die Spezifikation schließt
Viel bestehender Code, jeweils kleine Änderungen	OpenSpec	Delta-Spezifikationen beschreiben nur das Geänderte, ohne dass für bestehende Funktionen eine vollständige Spezifikation neu geschrieben werden muss
Ein überwiegend Python-lastiges Team, das uv gewohnt ist	Spec Kit	Die Installationsart passt zum Stack
Ein überwiegend Node.js-lastiges Team	OpenSpec	Ein npm-Befehl genügt zur Installation
Ein Feature betrifft mehrere Repositories	OpenSpec	Stores können den Plan in einem gemeinsamen Repository halten; beachten Sie, dass es noch Beta ist
Sie wünschen viele fertige Erweiterungen (Fehlerbehebung, Ideenbewertung)	Spec Kit	Die offizielle Website listet mehr Erweiterungen und Presets
Anforderungen ändern sich oft und Sie möchten Spezifikationen und Pläne jederzeit bearbeiten	OpenSpec	Die Artefakte haben keine strengen Phasen, sodass Sie zurückgehen und bearbeiten können

Entscheidungshilfe

1. Schauen Sie vor den Features auf Ihren Stack und Ihre Gewohnheiten. Die beiden überschneiden sich stark im Funktionsumfang, und die Reibung durch eine unpassende Umgebung wiegt meist schwerer.
2. Lassen Sie beide am selben kleinen Feature laufen. Wählen Sie eine Anforderung, die einen halben Tag dauert, und gehen Sie mit jedem den vollständigen Ablauf durch. Das ist verlässlicher, als zehn Vergleichsartikel zu lesen.
3. Installieren Sie nicht beide in einem Projekt. Beide Werkzeuge erzeugen Befehle und Verzeichnisse im Projekt, und eine Mischung macht die Befehlsliste Ihres Assistenten unübersichtlich.
4. Beurteilen Sie nach drei Dingen: ob das Schreiben der Spezifikation Nacharbeit tatsächlich verringert hat, ob Ihr KI-Assistent offiziell unterstützt wird und ob das Team bereit ist, diese Markdown-Dateien zu pflegen.

Wie HagiCode vorgeht

Wir nutzen OpenSpec seit langem und haben darum herum eine Spezifikationsverwaltung über mehrere Repositories sowie die Wahl des Agenten je Phase aufgebaut. Beschrieben ist das in diesen beiden Artikeln: Optimierung der OpenSpec-Leistung in verschiedenen Phasen mit verschiedenen Agenten: HagiCode Praxiszusammenfassung und Was ist MonoSpecs: Warum es eine Weiterentwicklung und Erweiterung von OpenSpec ist. Das ist unsere Wahl und heißt nicht, dass es für jedes Team besser ist. Wenn Spec Kit besser zu Ihrem Team passt, funktioniert es genauso mit den von HagiCode unterstützten Agent-CLIs wie Claude Code und Codex; die Einrichtung finden Sie unter Installation von AI Agent CLI.

Empfohlener Weg

• Um schnell eines auszuprobieren: Wählen Sie das, das zu Ihrem Stack passt, installieren Sie es und gehen Sie an einem kleinen Feature nur den kürzesten Weg.
• Um sauber zu vergleichen: Folgen Sie Punkt 2 oben mit beiden und entscheiden Sie dann nach „Menge der Nacharbeit“ und „Akzeptanz im Team“.
• Um tiefer einzusteigen: Lesen Sie Spec Kit installieren und die Einführung in OpenSpec.