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

Entwickler, die im Jahr 2026 Setups für spec-getriebene Entwicklung vergleichen, fragen in der Regel nicht nach dem klügsten Modell. Sie fragen sich, welcher Workflow einen KI-Agenten ausrichtet, ohne sie mit unnötigem Ballast zu überladen.

GitHub Spec Kit, AWS Kiro und die benutzerdefinierten Workflows von Claude Code implementieren alle dieselbe grobe Idee – Anforderungen, Design, Aufgaben, Implementierung, Validierung – sie unterscheiden sich jedoch in Portabilität, Integrationsiefe und dem Grad der erzwungenen Prozessstruktur.

Wenn Sie zunächst die Konzepte verstehen möchten, lesen Sie Was ist spec-getriebene Entwicklung? und den tool-unabhängigen Leitfaden zur Spec-getriebenen Entwicklungs-Workflow im Dokumentationscluster App-Architektur. Dieser Vergleich befindet sich im Hub für KI-Entwicklungstools neben Assistenten-Reviews und Workflow-Leitfäden.

SDD wird zu einer Tool-Kategorie

Spec-getriebene Entwicklung war irgendwann Ende 2025 mehr als nur ein theoretisches Übungsfeld. Jeder große Anbieter für KI-Coding liefert mittlerweile eine eigene Version des Muster Specify-Plan-Implement (Spezifizieren-Planen-Implementieren) aus, und eine wachsende Liste eigenständiger Tools konkurriert darin, wie viel Struktur sie um diesen Kreislauf legen.

Der Vergleich, der wirklich zählt, ist nicht „Welches Tool gewinnt?“, sondern Prozessiefe versus Portabilität. Kiro ist integriert. Spec Kit ist portabel. Claude-Code-Workflows sind modifizierbar. Schlechte Spezifikationen machen jeden Agenten schlechter, unabhängig davon, welche Hülle Sie wählen. Gute Spezifikationen funktionieren in jedem Tool.

Wie man SDD-Setups vergleicht

Bevor Sie ein Tool auswählen, benennen Sie, was Sie optimieren möchten. Dasselbe Feature kann in einem Setup mühelos wirken und in einem anderen bürokratisch, abhängig von der Teamgröße, dem Alter der Codebasis und dem benötigten Prüfmaße.

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 einen bestimmten IDE, eine Cloud oder ein proprietäres Format gebunden?

Einrichtungsreibungsverlust – Wie lang ist der Weg von „Ich möchte SDD ausprobieren" bis zu einem funktionierenden Specify-Plan-Tasks-Loop? CLI-Scaffolding, IDE-Installation oder das Do-it-yourself mit Slash-Commands haben alle unterschiedliche Aktivierungsenergie.

Qualität der Spezifikation – Hilft Ihnen das Tool, präzise Anforderungen und Akzeptanzkriterien zu schreiben, oder generiert es überwiegend lange Dokumente? Struktur ist nützlich. Umfang ist es nicht.

Aufgabenausführung – Wie teilt das Tool Arbeit in prüfbare_slices auf? Können Aufgaben parallel ausgeführt werden? Widersteht es Explosionen mit fünfzig Aufgabenpunkten?

Prüfstationen (Review Checkpoints) – Gibt es natürliche menschliche Kontrollpunkte zwischen Specify, Plan, Tasks und Implement? SDD ohne Review ist nur langsames „Vibe Coding".

Repository-Bezug – Liest der Workflow Projekt-Konventionen, Entscheidungsprotokolle, ADRs (Architecture Decision Records), AGENTS.md und den bestehenden Code, bevor geplant wird? Agenten ohne Bezug zur Realität erfinden die Architektur neu, weil sie die hinter früheren Entscheidungen stehende, geprüfte Absicht nie sehen.

Teamzusammenarbeit – Können mehrere Personen dieselben Spezifikations-Artefakte in Pull Requests prüfen? Kann man Agenten mischen, ohne den Prozess neu zu schreiben?

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

GitHub Spec Kit

