GitHubs Spec Kit – Hochwertige Software schneller entwickeln

• Spec-Driven Development: Ein Ansatz, der die in der traditionellen Entwicklung nur unterstützend eingesetzte Spezifikation (Spec) zu einer ausführbaren Spezifikation aufwertet, um daraus direkt eine funktionierende Implementierung zu erzeugen
  • Weg von der codezentrierten Praxis hin zu einer intentionszentrierten Entwicklung, die zuerst Was und Warum definiert und erst danach das Wie konkretisiert
  • Die Kernidee ist, durch Spezifikationen konsistente Artefakte zu erzeugen und wiederkehrende Arbeit zu automatisieren, damit sich Entwickler auf Produktprobleme konzentrieren können
• Spec Kit ist eine Sammlung von Werkzeugen, die dabei hilft, diese Spezifikationen in ausführbare Artefakte zu überführen und so die Implementierung zu automatisieren
• Nach der Installation wird mit /specify das Was/Warum beschrieben, mit /plan der Stack/die Architektur festgelegt und mit /tasks werden Arbeitseinheiten erzeugt
• Ziel ist es, Organisationen dabei zu helfen, sich von der Erstellung nicht differenzierender gemeinsamer Codebestandteile zu lösen und sich auf Produktszenarien zu konzentrieren – ein experimentelles Framework, das über einen spezifikationsgetriebenen Ansatz sowohl Qualität als auch Geschwindigkeit steigern will

Kernphilosophie: Core philosophy

• Intentionszentrierte Entwicklung mit einer spec-first-Denkweise, bei der das Was Vorrang hat und das Wie erst später konkretisiert wird
• Erstellung reichhaltiger Spezifikationen mit Guardrails und organisatorischen Prinzipien sowie ein mehrstufiger Verfeinerungsprozess statt einmaliger Codegenerierung
• Eine Vorgehensweise, die sich aktiv auf die Interpretationsfähigkeit fortgeschrittener AI-Modelle stützt, um Spezifikationen in ausführbare Ergebnisse zu überführen

Spezifikationsgetriebener Prozess mit Spec Kit

• Spec Kit macht Spezifikationen zum Zentrum des Engineering-Prozesses und steuert damit Implementierung, Checklisten und die Zerlegung in Aufgaben, während Entwickler vor allem eine anleitende Rolle einnehmen
  • Coding Agents übernehmen den Großteil der Schreibarbeit
• Der Prozess besteht aus 4 Phasen, jede mit klaren Checkpoints; zur nächsten Phase wird erst übergegangen, wenn die aktuelle Arbeit vollständig validiert ist
• Specify-Phase: Gibt man eine Beschreibung auf hohem Niveau vor, erzeugt der Coding Agent eine detaillierte Spezifikation, die sich nicht auf den Technologie-Stack, sondern auf User Journey, Experience und Erfolgsmetriken konzentriert
  • Dabei wird abgebildet, wer die Nutzer sind, welches Problem gelöst wird, wie die Interaktion aussieht und welche Ergebnisse wichtig sind
  • Das ist ein lebendes Artefakt, das sich mit zunehmendem Nutzerverständnis weiterentwickelt
• Plan-Phase: Gibt man gewünschten Stack, Architektur und Randbedingungen vor, erstellt der Coding Agent einen umfassenden technischen Plan
  • Einschließlich Standardtechnologien im Unternehmen, Integration von Legacy-Systemen, Compliance und Performance-Zielen
  • Es können mehrere Planvarianten zum Vergleich angefordert werden; mit internen Dokumenten lassen sich Architekturpatterns direkt integrieren
• Tasks-Phase: Auf Basis von Spezifikation und Plan zerlegt der Coding Agent die Arbeit in kleine, überprüfbare Chunks
  • Jede Aufgabe kann unabhängig implementiert und getestet werden und ist so gestaltet, dass AI sie validieren und nachverfolgen kann
  • Zum Beispiel nicht „Authentifizierung aufbauen“, sondern konkret „Einen Benutzerregistrierungs-Endpunkt mit Validierung des E-Mail-Formats erstellen“
• Implement-Phase: Der Coding Agent bearbeitet Aufgaben einzeln oder parallel, während Entwickler fokussierte Änderungen prüfen
  • Die Spezifikation sagt, was gebaut werden soll, der Plan wie es gebaut werden soll, und die Tasks bestimmen, woran gearbeitet wird
