GitHub Spec Kit vs. Kiro vs. Claude Code SDD-Workflows

Entwickler, die 2026 Spec-Driven Development (SDD)-Setup vergleichen, fragen in der Regel nicht, welches Modell das intelligenteste ist. Sie fragen, welcher Arbeitsfluss eine KI-Agentur ohne sie in Bürokratie zu ertränken, korrekt ausrichtet.

GitHub Spec Kit, AWS Kiro und benutzerdefinierte Claude Code-Arbeitsflüsse implementieren alle dieselbe grundlegende Idee – Anforderungen, Design, Aufgaben, Implementierung, Validierung – wobei sie jedoch Portabilität, Integrationsiefe und den Grad des erzwungenen Prozesses gegeneinander abwägen.

Wenn Sie die Konzepte zuerst kennenlernen möchten, lesen Sie Was ist Spec-Driven Development? und den toolunabhängigen Leitfaden Spec-Driven Development Workflow im App-Architektur-Dokumentationscluster. Dieser Vergleich befindet sich im KI-Entwickler-Tools-Hub neben Assistenten-Reviews und Workflow-Leitfäden. Er behandelt die drei Setups, über die Entwickler auf Hacker News und Reddit-ähnlichen Foren am meisten diskutieren, sowie die leichteren und schwereren Alternativen, die sie umgeben.

SDD wird zu einer Kategorie von Tools

Spec-Driven Development war Ende 2025 mehr als nur ein theoretisches Konzept. Jeder große Anbieter von KI-Coding-Tools liefert nun eine Version von „spezifizieren-planen-implementieren", und eine wachsende Liste von eigenständigen Tools konkurriert darum, wie viel Struktur sie in diesen Zyklus einbetten.

Der entscheidende Vergleich ist nicht „welches Tool gewinnt". Es geht um Prozessiefe gegenüber Portabilität. Kiro ist integriert. Spec Kit ist portabel. Claude Code-Arbeitsflüsse sind anpassbar. Schlechte Spezifikationen machen jeden Agenten schlechter, unabhängig davon, welche Hülle Sie wählen. Gute Spezifikationen sind über Tools hinweg tragbar.

Wie man SDD-Setups vergleicht

Bevor Sie ein Tool auswählen, bestimmen Sie, worauf Sie optimieren. Dasselbe Feature kann in einem Setup mühelos wirken und in einem anderen bürokratisch sein, abhängig von Teamgröße, Alter des Codebases und dem Umfang der benötigten Überprüfung.

Portabilität – Können die Spezifikationen als reines Markdown in Ihrem Repository leben und mit dem Agenten funktionieren, den Sie im nächsten Quartal bevorzugen? Oder sind sie an eine IDE, eine Cloud oder ein proprietäres Format gebunden?

Setup-Reibung – Wie lange dauert es vom „Ich möchte SDD ausprobieren" bis zu einem funktionierenden spezifizieren-planen-Aufgaben-Loop? CLI-Scaffolding, IDE-Installation oder das eigene Erstellen von Slash-Commands haben unterschiedliche Aktivierungsenergien.

Spezifikationsqualität – Hilft das Tool Ihnen, präzise Anforderungen und Akzeptanzkriterien zu schreiben, oder generiert es hauptsächlich lange Dokumente? Struktur ist nützlich. Volumen nicht.

Aufgabenausführung – Wie unterteilt das Tool die Arbeit in überprüfbare Abschnitte? Können Aufgaben parallel ausgeführt werden? Widersteht es Explosionen von fünfzig Aufgaben?

Überprüfungsmeilensteine – Gibt es natürliche menschliche Kontrollpunkte zwischen Spezifizieren, Planen, Aufgaben und Implementieren? SDD ohne Überprüfung ist nur langsames Vibe Coding.

Repository-Verankerung – Liest der Workflow Projektkonventionen, Entscheidungsprotokolle, ADRs, AGENTS.md und vorhandenen Code vor der Planung? Agenten ohne Verankerung erfinden die Architektur neu, weil sie die überprüfte Absicht hinter früheren Entscheidungen nie sehen.

Teamzusammenarbeit – Können mehrere Personen dieselben Spezifikationsartefakte in Pull Requests überprüfen? Können Sie Agenten mischen, ohne den Prozess neu zu schreiben?

Abhängigkeit (Lock-in) – Was verlieren Sie, wenn Sie in sechs Monaten Editoren, Modelle oder Cloud-Anbieter wechseln?

GitHub Spec Kit

