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

Entwickler, die sich im Jahr 2026 mit verschiedenen Spec-Driven-Development-Setups (SDD) vertraut machen, fragen in der Regel nicht danach, welches KI-Modell am intelligentsten ist. Sie fragen sich, welcher Workflow einen KI-Agenten ausgerichtet halten wird, ohne sie unter einer Flut an Formalitäten zu begraben.

GitHub Spec Kit, AWS Kiro und benutzerdefinierte Workflows von Claude Code implementieren alle dieselbe Grundidee – Anforderungen, Design, Aufgaben, Implementierung, Validierung – unterscheiden sich aber in Sachen Portabilität, Integrationsstufe und dem Umfang, in dem sie Prozesse erzwingen.

Wenn Sie zunächst die Konzepte verstehen möchten, lesen Sie Was ist Spec-Driven Development? und die werksneutralen Leitfaden Spec-Driven-Development-Workflow in der Doku-Cluster-Sektion App-Architektur. Dieser Vergleich befindet sich im Hub für KI-Entwickler-Tools neben Assistenten-Tests und Workflow-Leitfäden.

SDD wird zu einer Werkzeugkategorie

Spec-Driven Development war Ende 2025 keine rein theoretische Übung mehr. Jeder große Anbieter für KI-Coding liefert mittlerweile eine Version des specify-plan-implement-Zyklus aus, und eine wachsende Liste von eigenständigen Tools konkurriert darüber, wie viel Struktur sie um diesen Zyklus herum hinzufügen.

Der Vergleich, der wirklich zählt, ist nicht „welches Tool gewinnt“. Es geht um 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 verschiedene Tools hinweg.

Wie man SDD-Setups vergleicht

Bevor Sie ein Tool auswählen, benennen Sie, worauf Sie optimiert sind. Dasselbe Feature kann in einer Umgebung mühelos sein und in einer anderen bürokratisch wirken, je nach Teamgröße, Alter des Codebases und dem Umfang, in dem Sie Reviews benötigen.

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

Einrichtungsreibung – Wie lange dauert es von „Ich möchte SDD ausprobieren“ bis zu einem funktionierenden specify-plan-tasks-Zyklus? CLI-Gerüste, IDE-Installationen oder das Erstellen eigener Slash-Commands haben alle unterschiedliche Aktivierungsenergien.

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

Aufgabenausführung – Wie unterteilt das Tool die Arbeit in überprüfbare Schnitte? Können Aufgaben parallel ausgeführt werden? Widersteht es Explosionen von Fünfzig-Punkte-Aufgabenlisten?

Prüfpunkte (Review-Checkpoints) – Gibt es natürliche menschliche Kontrollgitter zwischen Specify, Plan, Tasks und Implement? SDD ohne Reviews ist nur langsames Vibe Coding.

Bezug zum Repository (Grounding) – Liest der Workflow die Projektkonventionen, Entscheidungsprotokolle, ADRs, AGENTS.md und den vorhandenen Code, bevor er plant? Agenten ohne Bezugspunkte erfinden die Architektur neu, weil sie die hinter vergangenen Entscheidungen stehende, geprüfte Intention 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 den Editor, das Modell oder den Cloud-Anbieter wechseln?

GitHub Spec Kit

GitHub Spec Kit ist ein Open-Source-CLI-Toolkit, das einen spec-gesteuerten Zyklus in Ihr Repository gerüstet (scaffolded) 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 Befehle folgen einer constitution-specify-clarify-plan-tasks-implement-Sequenz, wobei es einen expliziten clarify-Schritt gibt, um Mehrdeutigkeiten zu klären, bevor die Architekturentscheidungen beginnen.

Der definierende Vorteil von Spec Kit ist die Agenten-Unabhängigkeit. Die offiziellen Dokumente positionieren es als Werkzeug, 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ührenden, ohne den Prozess neu zu schreiben. Das macht Spec Kit zur Standardempfehlung für Teams, die SDD ohne Wette auf einen einzelnen Anbieter wollen.