• In jeder Phase übernehmen Entwickler eine Validierungsrolle: Sie reflektieren und verfeinern, prüfen, ob die Spezifikation die Absicht erfasst, ob der Plan reale Einschränkungen berücksichtigt und ob Lücken oder Edge Cases vorhanden sind

Verwendung von Spec Kit in agentischen Workflows

• Spec Kit arbeitet mit Coding Agents wie GitHub Copilot, Claude Code, Gemini CLI und steuert die Agents über eine einfache Folge von Befehlen, um Artefakte zu erzeugen
  • So werden vage Prompts in klare Absichten übersetzt und zuverlässig ausgeführt
• Nach der Projektinitialisierung liefert man mit dem Befehl /specify einen Prompt auf hohem Niveau; der Coding Agent erzeugt daraus die vollständige Spezifikation mit Fokus auf das „Was“ und „Warum“ des Projekts
• Mit dem Befehl /plan gibt man die technische Richtung auf hohem Niveau vor; der Coding Agent erstellt daraus einen detaillierten Plan, der Architektur und Einschränkungen berücksichtigt
• Mit dem Befehl /tasks werden Spezifikation und Plan in eine ausführbare Aufgabenliste zerlegt, auf deren Grundlage der Coding Agent die Projektanforderungen umsetzt

Entwicklungsphasen: Development phases

• 0-to-1 (Greenfield): Unterstützt einen Ablauf von Spezifikation erstellen → Planung aufsetzen → produktionsreife App auf Basis hochrangiger Anforderungen
• Kreative Exploration: Betont einen Prozess, in dem verschiedene Stacks/Architekturen und UX-Patterns per paralleler Implementierung erprobt werden
• Schrittweise Verbesserung (Brownfield): Evolutionäre Entwicklung durch wiederholtes Hinzufügen von Features, Modernisierung von Legacy-Systemen und Anpassung von Prozessen

Drei Szenarien, in denen dieser Ansatz gut funktioniert

• Greenfield (zero-to-one): Beim Start eines neuen Projekts wird nicht sofort mit dem Coden begonnen; stattdessen werden Spezifikation und Plan vorab erstellt, damit AI auch wirklich das Beabsichtigte baut und statt generischer Lösungen auf Basis allgemeiner Muster maßgeschneiderte Ergebnisse liefert
• Feature-Arbeit in bestehenden Systemen (N-to-N+1): Wenn einem komplexen Codebestand neue Funktionen hinzugefügt werden, klärt die Spezifikation die Interaktion der neuen Funktion mit dem bestehenden System und der Plan kodiert architektonische Einschränkungen, damit Code entsteht, der sich nativ anfühlt
  • Das macht kontinuierliche Weiterentwicklung schneller und sicherer, kann aber fortgeschrittene Context-Engineering-Techniken erfordern
• Legacy-Modernisierung: Wenn bei der Neuentwicklung von Legacy-Systemen die ursprüngliche Absicht verloren gegangen ist, hilft der Spec-Kit-Prozess dabei, die wesentliche Geschäftslogik in einer modernen Spezifikation festzuhalten und eine frische Architektur zu planen, damit AI ohne technische Schulden neu aufbauen kann

Prerequisites

• Linux/macOS oder WSL2 unter Windows erforderlich
• Als AI-Agent kann zwischen Claude Code, GitHub Copilot, Gemini CLI und Cursor gewählt werden

[edunga1]

Erinnert mich an den Copilot Workspace.

[cocofather]

Es scheint die Grundlage für KI-gestützte Programmierung auf Basis natürlicher Sprache zu werden.

[tested]

Die Vorteile von GitHubs Spec Kit lassen sich auch mit GitHub Copilot nutzen.
Da es von GitHub entwickelt wurde, ist das vielleicht selbstverständlich? Viele andere Tools basierten jedoch auf Claude.

[skageektp]

Das erinnert mich an die Kiro IDE.

[kandk]

Interessant. Ergibt auch irgendwie Sinn.

[xguru]

Der Link zur ausführlichen Vorstellung von SDD mitten im Artikel ist wirklich lesenswert. Unten ist eine KI-Zusammenfassung davon.

Spezifikationsgetriebene Entwicklung (Specification-Driven Development, SDD)

The Power Inversion