GitHub Spec Kit ist ein Open-Source-CLI-Toolkit, das einen spec-gesteuerten Loop in Ihr Repository scaffoldd und die Ausführung an den Coding-Agenten übergibt, den Sie bereits verwenden. Die specify-CLI fügt Vorlagen, Slash-Commands und ein konventionelles Verzeichnislayout hinzu. Typische Befolge folgen einer Konstitution-Spezifizieren-Klären-Planen-Aufgaben-Implementieren-Sequenz, mit einem expliziten Klärungsschritt, um Mehrdeutigkeit zu lösen, bevor die Architekturarbeit beginnt.

Der definierende Vorteil von Spec Kit ist die Agenten-Unabhängigkeit. Die offiziellen Docs positionieren es als Tooling, das mit Claude Code, GitHub Copilot, Cursor, Gemini CLI, Codex und dutzenden anderen Agenten funktioniert. Sie schreiben Spezifikationen einmal in Markdown, committen sie wie Code und tauschen den Executor aus, ohne den Prozess neu zu schreiben. Das macht Spec Kit zur Standardempfehlung für Teams, die SDD wollen, ohne auf einen einzelnen Anbieter zu setzen.

Die Trade-offs sind real. Spec Kit kann einen großen Artefaktbaum erzeugen – Konstitution, Spezifikation, Plan, Aufgaben, Verträge – was sich bei Multi-Session-Features auszahlt, aber für eine kleine CLI-Anpassung schwer wirkt. Hacker News-Threads vergleichen diesen Overhead regelmäßig mit Wasserfall-Zeremonie. Spec Kit ist auch schwächer, wenn Sie eine vollständig integrierte IDE wünschen, in der Spezifikationen, Aufgaben und Implementierung in einer geführten Oberfläche leben. Es legt Prozess über Ihren bestehenden Editor, anstatt ihn zu ersetzen.

Spec Kit passt zu Teams, die bereits einen bevorzugten AI-Coding-Assistenten haben und ein standardisiertes SDD-Scaffolding darüberlegen wollen. Es ist besonders stark für Greenfield-Features, Multi-Agent-Shops und alle, die Editor-Lock-in ablehnen.

AWS Kiro

Kiro ist AWS’ spec-gesteuerte IDE, aufgebaut auf einem VS Code / Code OSS Fork. Während Spec Kit SDD in Ihren bestehenden Stack bringt, geht Kiro davon aus, dass SDD eine zweckgebundene Umgebung verdient. Ein Prompt generiert strukturierte Artefakte – typischerweise requirements.md in EARS-Notation, design.md und eine abhängigkeitsequenzierte tasks.md –, bevor Agenten Produktionscode schreiben.

Die geführte Erfahrung ist Kiro’s Hauptverkaufsargument. Anforderungen, Design und Aufgaben sind erstklassige UI-Objekte neben Ihrem Code, keine Dateien, die Sie über eine separate CLI verwalten. Kiro liefert auch Agent Hooks, ereignisgesteuerte Automatisierungen, die Tests, Docs oder verwandte Artefakte aktualisieren können, wenn sich die Implementierung ändert. Dieser bidirektionale Loop ist etwas, das Spec Kit nicht out-of-the-box bietet – Spec Kit Spezifikationen bleiben statisch, bis ein Mensch sie aktualisiert.

Die Kosten sind Integrationsiefe auf Kosten der Portabilität. Kiro läuft in seinem Editor, verwendet AWS Bedrock-gestützte Modelle und berechnet über ein kreditbasiertes Preismodell mit gestaffelten Plänen. Enterprise-Teams, die bereits auf AWS-Infrastruktur sind, finden das oft akzeptabel. Solo-Entwickler und Multi-Editor-Teams vielleicht nicht. Kiro hat auch die typischen Unregelmäßigkeiten einer neueren IDE – Erweiterungskompatibilität, Workflow-Überraschungen und die übliche Frage „Brauche ich wirklich noch einen Editor?".

Kiro passt zu Entwicklern, die die meist geführte SDD-Erfahrung wollen und bereit sind, eine spec-native IDE zu übernehmen. Es ist eine starke Option für Enterprise-Teams, AWS-lastige Umgebungen und alle, die von Amazon Q Developer migrieren und Spec-Discipline wollen, ohne die Toolchain manuell zusammenzustellen. Wenn Sie heute in standard VS Code leben und Ihr aktuelles Setup lieben, verlangt Kiro einen größeren Wechsel als Spec Kit.

Claude Code Custom Commands und Skills

