GitHub Spec Kit im Vergleich zu Kiro und Claude Code SDD-Workflows

Entwickler, die im Jahr 2026 Setups für die spec-getriebene Entwicklung (Spec-Driven Development, SDD) vergleichen, fragen in der Regel nicht, welches Modell am intelligentesten ist. Sie fragen, welcher Workflow einen KI-Agenten ausrichtet, ohne sie unter einer Flut an Formalitäten zu begraben.

GitHub Spec Kit, AWS Kiro und benutzerdefinierte Workflows von Claude Code implementieren alle dieselbe breite Idee – Anforderungen, Design, Aufgaben, Implementierung, Validierung – unterscheiden sich jedoch in ihrer Portabilität, Integrationstiefe und dem Umfang der erzwungenen Prozesse.

Wenn Sie zuerst die Konzepte benötigen, lesen Sie Was ist spec-getriebene Entwicklung? und die werkzeugunabhängige Spec-Driven Development Workflow-Leitfaden im App Architecture-Dokumentationscluster. Dieser Vergleich befindet sich im AI Developer Tools-Hub neben Assistenten-Reviews und Workflow-Leitfäden.

SDD wird zu einer Werkzeugkategorie

Die spec-getriebene Entwicklung hat irgendwann Ende 2025 aufgehört, nur noch eine theoretische Übung zu sein. Jeder große Anbieter von KI-Coding-Tools liefert inzwischen eine Version des specify-plan-implement-Zyklus aus, und eine wachsende Liste von Standalone-Werkzeugen konkurriert darum, wie viel Struktur sie um diesen Zyklus herum hinzufügen.

Der Vergleich, der zählt, ist nicht „welches Werkzeug gewinnt“. Es ist Prozess-Tiefe versus Portabilität. Kiro ist integriert. Spec Kit ist portabel. Claude-Code-Workflows sind hackbar. Schlechte Spezifikationen machen jeden Agenten schlechter, unabhängig davon, welche Hülle Sie wählen. Gute Spezifikationen funktionieren über Werkzeuge hinweg.

Wie man SDD-Setups vergleicht

Bevor Sie ein Werkzeug wählen, benennen Sie, worauf Sie optimieren. Dasselbe Feature kann in einem Setup mühelos wirken und in einem anderen bürokratisch, abhängig von der Teamgröße, dem Alter des Codebasises und dem benötigten Review-Aufwand.

Portabilität – Können die Spezifikationen als normales 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 von „Ich möchte SDD ausprobieren“ bis zu einem funktionierenden specify-plan-tasks-Zyklus? CLI-Scaffolding, IDE-Installation oder das eigene Erstellen von Slash-Commands haben alle unterschiedliche Aktivierungsenergien.

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

Aufgabenausführung – Wie zerlegt das Werkzeug die Arbeit in überprüfbare Schnitte? Können Aufgaben parallel ausgeführt werden? Widersteht es Explosionen von fünfzigpunktigen Aufgabenlisten?

Review-Checkpoints – Gibt es natürliche menschliche Schwellen zwischen specify, plan, tasks und implement? SDD ohne Review ist nur langsameres Vibe Coding.

Repository-Verankerung – Liest der Workflow Projekt-Konventionen, Entscheidungsprotokolle, ADRs, AGENTS.md und vorhandenen Code, bevor er plant? Agenten ohne Verankerung erfinden die Architektur neu, weil sie die hinter früheren Entscheidungen stehende, geprüfte Absicht nie sehen.

Team-Kollaboration – Können mehrere Personen dieselben Spezifikations-Artefakte in Pull Requests überprüfen? Können Sie Agenten mischen, ohne den Prozess umzuschreiben?

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

GitHub Spec Kit

GitHub Spec Kit ist ein Open-Source-CLI-Toolkit, das einen spec-getriebenen Zyklus in Ihr Repository scaffoldet und die Ausführung an den Coding-Agenten übergibt, den Sie bereits verwenden. Die specify-CLI legt Vorlagen, Slash-Commands und eine konventionelle Ordnerstruktur an. Typische Befolge folgen einer constitution-specify-clarify-plan-tasks-implement-Sequenz, mit einem expliziten clarify-Schritt, um Mehrdeutigkeiten zu klären, bevor die Architekturarbeit beginnt.

Der entscheidende Vorteil von Spec Kit ist die Agenten-Unabhängigkeit. Die offiziellen Dokumente 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 wechseln den Ausführer, ohne den Prozess umzuschreiben. Das macht Spec Kit zur Standardempfehlung für Teams, die SDD wollen, ohne auf einen einzelnen Anbieter zu wetten.