Die Kompromisse sind real. Spec Kit kann einen großen Artefaktbaum erzeugen – constitution, spec, plan, tasks, contracts –, was sich bei Features über mehrere Sitzungen lohnt, aber für eine kleine CLI-Anpassung schwer wiegen kann. Threads auf Hacker News vergleichen diesen Overhead regelmäßig mit Waterfall-Zeremonien. Spec Kit ist auch schwächer, wenn Sie eine vollintegrierte IDE wünschen, in der Spezifikationen, Aufgaben und Implementierung auf einer einzigen geführten Oberfläche leben. Es legt den Prozess über Ihren bestehenden Editor statt ihn zu ersetzen.

Spec Kit passt zu Teams, die bereits einen bevorzugten KI-Coding-Assistenten haben und ein standardisiertes SDD-Gerüst darüber 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-gesteuerte IDE, gebaut auf einer VS Code / Code-OSS-Fork. Während Spec Kit SDD in Ihren bestehenden Stack bringt, geht Kiro davon aus, dass SDD eine eigens gebaute Umgebung verdient. Ein Prompt generiert strukturierte Artefakte – typischerweise requirements.md in EARS-Notation, design.md und eine abhängigkeiten-sequenzierte tasks.md –, bevor die Agenten Produktionscode schreiben.

Die geführte Erfahrung ist Kiros Hauptverkaufsargument. Anforderungen, Design und Aufgaben sind erste-klassige UI-Objekte neben Ihrem Code, keine Dateien, die Sie über eine separate CLI verwalten. Kiro bietet auch Agent Hooks, ereignisgesteuerte Automatisierungen, die Tests, Doku oder verwandte Artefakte aktualisieren können, wenn sich die Implementierung ändert. Dieser bidirektionale Zyklus ist etwas, das Spec Kit standardmäßig nicht bereitstellt – Spec-Kit-Spezifikationen bleiben statisch, bis ein Mensch sie aktualisiert.

Die Kosten sind die Integrationstiefe, die gegen Portabilität eingetauscht wird. Kiro läuft innerhalb seines Editors, verwendet auf AWS Bedrock basierende Modelle und stellt über ein kreditbasiertes Preismodell mit gestuften Plänen in Rechnung. Enterprise-Teams, die bereits auf AWS-Infrastruktur laufen, finden das oft akzeptabel. Solo-Entwickler und Teams mit mehreren Editoren vielleicht nicht. Kiro hat auch die rauen Kanten, die für eine neuere IDE typisch sind – Erweiterungskompatibilität, Workflow-Überraschungen und die übliche Frage „Brauche ich wirklich noch einen weiteren Editor?“.