GitHub Spec Kit ist eine Open-Source-CLI-Toolkit, das einen spec-getriebenen Loop in Ihr Repository skaliert und die Ausführung an den Coding-Agenten übergibt, den Sie bereits verwenden. Die specify-CLI installiert Templates, Slash-Commands und eine konventionelle Ordnerstruktur. Typische Befehle folgen einer Abfolge von Constitution-Specify-Clarify-Plan-Tasks-Implement (Verfassung-Spezifizieren-Präzisieren-Planen-Aufgaben-Implementieren), mit einem expliziten Schritt zur Präzisierung, um Mehrdeutigkeiten aufzulösen, bevor die Architekturarbeit beginnt.

Der definierende Vorteil von Spec Kit ist die Agenten-Unabhängigkeit. Die offiziellen Doku positionieren es als Tooling, das mit Claude Code, GitHub Copilot, Cursor, Gemini CLI, Codex und Dutzenden anderer Agenten funktioniert. Sie schreiben Spezifikationen einmal in Markdown, committen sie wie Code und wechseln den Ausführungs-Agenten, ohne den Prozess neu schreiben zu müssen. Das macht Spec Kit zur Standardempfehlung für Teams, die SDD möchten, ohne sich auf einen einzelnen Anbieter zu verlassen.

Die Kompromisse sind real. Spec Kit kann einen großen Artefakt-Baum erzeugen – Constitution, Spec, Plan, Tasks, Contracts –, was sich bei Features über mehrere Sitzungen hinweg lohnt, aber für eine kleine CLI-Anpassung schwerfällig wirkt. Threads auf Hacker News vergleichen diesen Overhead regelmäßig mit Wasserfall-Ritualen. Spec Kit ist zudem schwächer, wenn Sie eine vollständig integrierte IDE wünschen, in der Spezifikationen, Aufgaben und Implementierung in einer gesteuerten Oberfläche leben. Es legt Prozessstruktur über Ihren bestehenden Editor, anstatt diesen zu ersetzen.

Spec Kit eignet sich für Teams, die bereits einen bevorzugten KI-Coding-Assistenten haben und darüber ein standardisiertes SDD-Gerüst wollen. Besonders stark ist es bei Greenfield-Features, Multi-Agenten-Setups und für alle, die Editor-Lock-in ablehnen.

AWS Kiro

Kiro ist die spec-getriebene IDE von AWS, aufgebaut auf einer VS Code / Code-OSS-Fork. Wo Spec Kit SDD in Ihren bestehenden Stack bringt, setzt Kiro voraus, dass SDD eine eigens dafür gebaute Umgebung verdient. Ein Prompt erzeugt strukturierte Artefakte – typischerweise requirements.md in EARS-Notation (Easy-to-read and Simple), design.md und eine abhängeigkeitssequenzierte tasks.md – bevor Agenten Produktionscode schreiben.

Die gesteuerte Erfahrung ist Kiros 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, Doku oder verwandte Artefakte aktualisieren können, wenn sich die Implementierung ändert. Dieser bidirektionale Loop ist etwas, das Spec Kit nicht von Haus aus bereitstellt – Spec-Kit-Spezifikationen bleiben statisch, bis ein Mensch sie aktualisiert.

Die Kosten sind die Integrationstiefe, die für Portabilität getauscht wird. Kiro läuft in seinem eigenen Editor, nutzt AWS-Bedrock-unterstützte Modelle und rechnet über ein kreditbasiertes Preismodell mit gestuften Plänen ab. Enterprise-Teams, die bereits auf AWS-Infrastruktur sind, finden das oft akzeptabel. Einzelentwickler und Teams mit mehreren Editoren vielleicht nicht. Kiro hat auch rauer Kanten, typisch für eine neuere IDE – Erweiterungskompatibilität, Workflow-Überraschungen und die übliche Frage „Brauche ich wirklich noch einen Editor?“.

Kiro eignet sich für Entwickler, die die am meisten gesteuerte SDD-Erfahrung wollen und es akzeptieren, eine spec-native IDE zu übernehmen. Es ist eine starke Option für Enterprise-Teams, AWS-lastige Umgebungen und für alle, die von Amazon Q Developer migrieren und spec-Disziplin wollen, ohne die Toolchain manuell zusammenzustellen. Wenn Sie heute in Standard-VS Code leben und Ihre aktuelle Einrichtung lieben, verlangt Kiro einen größeren Wechsel als Spec Kit.

