Spec Kit: ein Open-Source-Toolkit für spezifikationsgetriebene Entwicklung
Toolkit, das Ihnen den Einstieg in die spezifikationsgesteuerte Entwicklung erleichtert. Spec Kit Definieren Sie, was erstellt werden soll, bevor Sie es erstellen, mit einem beliebigen KI-Codierungsagenten.
Auf einen Blick
- Was ist das?
- Ein Open-Source-Python-Toolkit, das Spezifikationen in ausführbare Artefakte für KI-Codierungsagenten verwandelt, mit Erweiterungen, Presets und rollenbasierten Bundles.
- Für wen ist es gedacht?
- Das README stellt Spec Kit als ein prozessorientiertes Toolkit dar: erst festlegen, was gebaut werden soll, dann planen, in Aufgaben zerlegen, implementieren und konvergieren, mit Erweiterungen und Bundles zur Anpassung. Die MIT-Lizenz gewährt weitreichende Rechte, aber keine Garantie, und das Projekt nennt die Forschung von John Lam als Haupteinfluss.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Das Repository hat innerhalb des letzten Tages neue Commits erhalten.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Was das README unter spezifikationsgetriebener Entwicklung versteht
Das README beginnt nicht mit einer Funktionsliste, sondern mit einer Definition. Spezifikationsgetriebene Entwicklung kehrt dort die herkömmliche Reihenfolge um: Statt zuerst Code zu schreiben und Spezifikationen als Gerüst zu betrachten, das man später verwirft, werden Spezifikationen ausführbar und erzeugen direkt funktionierende Implementierungen. Das Repository bezeichnet sich selbst als Open-Source-Toolkit zum Bau hochwertiger Software mit beliebigen KI-Codierungsagenten, das entweder einen einsatzbereiten spezifikationsgetriebenen Prozess mitbringt oder die Möglichkeit bietet, einen eigenen zu verwenden. Das README enthält keine Benchmarks oder Produktionsergebnisse; Aussagen über gemessene Ergebnisse müssten also anderswo überprüft werden.
Installation der Specify-CLI und Projektinitialisierung
Für die Installation wird uv benötigt, ein Python-Paketmanager. Das README zeigt die Installation der CLI aus dem Git-Repository mit einem Release-Tag, wobei das führende v erhalten bleibt (als Beispiel wird v0.12.11 genannt). Das Paket ist auch auf PyPI als specify-cli veröffentlicht. Nach der Installation erstellt `specify init my-project --integration copilot` ein Projekt und richtet die Agentenintegration ein. Mit Selbstverwaltungsbefehlen lassen sich neue Releases prüfen (`specify self check`), ein Upgrade in der Vorschau anzeigen (`specify self upgrade --dry-run`), ein Upgrade direkt ausführen oder ein bestimmter Tag festlegen. Das README erwähnt außerdem, dass uvx-Ausführungen (ephemer) und Quellcode-Checkouts erkannt werden und statt eines Installers pfadspezifische Hinweise erzeugen.
Der Slash-Befehls-Workflow nach init
Nach der Initialisierung stellt der Agent eine Reihe von Befehlen bereit. Die meisten Agenten exponieren spec-kit als `/speckit.*`-Slash-Befehle; die Codex-CLI im Skills-Modus verwendet stattdessen `$speckit-*`, und die GitHub-Copilot-CLI nutzt `/agents`. Der Kernablauf ist: `/speckit.constitution` erstellt Leitprinzipien, `/speckit.specify` beschreibt, was gebaut werden soll, `/speckit.plan` liefert die Technologieentscheidungen, `/speckit.tasks` zerlegt den Plan in Aufgaben, und `/speckit.implement` führt sie aus. Zu den optionalen Befehlen gehören `/speckit.clarify` für unklare Bereiche, `/speckit.analyze` für Konsistenzprüfungen und `/speckit.checklist` für individuelle Qualitätschecklisten. Bei Integrationen mit Skills-Modus installiert `--integration-options="--skills"` Agentenskills statt Slash-Befehls-Promptdateien.
Erweiterungen, Presets und der Prioritätsstapel
Spec Kit lässt sich über zwei Systeme plus projektlokale Überschreibungen anpassen. Der Prioritätsstapel von oben nach unten: projektlokale Überschreibungen in `.specify/templates/overrides/`, Presets in `.specify/presets/templates/`, Erweiterungen in `.specify/extensions/templates/` und der Kern in `.specify/templates/`. Vorlagen werden zur Laufzeit aufgelöst, von oben nach unten wird die erste Übereinstimmung verwendet. Befehle von Erweiterungen und Presets werden zur Installationszeit angewendet und über `specify extension add` bzw. `specify preset add` in die Agentenverzeichnisse geschrieben. Erweiterungen fügen neue Befehle und Vorlagen hinzu, Presets überschreiben vorhandene Vorlagen und Befehle, auch die von installierten Erweiterungen. Das README nennt Beispiele wie Jira-Integration und regulatorische Rückverfolgbarkeit, listet aber keinen vollständigen Katalog.
Bundles für rollenbasierte Einrichtungen
Ein Bundle bündelt Erweiterungen, Presets, Schritte und Workflows zu einer versionierten, rollenorientierten Einrichtung, die durch ein handgeschriebenes `bundle.yml`-Manifest beschrieben wird. Ein Bundle ohne `integration`-Feld ist agentenneutral und erbt die bereits verwendete Integration des Projekts. Zu den Befehlen gehören Suche, Info, Installation, Auflistung, Update und Entfernung. Bundles werden aus einem priorisierten Katalogstapel (Projekt, Benutzer, eingebaut) aufgelöst; die Installationsrichtlinie erlaubt entweder die Installation oder beschränkt eine Quelle auf reine Erkennung. Das README nennt Garantien: info zeigt genau das, was install hinzufügt; Installationen sind idempotent und auf das Projektverzeichnis beschränkt; remove berührt keine Komponenten, die ein anderes installiertes Bundle noch benötigt; alle Konsum- und Autorenbefehle funktionieren offline gegen lokale oder festgelegte Quellen. Beispiele für Produktmanager, Business-Analyst, Sicherheitsforscher und Entwickler liegen unter `examples/bundles/`.
Entwicklungsphasen und experimentelle Ziele
Das README beschreibt drei Entwicklungsphasen. Die 0-zu-1-Entwicklung (Greenfield) erzeugt von Grund auf, von Anforderungen auf hoher Ebene bis zu produktionsreifen Anwendungen. Kreative Erkundung unterstützt parallele Implementierungen über mehrere Technologie-Stacks und UX-Muster hinweg. Iterative Verbesserung (Brownfield) behandelt die Modernisierung bestehender Systeme, fügt Funktionen schrittweise hinzu oder passt Prozesse an. Ein eigener Abschnitt listet experimentelle Ziele: Technologieunabhängigkeit, Unternehmenszwänge, nutzerzentrierte Entwicklung sowie kreative und iterative Prozesse. Das README nennt die Arbeit von John Lam als starken Einfluss. Zu einem Zeitplan, einer Roadmap oder einem Release-Plan für diese Ziele sagt das README nichts.
Voraussetzungen, Support und Lizenz
Voraussetzungen sind Linux, macOS oder Windows; ein unterstützter KI-Codierungsagent; uv (empfohlen) oder pipx für die Paketverwaltung; Python 3.11 oder neuer; und Git. Das README sagt, dass 30+ KI-Codierungsagenten unterstützt werden, verweist für die vollständige Liste auf einen Leitfaden, nennt sie aber nicht einzeln. Support läuft über GitHub-Issues. Der Auszug aus der MIT-Lizenz gewährt die Rechte zur Nutzung, Vervielfältigung, Änderung, Zusammenführung, Veröffentlichung, Verbreitung, Unterlizenzierung und zum Verkauf, vorbehaltlich der Lizenzbedingungen, und stellt die Software "as is", ohne jegliche Gewährleistung bereit. Zur Sicherheitslage, zu Supportzusagen oder Wartungsgarantien sagt der Lizenztext nichts.
Redaktionelles Fazit
Das README stellt Spec Kit als ein prozessorientiertes Toolkit dar: erst festlegen, was gebaut werden soll, dann planen, in Aufgaben zerlegen, implementieren und konvergieren, mit Erweiterungen und Bundles zur Anpassung. Die MIT-Lizenz gewährt weitreichende Rechte, aber keine Garantie, und das Projekt nennt die Forschung von John Lam als Haupteinfluss. Was das README nicht dokumentiert, etwa Produktionsleistung oder die vollständige Integrationsliste, lässt sich aus dieser Quelle nicht belegen.
Community-Notizen