• Der bisher codezentrierte Ablauf, in dem PRD- und Design-Dokumente nur unterstützend dienten, wird umgekehrt: Die Spezifikation ist das Original, und der Code ist ein Artefakt, das in einer bestimmten Sprache bzw. einem bestimmten Framework implementiert wird
  • Es wird die Diagnose gestellt, dass die dauerhafte Lücke zwischen Spezifikation und Implementierung weder durch bessere Dokumentation noch durch strengere Prozesse leicht zu schließen war
  • Wenn ausführbare Spezifikationen und Implementierungspläne den Code erzeugen, verschwindet diese Lücke, und es bleibt nur noch Transformation
• KI ermöglicht die Interpretation komplexer Spezifikationen und die Erstellung von Implementierungsplänen, doch unstrukturierte Generierung führt zu Chaos; SDD sichert daher Qualität durch präzise Struktur und Guardrails
• Wartung ist ein Vorgang der Weiterentwicklung der Spezifikation; Entwicklungsabsicht wird durch natürliche Sprache, Design-Artefakte und Kernprinzipien ausgedrückt, während Code die letzte Meile einnimmt
• Beim Debugging steht nicht die Korrektur fehlerhaften Codes im Vordergrund, sondern zuerst die Anpassung der Spezifikation und des Implementierungsplans; Refactoring wird neu definiert als Neustrukturierung für mehr Klarheit

The SDD Workflow in Practice

• Ideen werden durch konversationelle Interaktion mit KI zu einem PRD verfeinert; die KI konkretisiert dabei Fragen, Edge Cases und Akzeptanzkriterien
  • Anforderungen und Design werden zu einer kontinuierlichen Aktivität, wodurch teamweite branchbasierte Spezifikationsarbeit sowie Reviews und Versionierung unterstützt werden
• Ein Research Agent untersucht Bibliothekskompatibilität, Performance, Sicherheit und organisatorische Einschränkungen (DB-Standards, Authentifizierung, Deployment-Richtlinien) und übernimmt diese automatisch in die Spezifikation
• Aus dem PRD wird ein Implementierungsplan erzeugt, der Anforderungen und technische Entscheidungen nachvollziehbar aufeinander abbildet; die KI prüft fortlaufend Widersprüche, Unklarheiten und Lücken
• Sobald Spezifikation und Plan ausreichend stabil sind, beginnt die Codegenerierung; anfangs dient explorative Generierung dazu, die Machbarkeit zu validieren
  • Fachliche Konzepte werden in Datenmodelle, User Stories in API-Endpunkte und Akzeptanzszenarien in Tests überführt
• Metriken und Incidents aus dem Betrieb aktualisieren die Spezifikation und fließen in die nächste Regenerierung ein; Performance-Bottlenecks werden zu nichtfunktionalen Anforderungen, Schwachstellen zu globalen Constraints hochgestuft

Why SDD Matters Now

• Schwellenwert der KI-Fähigkeiten: Aus natürlichsprachlichen Spezifikationen lässt sich verlässlich lauffähiger Code erzeugen; die Automatisierung der mechanischen Teile der Implementierungsübersetzung unterstützt Exploration und Kreativität
• Explosion der Komplexität: Durch viele Services, Frameworks und Abhängigkeiten wird es schwierig, die Konsistenz zwischen Absicht und Implementierung zu wahren; deshalb ist die spezifikationsgetriebene Ausrichtung von SDD nötig
• Beschleunigter Wandel: In Situationen mit häufigen Pivots verarbeitet SDD Änderungen nicht durch manuelle Weitergabe an Dokumentation, Design und Code, sondern durch systematische Regenerierung
  • Beispielsweise werden What-if-Simulationen und parallele Implementierungen möglich und erhöhen so die Entscheidungsagilität

Core Principles

• Spezifikation = gemeinsame Sprache: Die Spezifikation ist ein Artefakt erster Klasse, Code ist deren Ausdruck in einem bestimmten Stack, und Wartung ist die Weiterentwicklung der Spezifikation
• Ausführbare Spezifikation: Mit einer Spezifikation auf dem Niveau von Präzision, Vollständigkeit und Eindeutigkeit wird ein funktionsfähiges System erzeugt
• Kontinuierliche Verfeinerung: Statt eines einmaligen Gates erfolgt eine ständige Konsistenzprüfung
• Research-basierter Kontext: Performance, Sicherheit und organisatorische Einschränkungen werden fortlaufend gesammelt und in die Spezifikation eingespeist
• Bidirektionales Feedback: Die Realität des Betriebs wird zum Input für Spezifikations-Updates
• Branching für Exploration: Von derselben Spezifikation aus wird die Erzeugung mehrerer Implementierungen für Optimierungsziele wie Performance, Wartbarkeit, UX oder Kosten unterstützt