Claude Code: Benutzerdefinierte Commands und Skills

Claude Code liefert kein einzelnes offizielles SDD-Produkt auf die Art, wie es Spec Kit oder Kiro tun. Wenn Sie das Tool selbst neu sind, beginnen Sie mit dem Leitfaden zur Installation und Konfiguration von Claude Code für Setup, Berechtigungen und lokale Backends. Das SDD-Muster selbst lebt in benutzerdefinierten Commands, Skills und repository-lokale Markdown-Templates, die Entwickler pflegen. Anthropic hat ältere .claude/commands/*.md-Dateien in den Skills-Mechanismus eingegliedert, sodass das dauerhafte Muster eine SKILL.md (oder Äquivalentes) ist, die Ihre Specify-Plan-Implement-Checkliste definiert und bei Bedarf geladen wird.

Dieser Ansatz ist der leichteste und am besten modifizierbare. Sie können ein Kiro-Stil Drei-Datei-Layout portieren, Spec-Kit-Phasen mit Slash-Commands spiegeln oder einen minimalen Workflow erfinden, der zu einem einzigen Repository passt. Claude Code liest CLAUDE.md für dauerhaft aktiven Projekt-Kontext und ruft Skills ab, wenn die Aufgabe passt. Diese progressive Offenlegung hält Sitzungen fokussiert, ohne eine komplette Verfassung bei jedem Prompt zu laden.

Der Nachteil ist die Disziplin. Nichts zwingt Sie durch Präzisierungs- oder Prüfgates, außer Sie bauen diese Gates selbst. Threads auf Reddit und Hacker News über „spec-getriebene Entwicklung in Claude Code" sind voller Entwickler, die den Skill eines anderen kopiert haben, ihn einmal ausgeführt und beim unstrukturierten Prompting zurückgekehrt sind, als der Skill sich langsam anfühlte. Claude-Code-SDD funktioniert, wenn Sie Skills wie Code behandeln – versioniert, geprüft und gepflegt – und nicht wie einen Einmal-Prompt-Download.

Für eine ernsthafte Implementierung lesen Sie Claude Skills und SKILL.md für Entwickler und coden Sie Ihre Phasen als Skills mit expliziten Prüfpunkten. Claude-Code-SDD ist die richtige Wahl, wenn Sie bereits in Claude Code leben, maximale Flexibilität wollen und den Workflow selbst pflegen werden. Für den speziellen Schritt der Prüfung kann Claude Code Subagenten einen unabhängigen Review-Durchlauf in isoliertem Kontext auf generiertem Code durchführen, bevor Sie eine Aufgabe mergen – ein leichtgewichtiger Ersatz für die Validierungsrolle, die Kiros Agent Hooks nativ bereitstellen.

Superpowers: Eine paketierte Version des DIY-Skill-Stacks

Wenn es sich anfühlt, genau dieses Disziplinproblem zu sein, vor dem die obige Tabelle warnt, lohnt sich ein Blick auf Superpowers. 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 – vertrieben als installierbares Plugin, statt etwas, das Sie von Grund auf schreiben. Es zielt direkt auf die Einschränkung „Qualität hängt vollständig von der Disziplin des Autors ab": Die Skills werden automatisch ausgelöst und sollen obligatorischer Workflow sein, keine optionalen Vorschläge, die der Agent überspringen kann.

Der erzwungene Workflow bildet eng den in Spec-Driven Development Workflow From Requirements to Code behandelten Fünf-Phasen-Loop ab: Brainstorming verfeinert eine grobe Idee in ein geprüftes Design-Dokument, writing-plans teilt es in kleine, überprüfbare Aufgaben auf, subagent-driven-development dispatcht frische Subagenten pro Aufgabe mit zweistufiger Prüfung und test-driven-development erzwingt strenges Red-Green-Refactor, bevor etwas als fertig gilt. Dieser letzte Teil ist strenger, als die meisten Claude-Code-SDD-Skills es sein – Superpowers löscht explizit Code, der vor dem Existieren eines fehlernden Tests 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 Methodik Sie über verschiedene Harness hinweg begleitet, anstatt in einem einzigen .claude/skills/-Ordner zu leben. Das macht es zu einem Mittelweg zwischen dem Selbstbau eines Claude-Code-Skills und der Adoption eines schwereren, IDE-spezifischen Tools wie Kiro: Sie erhalten einen meinungsstarken, erzwungenen Loop, ohne Ihren Editor aufzugeben oder sich an das Spezifikationsformat eines einzelnen Anbieters zu binden.

Superpowers eignet sich für Entwickler, die dem Prinzip der Claude-Code-Skills zustimmen, aber ständig zum unstrukturierten Prompting zurückgleiten, weil nichts die Prüfgate erzwingt. Es ist eine schwächere Passform, wenn Sie bereits einen projektspezifischen SDD-Skill haben, der auf Ihren Stack abgestimmt ist – in dem Fall tauschen Sie eine kleine Menge Anpassungsfähigkeit gegen eine größere Menge erzwungener Formalismus ein.

BMAD, OpenSpec und andere Workflows

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

OpenSpec (Fission AI) nimmt einen änderungsorientierten Ansatz mit weniger generierten Dateien als Spec Kit. Community-Benchmarks berichten von substantiell geringerem Token-Verbrauch für vergleichbare Aufgaben, zum Preis von weniger Vorab-Struktur. OpenSpec neigt dazu zu gewinnen, wenn Sie eine bestehende Codebasis modifizieren und prüfbare Spezifikationen ohne eine 800-Zeilen-Planungsphase wollen. Es konkurriert mit Spec Kit mehr in der Portabilität als mit Kiro in der IDE-Integration. Siehe den OpenSpec Quickstart für die Installationsschritte, den Explore-Propose-Apply-Archive-Loop und die Fallstricke, die auf Reddit am häufigsten auftauchen.

BMAD-METHOD (Community) drückt in die entgegengesetzte Richtung – Multi-Agenten, rollenbasierte Workflows, die Personas wie Product Owner, Architekt, Entwickler und Reviewer simulieren. BMAD kann bei großen Greenfield-Vorhaben leistungsfähig sein, wo explizite Rollentrennung hilft. Es ist auch schwerfällig. Teams berichten häufig, dass sich die Formalität nur dann lohnt, wenn Koordinationsprobleme bereits akuten Charakter haben.

Tessl betrachtet die Spezifikation als die wörtliche Quelle des generierten Codes, markiert Ausgaben als abgeleitet und rät von Handkorrekturen ab. Das ist die stärkste „Spec-as-Source"-Haltung unter den Mainstream-Tools, aber Tessl bleibt in der Beta-Phase und trägt den höchsten Produkt-Lock-in der Gruppe.

Spec Kitty und andere Community-Scaffolds liegen im Gewicht zwischen OpenSpec und Spec Kit. Sie sind es wert, beobachtet zu werden, wenn Sie Templates wollen, ohne die vollständige GitHub-Toolchain zu übernehmen.

Das Muster hinter ihnen allen ist dasselbe. Mehr Prozess hilft, wenn Mehrdeutigkeit teuer ist. Mehr Prozess schadet, wenn Feedbackgeschwindigkeit wichtiger ist als Ausrichtung. Passen Sie das Gewicht des Tools zur Größe der Aufgabe, nicht zum 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.

Einzelentwickler, bestehende Codebasis, kleine Features. Beginnen Sie mit Claude-Code-Skills oder OpenSpec. Schreiben Sie einen kurzen Anforderungsblock, eine minimale Aufgabenliste und einen Prüfpunkt. Installieren Sie keinen kompletten Spec-Kit-Baum für eine Fünfzig-Zeilen-Änderung.

Möchten den Claude-Code-Skills-Ansatz, springen aber ständig über Ihre eigenen Prüfgate. Installieren Sie stattdessen Superpowers, anstatt einen benutzerdefinierten Skill von Grund auf zu schreiben. Sie geben etwas projektspezifische Abstimmung auf, im Austausch für einen erzwungenen Brainstorm-Plan-Implement-Review-Loop, der nicht von Ihrer Tagesdisziplin abhängt.

Einzelentwickler, Greenfield-Feature, mehrere Sitzungen. Spec Kit oder ein gut gepflegter Claude-Code-SDD-Skill. Sie benötigen dauerhafte Artefakte mehr als IDE-Helferhand.

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

Enterprise-Team, AWS-nativ, Compliance-Druck. Kiro. Gesteuerte Artefakte, Anforderungsnachverfolgbarkeit und Hooks, die Doku und Tests näher an die Implementierung halten.

Regulierte Umgebung. Kiro oder Spec Kit plus Ihrer eigenen Validierungs-Checkliste – nicht nur Claude-Code-Skills, es sei denn, Sie coden Compliance-Gates explizit ein. Tooling ersetzt keine Audit-Trails. Es macht sie nur einfacher zu produzieren.

Bestehende Codebasis, Brownfield-Änderung. OpenSpec oder ein leichtgewichtiger Claude-Code-Workflow. Die vollständige Spec-Kit-Formalität bei jedem Bugfix wird sich wie Wasserfall anfühlen. Halten Sie schwerere Struktur für durchgreifende Features zurück.

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

Teams, die Multi-Agenten-Orchestrierung experimentieren, sollten auch einen Blick auf Oh My OpenCode Agents werfen für Muster, Rollen über Agenten hinweg aufzuteilen – ergänzend zu SDD-Artefakten, kein Ersatz dafür. Wenn Ihr Team einen terminal-first Agenten anstelle eines IDE-integrierten läuft, zeigt der Praktische Leitfaden für die OpenCode-CLI die leichtere, prompt-basierte Version derselben Plan-before-Implement-Disziplin – nützlich, wenn ein kompletter Spec-Kit-Baum mehr Formalismus ist, als die Aufgabe rechtfertigt.

Praktische Entscheidungstabelle

Was eigentlich Erfolg bestimmt

Die Toolwahl ist weniger wichtig als die Qualität der Artefakte. Eine Kiros-Anforderungsdatei mit vagen Akzeptanzkriterien wird dieselbe 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 in jedem Setup funktionieren, sind langweilig und wirksam. Halten Sie Spezifikationen klein genug, um sie in einer Sitzung zu prüfen. Schreiben Sie Nicht-Ziele (Non-Goals) explizit auf. Brechen Sie Aufgaben in Diffs auf, 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 für ein bestimmtes Feature immer noch zwischen SDD und unstrukturiertem Prompting wählen, lesen Sie Spec-Driven Development vs Vibe Coding. Der Toolvergleich in diesem Artikel wird erst dann relevant, wenn Sie entschieden haben, dass das Feature überhaupt eine Spezifikation verdient.

Schlechte Spezifikationen machen jeden Agenten schlechter. Gute Spezifikationen funktionieren in jedem Tool.

Fazit

GitHub Spec Kit, Kiro und Claude-Code-Workflows sind drei Antworten auf dieselbe Frage – wie halten Sie KI-Agenten über Sitzungen hinweg ausgerichtet – mit verschiedenen Wetten auf Portabilität versus Integration. Spec Kit optimiert für agenten-unabhängiges Markdown in Ihrem Repository. Kiro optimiert für eine gesteuerte, spec-native IDE mit AWS-gestützten Agenten. Claude-Code-Skills optimieren für modifizierbare, leichtgewichtige Workflows, die nur dann erfolgreich sind, wenn Sie sie pflegen.

Wählen Sie das flachste Setup, das die Mehrdeutigkeit für das jeweilige Feature entfernt. Fügen Sie Struktur hinzu, wenn Koordinationsprobleme auftauchen, und nicht, wenn ein Blog-Post es Ihnen sagt. Die Entwickler, die 2026 Wert aus SDD ziehen, sind nicht die mit der aufwendigsten Toolchain. Sie sind die, die Spezifikationen schreiben, die es wert sind, implementiert zu werden – und dann lassen sie das Tool, das sie gewählt haben, dagegen ausführen.

Nützliche Links

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