Die Nachteile sind real. Spec Kit kann einen großen Artefaktbaum erzeugen – constitution, spec, plan, tasks, contracts –, was sich bei Multi-Session-Features auszahlt, aber für eine kleine CLI-Anpassung schwerfällig wirkt. Hacker News-Threads vergleichen diesen Overhead regelmäßig mit Waterfall-Zeremonien. Spec Kit ist auch schwächer, wenn Sie eine vollständig integrierte IDE wünschen, in der Spezifikationen, Aufgaben und Implementierung auf einer geführten Oberfläche leben. Es legt Prozesse über Ihren vorhandenen Editor, anstatt ihn zu ersetzen.

Spec Kit passt zu Teams, die bereits einen bevorzugten KI-Coding-Assistenten haben und darauf ein standardisiertes SDD-Scaffold wünschen. Es ist besonders stark für Greenfield-Features, Multi-Agenten-Shops und alle, die Editor-Lock-in ablehnen.

AWS Kiro

Kiro ist AWS’ spec-getriebene IDE, basierend auf einer VS Code / Code OSS Fork. Während Spec Kit SDD in Ihren vorhandenen Stack bringt, geht Kiro davon aus, dass SDD eine eigens dafür gebaute Umgebung verdient. Ein Prompt erzeugt strukturierte Artefakte – typischerweise requirements.md in EARS-Notation, design.md und eine abhängigkeitssequenzierte 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, Dokumente oder verwandte Artefakte aktualisieren können, wenn sich die Implementierung ändert. Dieser bidirektionale Zyklus ist etwas, das Spec Kit nicht aus der Schachtel bietet – Spec-Kit-Spezifikationen bleiben statisch, bis ein Mensch sie aktualisiert.

Die Kosten sind Integrationstiefe gegen Portabilität. Kiro läuft in seinem Editor, verwendet AWS-Bedrock-unterstü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 raue Kanten, typisch für eine neuere IDE – Erweiterungskompatibilität, Workflow-Überraschungen und die übliche Frage „Brauche ich wirklich noch einen Editor?“.