Implementation Approaches

• In der heutigen Praxis sind die Kombination bestehender Tools und das Einhalten von Disziplin entscheidend; umsetzen lässt sich das mit folgenden Elementen
  • KI-Assistenten zur iterativen Verfeinerung der Spezifikation
  • Research Agents zur Sammlung technischen Kontexts
  • Codegenerierungs-Tools für die Umwandlung von Spezifikation in Implementierung
  • Versionsverwaltung, angepasst an einen spec-first Workflow
  • Prüfungen auf Basis von KI-Konsistenzanalysen der Spezifikationsdokumente
• Das gemeinsame Grundprinzip lautet, die Spezifikation als Single Source of Truth zu behandeln und Code als von der Spezifikation gefordertes Ergebnis zu sehen

Streamlining SDD with Commands

• /specify: Wandelt eine Funktionsbeschreibung in eine strukturierte Spezifikation um und automatisiert automatische Nummerierung, Branch-Erstellung und die Einrichtung einer templatebasierten Verzeichnisstruktur
• /plan: Erzeugt Spezifikationsanalyse → Prüfung der Verfassungskonformität → technische Übersetzung → Dokumentation von Datenmodell, API-Verträgen und Testszenarien → Quickstart-Validierung
• /tasks: Liest plan.md und zugehörige Entwürfe, erstellt daraus eine ausführbare Task-Liste und bietet Kennzeichnung parallelisierbarer Tasks sowie sichere Parallelgruppierung
• Beispiel: Chat-Funktion
  • Es wird ein Ablauf gezeigt, bei dem sich rund 12 Stunden Dokumentationsarbeit im traditionellen Ansatz durch die Automatisierung von Spezifikation, Plan und Tasks auf etwa 15 Minuten reduzieren lassen
  • Zu den Artefakten gehören Spezifikation, Implementierungsplan mit Begründung, API-Verträge und Datenmodell, Quickstart-Szenarien sowie tasks.md, alles versionsverwaltet im Branch

The Power of Structured Automation

• Verhindern fehlender Punkte: Templates decken auch nichtfunktionale Anforderungen und Fehlerbehandlung ab
• Nachvollziehbarkeit von Entscheidungen: Jede technische Wahl ist mit konkreten Anforderungen verknüpft
• Lebende Dokumente: Da die Spezifikation den Code erzeugt, lässt sich die Synchronisierung leicht aufrechterhalten
• Schnelle Iteration: Bei Anforderungsänderungen ist durch Neu-Generierung des Plans eine Reaktion in Minuten oder Stunden möglich

Template-Driven Quality

• Verhindern vorschnellen Einsickerns von Implementierungsdetails: Regeln mit Fokus auf WHAT/WHY unter Ausschluss von HOW helfen, das Abstraktionsniveau zu halten
• Erzwingen von Unsicherheitsmarkierungen: Der Marker [NEEDS CLARIFICATION] verhindert Mutmaßungen und fördert explizite Rückfragen
• Checklistenbasierte Selbstprüfung: Durch Prüfung von Vollständigkeit, Klarheit und messbaren Akzeptanzkriterien wird ein Quality Gate umgesetzt
• Verfassungs-Gate: Checks in der Vorstufe (-1), etwa Simplicity Gate (≤3 Projekte), Anti-Abstraction Gate (Framework direkt verwenden) und Integration-First Gate (Verträge und Vertragstests zuerst)
• Geschichtete Detailverwaltung: Übermäßiger Code und Details werden in implementation-details/ ausgelagert, um die Lesbarkeit zu erhalten
• Test-Priorität: Regeln für Dateierstellung und Test-First in der Reihenfolge Vertrag → Integration → E2E → Unit sichern die Prüfbarkeit
• Eindämmung von Annahmen und spekulativen Features: Verbot spekulativer Features und explizite Voraussetzungen je Phase stärken das Scope-Management

The Constitutional Foundation

