GitHub Spec Kit ist ein Open-Source-Toolkit, das KI-Coding-Agenten zwingt, erst Spezifikationen zu schreiben und dann Code. Statt einem LLM eine vage Beschreibung zu geben und auf korrekte Ausgabe zu hoffen, definiert man, was gebaut werden soll, plant die Architektur, zerlegt alles in Aufgaben und lässt erst dann die KI implementieren. Das Toolkit funktioniert mit über 24 Coding-Agenten, von GitHub Copilot über Claude Code bis Gemini CLI, und hat auf GitHub mehr als 80.000 Stars erreicht.
Die Grundidee: Sprachmodelle sind hervorragend im Vervollständigen von Mustern, aber miserabel im Gedankenlesen. Ein vager Prompt zwingt das Modell, unausgesprochene Anforderungen zu erraten. Manche Vermutungen sind falsch. Spezifikationsgetriebene Entwicklung eliminiert das Raten, indem jede Anforderung, jede Architekturentscheidung und jede Aufgabengrenze explizit festgelegt wird, bevor eine einzige Zeile Code entsteht.
Warum Vibe Coding bei wachsender Komplexität scheitert
Vibe Coding, die Praxis, einem KI-Agenten zu beschreiben, was man will, und die Ausgabe ohne Prüfung zu akzeptieren, funktioniert für Prototypen. Man promptet, führt aus, gibt Fehlermeldungen zurück, bis es kompiliert. Für ein Wochenendprojekt ist das in Ordnung.
Die Probleme zeigen sich, wenn Projekte über eine einzelne Datei hinauswachsen. KI-generierter Code enthält im Durchschnitt 2,74-mal mehr Sicherheitslücken, besonders bei Eingabevalidierung und Authentifizierung. Googles DORA-Forschung hat einen Rückgang der Lieferstabilität um 7,2% gemessen, wenn Teams KI ohne Governance-Strukturen einsetzen. Agenten wurden dabei beobachtet, wie sie Validierungschecks entfernen, Datenbankrichtlinien lockern und Authentifizierung abschalten, nur um Laufzeitfehler zu beheben.
GitHubs Den Delimarsky, Principal Product Manager und der Kopf hinter Spec Kit, bringt es auf den Punkt: “Das Problem ist nicht die Coding-Fähigkeit des Agenten, sondern unser Ansatz. Wir behandeln Coding-Agenten wie Suchmaschinen, obwohl wir sie wie buchstabentreue Pair-Programmierer behandeln sollten.” Ein buchstabentreuer Pair-Programmierer braucht ein Briefing. Spec Kit ist dieses Briefing.
Die Kluft zwischen “es kompiliert” und “es tut, was wir brauchen” ist genau das, worauf spezifikationsgetriebene Entwicklung abzielt. Statt tausend Zeilen Code-Dumps zu sichten und auf Fehler zu hoffen, prüft man fokussierte Spezifikationen, die beschreiben, was das System tun soll, und validiert dann, ob die Implementierung übereinstimmt.
Der Vier-Phasen-Workflow: Specify, Plan, Tasks, Implement
Spec Kit strukturiert KI-gestützte Entwicklung in vier kontrollierte Phasen. Man geht nicht zur nächsten Phase über, bevor die aktuelle validiert ist. Das ist der Schlüsselunterschied sowohl zu Vibe Coding als auch zu traditionellem Agile: Spezifikationen sind keine optionale Dokumentation, die nach dem Sprint-Planning ignoriert wird. Sie sind die ausführbaren Verträge, die die Codegenerierung steuern.
Phase 1: Specify
Man beschreibt, was gebaut werden soll, in Form von User Journeys, Erfolgskriterien und funktionalen Anforderungen. Noch keine technischen Entscheidungen. Der Befehl /speckit.specify erzeugt ein strukturiertes Spezifikationsdokument.
# Spec Kit im Projekt initialisieren
uvx --from git+https://github.com/github/spec-kit.git specify init mein-projekt
# Spezifikation generieren
/speckit.specify
Die Spezifikation erfasst das “Was” und “Warum”, ohne das “Wie” vorzuschreiben. Diese Trennung erlaubt es, mehrere technische Ansätze auf Basis derselben Anforderungen zu erkunden.
Phase 2: Plan
Der Befehl /speckit.plan übersetzt die Spezifikation in einen technischen Implementierungsplan. Hier fallen die Architekturentscheidungen: welches Framework, welche Datenbank, welche Patterns. Das Plandokument wird zum gemeinsamen Kontext, der den KI-Agenten auf die technische Vision ausrichtet.
Wenn die Spezifikation Bereiche enthält, die zu vage für eine sichere Implementierung sind, fügt das Plandokument [NEEDS CLARIFICATION]-Marker ein. Das ist Spec Kits Anti-Halluzinations-Mechanismus: Statt eine Implementierung zu erfinden, wenn Anforderungen mehrdeutig sind, markiert es die Lücke und bittet um Klärung.
Phase 3: Tasks
Der Befehl /speckit.tasks zerlegt den Plan in kleine, überprüfbare und testbare Arbeitseinheiten. Jede Aufgabe hat klare Akzeptanzkriterien, und ein KI-Agent kann sie isoliert implementieren, ohne den gesamten Projektkontext im Gedächtnis halten zu müssen.
Phase 4: Implement
Erst jetzt schreibt der KI-Agent Code. Jede Aufgabe wird einzeln implementiert, gegen ihre Akzeptanzkriterien getestet und geprüft, bevor die nächste beginnt. Die kognitive Belastung für den Reviewer sinkt drastisch, weil man nicht auf einen monolithischen Diff starrt, sondern auf eine fokussierte Änderung, die eine spezifische, vorab genehmigte Aufgabe umsetzt.
Dieser phasenbasierte Ansatz erzeugt einen vollständigen Audit-Trail. Jedes Spezifikations-, Plan- und Aufgabendokument lebt im Repository neben dem Code. Wenn jemand sechs Monate später fragt “Warum haben wir das so gebaut?”, liegt die Antwort im .specify/-Verzeichnis, nicht in irgendjemandes Slack-Nachrichten.
Für Unternehmen im DACH-Raum, die unter den Dokumentationspflichten des EU AI Act arbeiten, ist dieser automatische Audit-Trail besonders wertvoll. Die Nachvollziehbarkeit von Anforderung zu Implementierung ist bei KI-generierten Systemen keine optionale Nettigkeit, sondern eine regulatorische Erwartung.
Agent-agnostisch: Über 24 unterstützte Coding-Agenten
Wo Kiro spezifikationsgetriebene Entwicklung in eine proprietäre IDE einbaut, geht Spec Kit den entgegengesetzten Weg. Es ist ein portables Toolkit, das sich um jeden bereits genutzten Coding-Agenten legt.
Der specify init-Befehl fragt, welchen Agenten man verwendet, und erzeugt die passenden Konfigurationsdateien, Slash-Commands und Integrationsskripte. Aktuell unterstützte Agenten:
- IDE-Agenten: GitHub Copilot, Cursor, Windsurf, JetBrains Junie, VS Code
- CLI-Agenten: Claude Code, Gemini CLI, Codex CLI, Qwen Code, Kiro CLI
- Spezialtools: IBM Bob, Pi Coding Agent, OpenCode, Codebuddy
- Enterprise: Qoder CLI, Amp, SHAI, Mistral Vibe
- Custom: Eigene Agenten via
--ai generic
Das ist entscheidend, weil Teams selten nur einen einzigen Coding-Agenten nutzen. Ein Entwickler bevorzugt Cursor, ein anderer Claude Code, ein dritter Gemini CLI. Spec Kit gibt ihnen einen gemeinsamen Workflow, unabhängig von der Werkzeugwahl. Die Spezifikationen, Pläne und Aufgabenlisten sind identisch, egal ob ein Mensch oder eine KI sie liest, und egal welche KI.
Das agent-agnostische Design macht den Workflow auch zukunftssicher. Wenn der nächste populäre Coding-Agent erscheint, tauscht man das Template aus und behält Spezifikationen, Pläne und Aufgabenzerlegungen bei.
Anpassung: Constitutions, Extensions und Presets
Spec Kit ist kein starrer Workflow. Es enthält ein dreistufiges Anpassungssystem, mit dem Teams eigene Standards in den spezifikationsgetriebenen Prozess einbetten können.
Constitutions (/speckit.constitution) definieren die nicht verhandelbaren Prinzipien eines Projekts: Testanforderungen, Performance-Ziele, Sicherheitsrichtlinien, Compliance-Regeln. Jede danach generierte Spezifikation berücksichtigt diese Vorgaben. Wenn die Organisation 80% Testabdeckung und OWASP-Top-10-Scans verlangt, codiert man das einmal, und jede Spezifikation erbt es.
Für DACH-Teams bedeutet das: DSGVO-Anforderungen an Datenverarbeitung, die Dokumentationspflichten des EU AI Act oder branchenspezifische Regularien lassen sich direkt in die Constitution einbetten. Jeder Agent, der danach Spezifikationen generiert, berücksichtigt diese Regeln automatisch.
Extensions erweitern den Workflow um neue Fähigkeiten. Eine Extension könnte eine Sicherheitsüberprüfung zwischen Planung und Aufgabenerstellung einfügen oder Dokumentationsanforderungen in jede Aufgabe injizieren.
Presets formen die gesamte Erfahrung um. Sie können Terminologie, Workflow-Schritte und Ausgabeformate ändern. Die Community hat bereits kreative Beispiele produziert: Ein Preset verwandelt Spezifikationen in “Voyage Manifests” und Aufgaben in “Crew Assignments.”
Praxisbeispiele: Vom Greenfield-Projekt bis zur 420.000-Zeilen-Codebasis
GitHub hat fünf detaillierte Community-Walkthroughs veröffentlicht, die Spec Kit in verschiedenen Szenarien zeigen:
Greenfield .NET CLI-Tool: Bei einem Projekt von Null hat Spec Kit drei mehrdeutige Anforderungen in der Spezifikationsphase abgefangen, die bei direktem Vibe Coding zu falschen Implementierungen geführt hätten.
Spring Boot + React-Plattform: Ein Full-Stack-Projekt, bei dem die Spezifikation Backend-API-Verträge von Frontend-Verhaltensanforderungen trennte. Zwei KI-Agenten arbeiteten an derselben Spezifikation ohne Konflikte, weil die Aufgabengrenzen explizit waren.
Brownfield ASP.NET CMS: Erweiterung eines bestehenden Systems ohne es zu zerstören. Das Plandokument kodierte die bestehende Architektur als Constraints und verhinderte, dass die KI Rewrites vorschlug, wo inkrementelle Erweiterung gefragt war.
Großes Java-Runtime-Projekt (420.000 Zeilen, 180 Module): Der härteste Testfall. Spec Kits Aufgabenzerlegung brach eine modulübergreifende Änderung in 14 isolierte Aufgaben auf, jede auf ein spezifisches Modul bezogen. Die Alternative (einen KI-Agenten die Änderung über 180 Module gleichzeitig versuchen lassen) hätte einen nicht überprüfbaren Diff erzeugt.
Go/React-Dashboard via Copilot CLI: Ein reiner Terminal-Workflow, der beweist, dass Spec Kit keine IDE benötigt.
Wann Spec Kit sich lohnt (und wann nicht)
Spec Kit kostet Vorlaufzeit. Das ist der Trade-off, und er ist real. Die InfoWorld-Analyse stellt fest, dass spezifikationsgetriebene Entwicklung langsamer ist als ungelenkte KI-Codierung und vorhandene Entwicklungsexpertise erfordert.
Spec Kit lohnt sich, wenn:
- Ein Greenfield-Feature mit komplexen Anforderungen oder mehreren Stakeholdern gebaut wird
- Eine große bestehende Codebasis modifiziert wird und die KI strukturelle Constraints braucht
- Mehrere Entwickler am selben Projekt arbeiten und ein gemeinsames Verständnis benötigen
- Compliance- oder Audit-Anforderungen Nachvollziehbarkeit von Anforderung zu Implementierung verlangen
- Man bereits die Erfahrung gemacht hat, dass Vibe Coding plausibel aussehenden Code erzeugt, der an Randfällen zerbricht
Spec Kit überspringen, wenn:
- Es um einen Wegwerf-Prototyp geht
- Die Aufgabe ein einzelnes Skript oder Utility ist
- Umfassende Anforderungen bereits in einem anderen System liegen (Jira, Linear, Notion)
- Geschwindigkeit bis zur ersten funktionierenden Version wichtiger ist als langfristige Wartbarkeit
Der Sweet Spot sind Teams, die Features bauen, die in die Produktion gehen und gewartet werden müssen. Spec Kit eliminiert nicht die Notwendigkeit von Entwickler-Expertise; es macht diese Expertise effektiver, indem es den Fokus auf Spezifikationsprüfung statt auf Zeile-für-Zeile-Code-Review legt.
In fünf Minuten starten
# Specify CLI installieren
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@v0.1.4
# Neues Projekt mit bevorzugtem Agenten initialisieren
specify init mein-projekt --ai claude-code
# Oder zu bestehendem Projekt hinzufügen
cd bestehendes-projekt
specify init . --ai copilot
# Mit einer Spezifikation starten
/speckit.specify
Das initialisierte Projekt erzeugt ein .specify/-Verzeichnis mit Templates, Konfiguration und der Agenten-Integration. Die Slash-Commands (/speckit.specify, /speckit.plan, /speckit.tasks, /speckit.implement) steuern den Workflow über die Oberfläche des gewählten Agenten.
Für Organisationen hinter Firewalls unterstützt Spec Kit die Installation ohne Internetzugang via pip download und GitHub-Token-Authentifizierung für Unternehmensumgebungen.
Häufig gestellte Fragen
Was ist GitHub Spec Kit?
GitHub Spec Kit ist ein Open-Source-Toolkit, das spezifikationsgetriebene Entwicklung für KI-Coding-Agenten ermöglicht. Es bietet einen Vier-Phasen-Workflow (Specify, Plan, Tasks, Implement), der KI-Agenten zwingt, Anforderungen zu verstehen, bevor sie Code schreiben. Es unterstützt über 24 Coding-Agenten, darunter GitHub Copilot, Claude Code, Cursor und Gemini CLI.
Was ist der Unterschied zwischen Spec-Driven Development und Vibe Coding?
Vibe Coding bedeutet, einer KI eine Beschreibung zu geben und den generierten Code ohne Prüfung zu akzeptieren. Spec-Driven Development verlangt explizite Spezifikationen, technische Pläne und Aufgabenzerlegungen, bevor Code geschrieben wird. Die KI implementiert gegen genehmigte Spezifikationen, statt unausgesprochene Anforderungen zu erraten.
Welche KI-Coding-Agenten unterstützt Spec Kit?
Spec Kit unterstützt über 24 KI-Coding-Agenten, darunter GitHub Copilot, Cursor, Windsurf, JetBrains Junie, Claude Code, Gemini CLI, Codex CLI, Qwen Code, Kiro CLI, IBM Bob und viele weitere. Es bietet auch einen generischen Agenten-Modus für nicht unterstützte Tools.
Wie unterscheidet sich Spec Kit von Kiro IDE?
Kiro IDE ist ein proprietärer VS Code Fork von AWS, der spezifikationsgetriebene Entwicklung in seine IDE einbaut. Spec Kit ist ein Open-Source-Toolkit, das agent-agnostisch um jeden bereits genutzten Coding-Agenten gelegt wird. Spec Kit funktioniert über IDEs und CLI-Tools hinweg, während Kiro ein eigenständiges Produkt mit eigener Editor-Erfahrung ist.
Lohnt sich Spec Kit trotz des zusätzlichen Zeitaufwands?
Für Produktionsfeatures mit komplexen Anforderungen ja. Spec Kit kostet Vorlaufzeit bei der Spezifikation, reduziert aber Debugging, Nacharbeit und das Problem “es funktioniert, aber ist nicht das, was gemeint war”. Für schnelle Prototypen oder Wegwerf-Skripte ist direktes KI-Coding schneller. Der Trade-off begünstigt Spec Kit, wenn Code langfristig gewartet werden muss.