Kiro passt zu Entwicklern, die die am stärksten geführte SDD-Erfahrung wollen und damit leben können, 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-Disziplin wollen, ohne das Tool-Chain 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 auf dieselbe Weise wie Spec Kit oder Kiro. Wenn Sie neu im Tool selbst 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 Custom Commands, Skills und lokalen Markdown-Vorlagen im Repository, die Entwickler pflegen. Anthropic hat ältere .claude/commands/*.md-Dateien in den Skills-Mechanismus eingearbeitet, sodass das dauerhafte Muster eine SKILL.md (oder gleichwertige Datei) 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-ähnliches 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 schrittweise Offenlegung hält Sitzungen fokussiert, ohne eine vollständige Konstitution bei jedem Prompt zu laden.

Der Nachteil ist die Disziplin. Nichts zwingt Sie durch clarify- oder Review-Gates, es sei denn, Sie bauen diese Gates selbst. Threads auf Reddit und Hacker News über „spec-driven development inside Claude Code“ sind voller Entwickler, die das Skill eines anderen kopiert, es einmal ausgeführt und zurück zum unstrukturierten Prompting gegangen sind, wenn sich das Skill langsam anfühlte. Claude-Code-SDD funktioniert, wenn Sie Skills wie Code behandeln – versioniert, geprü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 codieren Sie Ihre Phasen als Skills mit expliziten Prüfungen. 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 Schritt der Review-Gates speziell können Claude Code Subagents einen unabhängigen, isolierten Kontext-Review-Pass auf generierten Code ausführen, bevor Sie eine Aufgabe mergen – eine leichte Alternative für die Verifikationsrolle, die Kiros Agent Hooks nativ bereitstellen.

Superpowers: Eine paketierte Version des DIY-Skill-Stacks

Wenn das Handrollen dieses Skill-Stacks genau das Disziplinproblem zu sein scheint, auf das die Tabelle oben hinweist, 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 –, das als installierbares Plugin verteilt wird, statt von Ihnen aus dem Nichts geschrieben zu werden. Es zielt direkt auf die Einschränkung „Qualität hängt völlig von der Disziplin des Autors ab“ ab: Die Skills werden automatisch ausgelöst und sind als verpflichtender Workflow gedacht, nicht als optionale Vorschläge, die der Agent überspringen kann.

Der erzwungene Workflow mappt eng auf den in Spec-Driven-Development-Workflow von der Anforderung bis zum Code abgedeckten Fünf-Phasen-Zyklus: Brainstorming verfeinert eine grobe Idee in ein geprüftes Design-Dokument, writing-plans bricht es in kleine, überprüfbare Aufgaben auf, 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. Letzteres ist strenger, als sich die meisten Claude-Code-SDD-Skills die Mühe machen – Superpowers löscht explizit Code, der vor dem Bestehen eines fehlerhaften Tests geschrieben wurde, für den es diesen Test gab.

Im Gegensatz zu einem lokal im Repository geschriebenen 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 Harnesses hinweg begleitet, statt in einem einzelnen .claude/skills/-Ordner zu leben. Das macht es zu einem Mittelweg zwischen dem eigenen Claude-Code-Skill und der Adoption eines schwereren, IDE-spezifischen Tools wie Kiro: Sie erhalten einen zwingenden, geführten Zyklus, ohne Ihren Editor aufzugeben oder sich auf das Spezifikationsformat eines einzelnen Anbieters einzulassen.

Superpowers passt zu Entwicklern, die grundsätzlich den Claude-Code-Skills-Ansatz mögen, aber ständig zurück zum unstrukturierten Prompting rutschen, weil nichts die Review-Gates erzwingt. Es ist ein schwächerer Fit, wenn Sie bereits ein projektspezifisches SDD-Skill haben, das auf Ihren Stack abgestimmt ist – in dem Fall tauschen Sie einen kleinen Teil der Anpassbarkeit gegen eine größere Menge erzwungener Zeremonie ein.

BMAD, OpenSpec und andere Workflows

Nicht jedes Team wünscht sich den Spec-Kit-Artefaktbaum oder die Kiro-IDE. Zwei Alternativen tauchen in Vergleichen von 2026 ständig auf.

OpenSpec (Fission AI) nimmt einen änderungszentrierten Ansatz mit weniger generierten Dateien als Spec Kit. Community-Benchmarks berichten von erheblich niedrigerem Token-Verbrauch für vergleichbare Aufgaben, auf Kosten weniger Struktur im Voraus. OpenSpec gewinnt tendenziell, wenn Sie ein bestehendes Codebase ä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. Siehe den OpenSpec-Quickstart für die Installationsschritte, den explore-propose-apply-archive-Zyklus und die Fallstricke, die am häufigsten auf Reddit auftauchen.

BMAD-METHOD (Community) geht in die entgegengesetzte Richtung – Multi-Agenten, rollenbasierte Workflows, die Produkt-Owner-, Architekt-, Entwickler- und Revisors-Personas simulieren. BMAD kann bei großen Greenfield-Vorhaben mit expliziter Rollentrennung leistungsfähig sein. Es ist auch schwerfällig. Teams berichten häufig, dass sich die Zeremonie nur auszahlt, wenn der Koordinierungsschmerz bereits akut ist.

Tessl behandelt die Spezifikation als wörtliche Quelle des generierten Codes, markiert Ausgaben als abgeleitet und ermutigt zu Handänderungen. Das ist die stärkste „Spec-as-Source“-Position unter den Mainstream-Tools, aber Tessl bleibt in der Beta und trägt den höchsten Produkt-Lock-in der Gruppe.

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

gstack geht einen Schritt über die Spec-Ebene hinaus: Es hüllt den Coding-Agenten in ein vollständiges virtuelles Engineering-Team – Produkt-Review, Architektur- und Design-Review, Browser-QA, Sicherheitsaudits und die Ship-Deploy-Release-Kette – sodass die Spezifikation eine von mehreren erzwungenen Stufen ist, statt das Rückgrat zu sein. Es läuft auf Claude Code und neun anderen Agenten, und der Leitfaden deckt ab, wie man Spec Kit (oder OpenSpec) das Planungs-Rückgrat besorgen lässt, während gstack die Schichten liefert, die ein Spec-Tool nicht erzwingt.

Das Muster über all ihnen hinweg ist dasselbe. Mehr Prozess hilft, wenn Mehrdeutigkeit teuer ist. Mehr Prozess schadet, wenn die Geschwindigkeit des Feedbacks wichtiger ist als die Ausrichtung. Passen Sie das Gewicht des Tools 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, bestehendes Codebase, kleine Features. Beginnen Sie mit Claude-Code-Skills oder OpenSpec. Schreiben Sie einen kurzen Anforderungen-Block, eine minimale Aufgabenliste und einen Prüf-Punkt. Installieren Sie keinen vollständigen Spec-Kit-Baum für eine Fünfzig-Zeilen-Änderung.

Möchten den Claude-Code-Skills-Ansatz, aber überspringen ständig Ihre eigenen Review-Gates. Installieren Sie Superpowers statt eines Custom Skills aus dem Nichts zu schreiben. Sie opfern etwas projektspezifische Anpassungen im Austausch für 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 gepflegtes Claude-Code-SDD-Skill. Sie brauchen dauerhafte Artefakte mehr als IDE-Handhalten.

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

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

Regulierte Umgebung. Kiro oder Spec Kit plus Ihrer eigenen Validierungs-Checkliste – nicht nur Claude-Code-Skills, es sei denn, Sie codieren Compliance-Gates explizit. Werkzeug ersetzt keine Audit-Logs. Es macht sie nur leichter zu erzeugen.

Bestehendes Codebase, 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 querliegende Features.

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

Teams, die Experimente mit Multi-Agenten-Orchestrierung machen, sollten auch einen Blick auf Oh My OpenCode Agents werfen, für Muster, wie man Rollen über Agenten verteilt – komplementär zu SDD-Artefakten, keine Ersetzung dafür. Wenn Ihr Team einen terminal-first-Agenten statt eines IDE-integrierten betreibt, zeigt der OpenCode CLI Praxis-Leitfaden die leichtere, Prompt-Level-Version derselben Disziplin, vor der Implementierung zu planen – nützlich, wenn ein vollständiger Spec-Kit-Baum mehr Zeremonie ist, als die Aufgabe verlangt.

Praktische Entscheidungstabelle

Was tatsächlich den Erfolg bestimmt

Die Wahl des Tools ist weniger wichtig als die Qualität der Artefakte. 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, egal 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 auf. 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 bei einem bestimmten Feature noch zwischen SDD und unstrukturiertem Prompting wählen, lesen Sie Spec-Driven Development vs. Vibe Coding. Der Werkzeugvergleich in diesem Artikel zählt erst, wenn Sie entschieden haben, dass das Feature überhaupt eine Spezifikation verdient.

Schlechte Spezifikationen machen jeden Agenten schlechter. Gute Spezifikationen funktionieren über verschiedene Tools 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 auf agenten-agnostisches Markdown in Ihrem Repository. Kiro optimiert auf eine geführte spec-native IDE mit AWS-basierten Agenten. Claude-Code-Skills optimieren auf hackbare, leichte Workflows, die nur funktionieren, wenn Sie sie pflegen.

Wählen Sie das flachste Setup, das die Mehrdeutigkeit für das jeweilige Feature immer noch entfernt. Fügen Sie Struktur hinzu, wenn Koordinierungsschmerz auftritt, nicht wenn ein Blogpost es Ihnen sagt. Die Entwickler, die 2026 Wert aus SDD ziehen, sind nicht die mit der aufwendigsten Toolchain. Sie sind diejenigen, die Spezifikationen schreiben, die sich lohnen, implementiert zu werden – und dann dem von ihnen gewählten Tool erlauben, dagegen auszuführen.

Nützliche Links

• GitHub Spec Kit Dokumentation – offizielles Spec-Kit-Workflow-Referenz
• Superpowers Quickstart: Installation, Workflow und Ausprobieren – Open-Source-Skills-Paket, das eine Brainstorming-bis-TDD-Methodik über Claude Code, Cursor, Codex und andere Agenten hinweg erzwingt
• gstack: Ein meinungsstarker KI-Software-Ingenieur-Stack – die Option mit dem vollständigen virtuellen Engineering-Team und wie es mit Spec Kit, OpenSpec und Superpowers kombiniert wird
• Martin Fowler zu SDD-Tools – Analyse von Kiro, Spec Kit und Tessl