• Mit den unveränderlichen Prinzipien in memory/constitution.md wird eine Entwicklungsverfassung übernommen, die alle Implementierungen konsistent, einfach und hochwertig hält
  • Article I: Library-First — Jede Funktion beginnt als eigenständige Bibliothek und sichert so Modularität
  • Article II: CLI Mandate — Jede Bibliothek exponiert eine CLI-Schnittstelle mit Text-I/O und JSON, um Beobachtbarkeit und leichte Testbarkeit zu gewährleisten
  • Article III: Test-First — Keine Implementierung vor Testfreigabe und bestätigtem Fehlschlag (red); das Prinzip Verhalten zuerst definieren gilt
  • Articles VII & VIII: Simplicity, Anti-Abstraction — Minimierung der Projektanzahl und direktes Vertrauen in Frameworks bremsen Overengineering
  • Article IX: Integration-First Testing — Tests nah an der realen Umgebung werden bevorzugt, und Vertragstests sind verpflichtend vor der Implementierung
• Über das Phase--1-Gate der Templates wird die Verfassungskonformität in Checklisten gegossen; Ausnahmen dokumentieren ihre explizite Begründung unter Complexity Tracking
• Durch ein Änderungsverfahren kann sich die Anwendungsweise der Prinzipien weiterentwickeln, während die Kernphilosophie erhalten bleibt

The Transformation

• Ziel ist nicht der Ersatz von Entwicklern, sondern die Automatisierung mechanischer Übersetzung, um menschliche Fähigkeiten zu verstärken und die Konsistenz zwischen Absicht und Implementierung zu bewahren
• SDD setzt auf kontinuierliche Transformation, bei der Spezifikationen den Code erzeugen und sich Spezifikation, Research und Code in einem engen Feedback-Loop gemeinsam weiterentwickeln

[amoplan]

Mit welcher KI haben Sie das zusammengefasst?

[xguru]

Ich habe es mit GPT-5 gemacht. Ich verwende einen ziemlich langen Prompt, den ich für Zusammenfassungen zusammengestellt habe.

[heycalmdown]

Ich konnte mich mit dem Konzept stark identifizieren und habe es am Wochenende in einem neuen Projekt ein wenig getestet, aber es funktioniert nicht so gut wie gedacht. Es scheint noch einiges an Verbesserungen zu brauchen. Der grobe Ablauf ist zunächst, wie schon mehrfach vorgestellt, folgender:
Verfassung schreiben → Spezifikation schreiben → Tasks schreiben → Implementierung

Das Problem ist:

• Die Datei constitution.md ist zwar der zentrale Leitfaden dafür, "wie entwickelt werden soll", enthält aber nicht, "was diese App am Ende eigentlich sein soll"
• spec.md ist ein Dokument, das eine einzelne Funktion beschreibt
• Es gibt kein Master-Dokument dazu, "was diese App ist"
• Wenn man die Diskussionen auf GitHub liest, scheint die Idee zu sein, dass eine chain of specs letztlich zur source of truth wird. Das wirkt etwas fragwürdig, ist aber ungefähr nachvollziehbar.
• Über die Befehle /specify und /tasaks werden viele Dokumente als Artefakte erzeugt (also genau das gewünschte Ergebnis), aber dadurch wird der Kontext sehr schnell verbraucht (ich nutze Claude Code)
• Sobald man mit der Implementierung beginnt, entfernt man sich vorübergehend wieder von Spec Kit und schließt die Umsetzung wie gewohnt im Gespräch mit Claude Code ab
• Wenn der Kontext komplett aufgebraucht ist und man compaction ausführt oder eine neue Sitzung startet, vergisst es die von Spec Kit erzeugten Dokumente
• Wenn man die in tasks.md definierten Arbeiten ausführt, überschreibt man mitunter Dinge, die man vorher sauber gebaut hatte, und beim Beheben von Bugs entstehen auch neue Funktionen, sodass man sich immer weiter von tasks.md entfernt. Ich verstehe nicht, welchen Sinn es hat, tasks.md dauerhaft aufzubewahren.

Zu folgendem Fazit bin ich vorerst gekommen:

• Auch wenn am Ende etwas anderes herauskommt als ursprünglich gedacht, sollte man die Spezifikation zunächst fertigstellen und dann eine neue Spezifikation anlegen, um es schrittweise zu verbessern
• Die erste Spezifikation wird zwangsläufig groß; für die Funktionen der App sollte man sie am besten gar nicht beschreiben und lieber nur Boilerplate erstellen
• Wenn man etwas auf PoC-Niveau baut, ist es vermutlich besser, Spec Kit nicht zu verwenden