Kiro passt zu Entwicklern, die die am stärksten geführte SDD-Erfahrung wollen und sich damit wohlfühlen, eine spec-native IDE zu adoptieren. Es ist eine starke Option für Enterprise-Teams, AWS-lastige Umgebungen und alle, die von Amazon Q Developer migrieren und Spec-Disziplin wollen, ohne die Werkzeugkette 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 aus, wie es Spec Kit oder Kiro tun. Wenn Sie neu im Werkzeug selbst sind, beginnen Sie mit dem Claude Code Install- und Konfigurationsleitfaden für Setup, Berechtigungen und lokale Backends. Das SDD-Muster selbst lebt in Custom Commands, Skills und Repository-lokalen Markdown-Vorlagen, die Entwickler pflegen. Anthropic hat ältere .claude/commands/*.md-Dateien in den Skills-Mechanismus eingegliedert, sodass das dauerhafte Muster eine SKILL.md (oder Äquivalent) ist, die Ihre specify-plan-implement-Checkliste definiert und bei Bedarf geladen wird.

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

Der Nachteil ist Disziplin. Nichts zwingt Sie durch clarify- oder review-Schwellen, es sei denn, Sie bauen diese Schwellen selbst. Reddit- und Hacker-News-Threads über „spec-getriebene Entwicklung in Claude Code“ sind voller Entwickler, die jemand anderes’ Skill kopiert, ihn einmal ausgeführt und zum unstrukturierten Prompting zurückgekehrt sind, als der Skill langsam wirkte. Claude-Code-SDD funktioniert, wenn Sie Skills wie Code behandeln – versioniert, geprüfter und gewartet – und nicht wie einen einmaligen Prompt-Download.

Für eine ernsthafte Implementierung lesen Sie Claude Skills und SKILL.md für Entwickler und kodieren 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 wünschen und den Workflow selbst pflegen werden. Für den Review-Gate-Schritt speziell können Claude Code Subagents einen unabhängigen Review-Pass mit isoliertem Kontext auf generierten Code ausführen, bevor Sie eine Aufgabe mergen – ein leichtgewichtiger Ersatz für die Verifikationsrolle, die Kiro’s Agent Hooks nativ bereitstellen.

Superpowers: Eine paketierte Version des DIY-Skill-Stacks

Wenn das Handrollen dieses Skill-Stacks genau das Disziplinproblem zu sein scheint, vor dem die obige Tabelle warnt, ist Superpowers einen Blick wert. Es ist ein Open-Source-Skills-Paket – Brainstorming, writing-plans, subagent-driven-development, test-driven-development, requesting-code-review und eine Handvoll unterstützender Skills – das als installierbares Plugin distribuiert wird, statt etwas, das Sie von Grund auf schreiben. Es zielt direkt auf die Einschränkung „Qualität hängt vollständig von der Autoren-Disziplin ab“ ab: Die Skills werden automatisch ausgelöst und sollen ein verpflichtender Workflow sein, keine optionalen Vorschläge, die der Agent überspringen kann.

Der erzwungene Workflow entspricht eng dem in Spec-Driven Development Workflow Von den Anforderungen zum Code beschriebenen Fünf-Phasen-Zyklus: Brainstorming verfeinert eine grobe Idee zu einem geprüften Design-Dokument, writing-plans zerlegt es in kleine überprüfbare Aufgaben, subagent-driven-development dispatcht einen frischen Subagenten pro Aufgabe mit einer zweistufigen Prüfung, und test-driven-development erzwingt striktes Red-Green-Refactor, bevor etwas als erledigt gilt. Dieser letzte Teil ist strenger, als die meisten Claude-Code-SDD-Skills es sich anmaßen – Superpowers löscht explizit Code, der vor der Existenz eines fehlschlagenden Tests dafür geschrieben wurde.

Im Gegensatz zu einem Repository-lokalen Skill, den Sie selbst schreiben, ist Superpowers nicht nur für Claude Code. Es liefert Plugin-Manifeste für Claude Code, Cursor, Codex, Gemini CLI, GitHub Copilot CLI, Devin, Factory Droid und mehrere andere Agenten, sodass dieselbe Methodologie Sie über Harness hinweg begleitet, statt in einem einzelnen .claude/skills/-Ordner zu leben. Das macht es zu einem Mittelweg zwischen dem eigenen Erstellen eines Claude-Code-Skills und der Adoption eines schwereren, IDE-spezifischen Werkzeugs wie Kiro: Sie bekommen einen meinungsstarken, erzwungenen Zyklus, ohne Ihren Editor aufzugeben oder sich an ein einzelnes Anbieter-Spec-Format zu binden.

Superpowers passt zu Entwicklern, die den Claude-Code-Skills-Ansatz im Prinzip mögen, aber immer wieder zum unstrukturierten Prompting zurückrutschen, weil nichts die Review-Schwellen erzwingt. Es ist eine schwächere Passform, wenn Sie bereits einen projekt-spezifischen SDD-Skill haben, der auf Ihren Stack abgestimmt ist – in dem Fall tauschen Sie eine kleine Menge an Anpassung gegen eine größere Menge an erzwungener Zeremonie.

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 änderungsorientierten Ansatz mit weniger generierten Dateien als Spec Kit. Community-Benchmarks berichten von materiell geringerem Token-Verbrauch für vergleichbare Aufgaben, auf Kosten von weniger Vorstruktur. OpenSpec neigt dazu zu gewinnen, wenn Sie eine bestehende Codebasis ändern und überprüfbare Spezifikationen ohne eine 800-Zeilen-Planungsphase wollen. Es konkurriert mit Spec Kit eher in der Portabilität als mit Kiro in der IDE-Integration.

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

Tessl behandelt die Spezifikation als die buchstäbliche Quelle des generierten Codes, markiert die Ausgabe als abgeleitet und rät von Hand-Edits ab. Das ist die stärkste „Spec-as-Source“-Position unter den Mainstream-Tools, aber Tessl bleibt in der Beta und trägt die höchste Produkt-Abhängigkeit der Gruppe.

Spec Kitty und andere Community-Scaffolds liegen in der Schwere zwischen OpenSpec und Spec Kit. Sie sind einen Blick wert, wenn Sie Vorlagen wollen, ohne die vollständige GitHub-Werkzeugkette zu adoptieren.

Das Muster über all diese hinweg ist dasselbe. Mehr Prozess hilft, wenn Mehrdeutigkeit teuer ist. Mehr Prozess schadet, wenn Feedbackgeschwindigkeit wichtiger ist als Ausrichtung. Passen Sie das Gewicht des Werkzeugs an die Größe der Aufgabe an, nicht an den 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, bestehende Codebasis, kleine Features. Beginnen Sie mit Claude-Code-Skills oder OpenSpec. Schreiben Sie einen kurzen Anforderungen-Block, eine minimale Aufgabenliste und einen Review-Checkpoint. Installieren Sie keinen vollständigen Spec-Kit-Baum für eine fünfzigzeilige Änderung.

Möchten den Claude-Code-Skills-Ansatz, aber springen Ihre eigenen Review-Schwellen ständig über. Installieren Sie Superpowers, anstatt einen Custom Skill von Grund auf zu schreiben. Sie geben etwas projekt-spezifisches Tuning auf, im Tausch gegen einen erzwungenen Brainstorm-Plan-Implement-Review-Zyklus, der nicht von Ihrer Disziplin an diesem Tag abhängt.

Solo-Entwickler, Greenfield-Feature, mehrere Sitzungen. Spec Kit oder ein gut gepflegter Claude-Code-SDD-Skill. Sie brauchen dauerhafte Artefakte mehr als IDE-Halterung.

Kleines Team, gemischte Editoren. Spec Kit. Normale Markdown-Spezifikationen in Git, in Pull Requests geprüft, ausgeführt von welchem Agenten auch immer jeder Entwickler bevorzugt.

Enterprise-Team, AWS-nativ, Compliance-Druck. Kiro. Geführte Artefakte, Anforderungs-Nachverfolgbarkeit und Hooks, die Dokumente und Tests näher an der Implementierung halten.

Reguliertes Umfeld. Kiro oder Spec Kit plus Ihrer eigenen Validierungs-Checkliste – nicht nur Claude-Code-Skills, es sei denn, Sie kodieren Compliance-Schwellen explizit. Tooling ersetzt keine Audit-Trails. Es macht sie nur leichter zu erzeugen.

Bestehende Codebasis, Brownfield-Änderung. OpenSpec oder ein leichtgewichtiger Claude-Code-Workflow. Volle Spec-Kit-Zeremonie bei jedem Bugfix wird sich wie Waterfall anfühlen. Reservieren Sie schwerere Struktur für Querschnitts-Features.

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

Teams, die mit Multi-Agenten-Orchestrierung experimentieren, sollten auch einen Blick auf Oh My OpenCode Agents werfen, für Muster zum Aufteilen von Rollen über Agenten hinweg – komplementär zu SDD-Artefakten, kein Ersatz für sie.

Praktische Entscheidungstabelle

Was den Erfolg tatsächlich bestimmt

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

Die Praktiken, die über jedes Setup hinweg funktionieren, sind langweilig und effektiv. Halten Sie Spezifikationen klein genug, um sie in einer Sitzung zu prüfen. Schreiben Sie Nicht-Ziele explizit. Zerlegen Sie Aufgaben in Diffs, die ein Mensch lesen kann. Validieren Sie gegen Akzeptanzkriterien vor dem Merge. Aktualisieren Sie die Spezifikation, 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 Werkzeugvergleich in diesem Artikel ist nur relevant, wenn Sie entschieden haben, dass das Feature überhaupt eine Spezifikation verdient.

Schlechte Spezifikationen machen jeden Agenten schlechter. Gute Spezifikationen funktionieren über Werkzeuge hinweg.

Fazit

GitHub Spec Kit, Kiro und Claude-Code-Workflows sind drei Antworten auf dieselbe Frage – wie hält man KI-Agenten über Sitzungen hinweg ausgerichtet – mit unterschiedlichen Wetten auf Portabilität versus Integration. Spec Kit optimiert für agenten-agnostisches Markdown in Ihrem Repository. Kiro optimiert für eine geführte spec-native IDE mit AWS-unterstützten Agenten. Claude-Code-Skills optimieren für hackbare, leichtgewichtige Workflows, die nur erfolgreich sind, wenn Sie sie pflegen.

Wählen Sie das flachste Setup, das immer noch die Mehrdeutigkeit für das vorliegende Feature entfernt. Fügen Sie Struktur hinzu, wenn Koordinations-Schmerz auftritt, nicht wenn ein Blogpost es Ihnen sagt. Die Entwickler, die 2026 Wert aus SDD ziehen, sind nicht die mit der aufwendigsten Werkzeugkette. Es sind die, die Spezifikationen schreiben, die es wert sind, implementiert zu werden – und dann dem Werkzeug, das sie gewählt haben, erlauben, dagegen auszuführen.

Nützliche Links

• GitHub Spec Kit Dokumentation – offizielle Spec-Kit-Workflow-Referenz
• Superpowers Quickstart: Installation, Workflow und Test – Open-Source-Skills-Paket, das eine Brainstorming-zu-TDD-Methodologie über Claude Code, Cursor, Codex und andere Agenten hinweg durchsetzt
• Martin Fowler über SDD-Tools – Analyse von Kiro, Spec Kit und Tessl