Claude Code liefert kein einzelnes offizielles SDD-Produkt, wie Spec Kit oder Kiro es tun. Wenn Sie neu in dem Tool selbst sind, beginnen Sie mit dem Claude Code Installations- und Konfigurationsleitfaden für Setup, Berechtigungen und lokale Backends. Das SDD-Muster selbst lebt in benutzerdefinierten Commands, Skills und reponahen Markdown-Vorlagen, die Entwickler pflegen. Anthropic hat ältere .claude/commands/*.md-Dateien in den Skills-Mechanismus integriert, sodass das dauerhafte Muster eine SKILL.md (oder Äquivalent) ist, die Ihre specify-plan-implement-Checkliste definiert und auf Abruf geladen wird.

Dieser Ansatz ist der leichteste und am meisten hackable. Sie können ein Kiro-artiges Drei-File-Layout portieren, Spec Kit-Phasen mit Slash-Commands spiegeln oder einen minimalistischen Workflow erfinden, der zu einem Repository passt. Claude Code liest CLAUDE.md für immer aktiven Projekt-Kontext und zieht Skills, wenn die Aufgabe passt. Diese progressive Offenhaltung hält Sessions fokussiert, ohne eine vollständige Konstitution bei jedem Prompt zu laden.

Der Nachteil ist Disziplin. Nichts zwingt Sie durch Klärungs- oder Review-Gates, es sei denn, Sie bauen diese Gates selbst. Reddit- und Hacker News-Threads über „spec-driven development inside Claude Code" sind voll von Entwicklern, die jemandes Skill kopiert, ihn einmal ausgeführt und zurück zu unstrukturiertem Prompting gegangen sind, als der Skill sich langsam anfühlte. Claude Code SDD funktioniert, wenn Sie Skills wie Code behandeln – versioniert, überprüft und gepflegt – nicht wie einen einmaligen Prompt-Download.

Für eine ernsthafte Implementierung lesen Sie Claude Skills und SKILL.md für Entwickler und encodieren Sie Ihre Phasen als Skills mit expliziten Review-Checkpoints. Claude Code SDD ist die richtige Wahl, wenn Sie bereits in Claude Code leben, maximale Flexibilität wollen und den Workflow selbst pflegen werden.

BMAD, OpenSpec und andere Workflows

Nicht jedes Team möchte den Spec Kit-Artefaktbaum oder die Kiro IDE. Zwei Alternativen tauchen in Vergleichen 2026 ständig auf.

OpenSpec (Fission AI) nimmt einen change-zentrierten Ansatz mit weniger generierten Dateien als Spec Kit. Community-Benchmarks berichten von materiell geringerem Token-Verbrauch für vergleichbare Aufgaben, auf Kosten von weniger Vorab-Struktur. OpenSpec tendiert dazu zu gewinnen, wenn Sie ein bestehendes Codebase modifizieren und überprüfbare Spezifikationen ohne eine 800-Zeilen-Planungsphase wollen. Es konkurriert mit Spec Kit auf Portabilität mehr als mit Kiro auf IDE-Integration.

BMAD-METHOD (Community) drückt in die entgegengesetzte Richtung – Multi-Agent, rollenbasierte Workflows, die Produktbesitzer, Architekt, Entwickler und Reviewer-Personen simulieren. BMAD kann bei großen Greenfield-Bemühungen mächtig sein, wo explizite Rollentrennung hilft. Es ist auch schwer. Teams berichten häufig, dass sich die Zeremonie nur auszahlt, wenn Koordinations-Schmerz bereits akut ist.

Tessl behandelt die Spec als die wörtliche Quelle des generierten Codes, markiert Output als abgeleitet und discouragiert Hand-Edits. Das ist die stärkste „spec-as-source"-Position unter Mainstream-Tools, aber Tessl bleibt Beta und trägt den höchsten Produkt-Lock-in der Gruppe.

Spec Kitty und andere Community-Scaffolds sitzen zwischen OpenSpec und Spec Kit in Bezug auf Gewicht. Sie sind wertvoll zu beobachten, wenn Sie Vorlagen wollen, ohne die volle GitHub-Toolchain zu übernehmen.

Das Muster über all ihnen ist dasselbe. Mehr Prozess hilft, wenn Ambiguität teuer ist. Mehr Prozess schadet, wenn Feedback-Geschwindigkeit wichtiger ist als Ausrichtung. Passen Sie Tool-Gewicht an Task-Größe an, nicht an Hype.

Welches SDD-Setup sollten Sie verwenden?

Es gibt keinen universellen Gewinner. Das richtige Setup hängt davon ab, wer Sie sind, was Sie bauen und wie viel Struktur Sie tatsächlich pflegen werden.

Solo-Entwickler, bestehendes Codebase, kleine Features. Beginnen Sie mit Claude Code Skills oder OpenSpec. Schreiben Sie einen kurzen Anforderungsblock, eine minimale Aufgabenliste und einen Review-Checkpoint. Installieren Sie keinen vollständigen Spec Kit-Baum für eine fünfzig-Zeilen-Änderung.

Solo-Entwickler, Greenfield-Feature, multiple Sessions. Spec Kit oder ein gut gepflegter Claude Code SDD Skill. Sie benötigen dauerhafte Artefakte mehr als IDE-Hilfestellung.

Kleines Team, gemischte Editoren. Spec Kit. Reine Markdown-Spezifikationen in Git, überprüft in Pull Requests, ausgeführt von dem Agenten, den jeder Entwickler bevorzugt.

Enterprise-Team, AWS-nativ, Compliance-Druck. Kiro. Geführte Artefakte, Anforderungsrückverfolgbarkeit und Hooks, die Docs und Tests näher an die Implementierung halten.

Reguliertes Umfeld. Kiro oder Spec Kit plus Ihre eigene Validierungscheckliste – nicht nur Claude Code Skills, es sei denn, Sie codieren Compliance-Gates explizit. Tooling ersetzt keine Audit-Trails. Es macht sie nur einfacher zu produzieren.

Bestehendes Codebase, Brownfield-Änderung. OpenSpec oder ein leichtgewichtiger Claude Code-Workflow. Volle Spec Kit-Zeremonie bei jedem Bugfix wird sich wie Wasserfall anfühlen. Behalten Sie schwerere Struktur für cross-cutting-Features vor.

Greenfield-Produkt, viele Agenten. Spec Kit. Portabilität ist wichtiger als IDE-Polish, wenn Copilot, Claude Code und Cursor alle dasselbe Repo berühren können.

Teams, die mit Multi-Agent-Orchestrierung experimentieren, sollten sich auch Oh My OpenCode Agents ansehen, für Muster zur Aufteilung von Rollen über Agenten hinweg – ergänzend zu SDD-Artefakten, nicht als Ersatz dafür.

Praktische Entscheidungstabelle

Was tatsächlich den Erfolg bestimmt

Die Tool-Wahl ist weniger wichtig als die Artefaktqualität. Eine Kiro-Anforderungsdatei mit vagen Akzeptanzkriterien wird denselben Drift produzieren wie ein schlampiger Claude Code-Prompt. Ein Spec Kit-Plan, der fünfzig redundante Aufgaben auflistet, wird sich wie Wasserfall anfühlen, unabhängig davon, welcher Agent ihn implementiert.

Die Praktiken, die über jedes Setup hinweg tragen, sind langweilig und effektiv. Halten Sie Specs klein genug, um in einer Sitzung zu überprüfen. Schreiben Sie Nicht-Ziele explizit auf. Brechen Sie Aufgaben in Diffs auf, die ein Mensch lesen kann. Validieren Sie gegen Akzeptanzkriterien vor dem Merge. Aktualisieren Sie die Spec, wenn die Implementierung einen besseren Weg entdeckt.

Wenn Sie immer noch zwischen SDD und unstrukturiertem Prompting für ein gegebenes Feature wählen, lesen Sie Spec-Driven Development vs Vibe Coding. Der Tool-Vergleich in diesem Artikel ist nur relevant, sobald Sie entschieden haben, dass das Feature überhaupt eine Spec verdient.

Schlechte Specs machen jeden Agenten schlechter. Gute Specs sind über Tools hinweg tragbar.

Fazit

GitHub Spec Kit, Kiro und Claude Code-Workflows sind drei Antworten auf dieselbe Frage – wie halten Sie KI-Agenten über Sessions hinweg ausgerichtet – mit unterschiedlichen Wetten auf Portabilität versus Integration. Spec Kit optimiert für agentenagnostisches Markdown in Ihrem Repository. Kiro optimiert für eine geführte spec-native IDE mit AWS-gestützten Agenten. Claude Code Skills optimieren für hackable, leichtgewichtige Workflows, die nur gelingen, wenn Sie sie pflegen.

Wählen Sie das flachste Setup, das immer noch Ambiguität für das gegebene Feature entfernt. Fügen Sie Struktur hinzu, wenn Koordinations-Schmerz auftritt, nicht wenn ein Blog-Post es Ihnen sagt. Die Entwickler, die 2026 Wert aus SDD ziehen, sind nicht diejenigen mit der aufwendigsten Toolchain. Sie sind diejenigen, die Specs schreiben, die es wert sind, implementiert zu werden – und dann zulassen, dass welches Tool sie auch immer gewählt haben, gegen sie ausführt.

Nützliche Links

• GitHub Spec Kit Dokumentation – offizielle Spec Kit Workflow-Referenz
• Martin Fowler über SDD-Tools – Analyse von Kiro, Spec Kit und Tessl