AboutVibe-ProjekteBlog
CTRL K
TutorialVibesKI

Ergänzung am 29.12.2025

Ich habe inzwischen Abschied von GitHub Spec-Kit genommen. Und empfehle es nicht mehr.

Zwangsbranches

Ich fange mit einem soften Grund an: Zum Einen stört mich, dass jede Spec bereits beim Anlegen zwingend und unumgänglich einen eigenen Branch hervorruft. Dieses Verhalten ist zwar dokumentiert, aber nicht aus dem README auf der Startseite ersichtlich oder in den Einführungsvideos erklärt. Ich entscheide gern selbst, ob und wann ich branche. Die Folge ist, dass man nicht mehrere Specs zugleich anlegen kann. Man kann schon, nur beginnen sie dann allesamt mit “001-” weil sich jeder Branch für den Erstling hält. Man vergibt sich die Möglichkeit, mehrere Specs gleichzeitig agentisch zu bearbeiten. Genau diese Möglichkeit bildet aber den Clou der modernen Softwareentwicklung mit KI Agenten.

Debuggen nur an Spec-Kit vorbei möglich

Zum Zweiten stört mich die Tatsache, dass ein Spec komplett durchlaufen werden muss, bevor man mit dem nächsten beginnt. Das Problem dabei ist die Annahme, dass ein Spec nur fehlerfrei begonnen und durchlaufen werden kann. Denn ein Spec-Kit durchläuft die Phasen constitution - specify - plan - tasks - implement. Mehr gibt es nicht. Damit kommen wir zu meinem für spec-kit tödlichem Argument: Das Design von Spec-Kit geht davon aus, dass damit der Zyklus komplett ist. Merkt ihr was? Es fehlt etwas ganz Entscheidendes: das Debuggen. Dafür gibt es schlicht keinen Slash-Command. Mir ist, auch bei Einsatz von KI, in einem Viertejahrhundert Praxis praktisch nie der Fall untergekommen, dass nach Umsetzung eines Plans keine Fehler zu debuggen waren.

Man kann in Ermangelung eines entsprechenden zu spec-kit gehörenden Commands deshalb nur an spec-kit vorbei debuggen. Die ganzen ausgeklügelten Vereinbarungen der constitution greifen dann nicht. Sie liegen im versteckten Verzeichnis .spec-kit und dort im Verzeichnis memory. Nichts davon gilt ausgerechent dann, wenn die meines Erachtens maßgebliche Arbeit, das Debuggen, das Revidieren gefällter Entscheidungen, stattfindet. Wenn man wichtige Dinge nur am System vorbei erledigen kann, sollte man das System gar nicht erst beginnen. Man könnte sagen: Ja, aber du kannst doch in den Chat nach dem implement -command zurück springen und dort dein Problem prompten. Theoretisch ja. Praktisch nein. Wißt ihr, wie ein Chatfenster aussieht nachdem es einen kompletten Plan implementiert hat? Das Fenster ist mindestens zu 70 % belegt. Jeder weitere Prompt darin provoziert Halluzinationen und Fehler. Die dann wieder dort debuggt werden sollen… Es funktioniert nicht in der Praxis. Ich musst es hart lernen. Man muss einen neuen Chat starten können um etwas zu debuggen, und das geht mit spec-kit nicht.

Ich bin heute, zwei Monate später, der Meinung, dass man, statt sich mit spec-kit zu beschäftigen, besser daran tut, eine vernünftige AGENTS.md aufzusetzen, welche für jede KI gilt. Eventuell dann hier und da noch einige Hinterlassenschaften für spezielle KI, bspw. für die CLAUDE.md, dass und wann sie vom selbst angelegten SKill für Context7 gebrauchen machen soll usw.

Ausserdem ist schon nach zwei Monaten die IDE Landschaft nicht mehr dieselbe. Cursor hat jetzt selbst einen Plan-Modus. Das ist kein Alleinstellungsmerkmal von Kiro mehr. Überhaupt alle IDE stecken viel Energie darein, Prompts möglichst effizient und intelligent auszuwerten. Man muss diese Tools aber auch atmen lassen, ihre Stärken ausspielen lassen. Das macht man, indem man ihnen ganz normal sagt, was man will. Mit ihnen spricht, Rückfragen beantwortet. Darauf sind und werden sie immer weiter optimiert. Was man ihnen jedoch durch spec-kit gefiltert vorsetzt, ist ein Korsett.

Es muss im Dezember 2025 nicht mal eine IDE sein. Ich erledige mittlerweile mehr und mehr direkt in Claude Code. Es ist in der täglichen Arbeit, wo man eben doch viel zwischen Projekten wechseln muss, oft einfach schneller und direkter auf den Punkt.

Gleichwohl folgt hier mein ursprünglicher Blogbeitrag vom 22.10.2025, unverändert:

Using GithHub Spec-Kit

Einleitung in Spec-Kit: Wie Du mit Cursor und Spec-Driven Development (SDD) Produktionsreife Anwendungen erstellst

Dieser Blogbeitrag wurde zu einem Teil mit Hilfe durch Gemini erstellt und basiert auf einer Analyse der folgenden Quellen:

https://github.com/github/spec-kit

Warum Spec-Kit? Die Struktur, die KI-Agenten brauchen

Du kennst das Problem: Du hast eine großartige Idee für eine Anwendung, schreibst den Prompt, wirfst ihn Deinem Coding-Agenten zu und denkst: “Alles klar, los geht’s!”. Und dann erhältst Du Ergebnisse, die fehlerhaft sind, wichtige Funktionen vermissen lassen, oder der Agent hat sogar Dinge hinzugefügt, die Du gar nicht verlangt hast.

Coding-Agenten sind unglaublich leistungsfähig, aber sie brauchen Struktur. Sie benötigen dieselben Details, die auch echte Entwickler nutzen: Edge Cases, User Stories und Architekturentscheidungen.

Genau hier setzt GitHub Spec-Kit an. Es handelt sich um einen strukturierten Workflow, der Skripte und fein abgestimmte Prompts ausführt, um hochwertigen Kontext für Deinen KI-Agenten zu generieren. Im Wesentlichen führt Spec-Kit das Spec-Driven Development (SDD) in Deinen Workflow ein. SDD ist eine bewährte Methodik, bei der alles im Voraus geplant und dokumentiert wird.

Spec-Kit ist kein KI-Modell, sondern ein Open-Source-Framework und eine Kommandozeilenschnittstelle (CLI), die den strukturierten Prozess bereitstellt. Es fungiert als “Dirigent”, der die Partitur liefert und den Takt vorgibt.

Die Symbiose: Spec-Kit als Dirigent, Cursor als Virtuose

Spec-Kit ist agnostisch in Bezug auf den verwendeten Coding-Agenten. Du kannst es mit Claude, Codeex oder eben Cursor nutzen.

In dieser Arbeitsteilung ist Cursor der “Virtuose” oder der intelligente, KI-gestützte Code-Editor, der die Anweisungen des Spec-Kit-Frameworks ausführt.

Der Einsatz von Cursor

Wenn Du Spec-Kit zusammen mit Cursor verwendest, nutzt Du die integrierten Slash Commands. Anstatt manuell Prompts einzugeben, führst Du vordefinierte, kontextreiche Prompts aus, die Spec-Kit bereitstellt, wie zum Beispiel /Spec-Kit.constitution oder /Spec-Kit.specify. Die interne KI-Engine von Cursor liest diesen Prompt, versteht den Kontext aus den Spec-Kit-Vorlagen und generiert daraufhin die entsprechenden Dateien.

Ein entscheidender Vorteil bei der Nutzung von Cursor ist die Multi-LLM-Umgebung. Spec-Kit hat kein eigenes Sprachmodell (LLM); stattdessen wird das in der Cursor IDE ausgewählte und konfigurierte Modell verwendet. Dies bietet Dir maximale Flexibilität:

Der Spec-Kit-Workflow: Phasen des SDD

Der Spec-Kit-Workflow ist in mehrere kritische Phasen unterteilt, die sicherstellen, dass die KI alle notwendigen Informationen erhält, bevor sie mit dem Schreiben von Code beginnt:

1. Constitution (Die Gesetze des Projekts)

Dies ist oft der erste Schritt, den Du ausführst. Die Constitution legt die nicht verhandelbaren Projektprinzipien und -standards fest.

2. Specify (Was und Warum)

Dies ist der Beginn des Feature Life Cycles. In dieser Phase teilst Du dem Agenten mit, welche Funktion Du bauen möchtest, ausschließlich anhand von geschäftlichen Anforderungen und User Stories.

3. Clarify (Die Optionalität der Präzision)

Dieser optionale Schritt ist sehr zu empfehlen. Der Agent analysiert die erstellte spec.md und stellt klärende Fragen zu Unklarheiten oder fehlenden Details (z.B. zur Sortierreihenfolge oder Paginierung).

4. Plan (Das Wie)

Der Planungsphase folgt auf die finalisierte Spezifikation.

5. Tasks (Granulare Schritte)

Der Plan wird in individuelle, ausführbare Schritte zerlegt.

6. Implement (Die Code-Ausführung)

Dies ist der Schritt, in dem der Coding-Agent den eigentlichen Code schreibt.

Fortgeschrittene Technik: Kontextsteuerung mit Cursor

Für komplexe Projekte, insbesondere bei der Neuentwicklung (Greenfield), musst Du möglicherweise Logik aus Altsystemen analysieren.

Fazit

Spec-Kit und Cursor bieten zusammen eine strukturierte, transparente und skalierbare Methodik für die moderne Softwareentwicklung. Der Prozess ist dialogorientiert und erfordert von Dir eine sorgfältige Überprüfung und Verfeinerung aller generierten Artefakte. Indem Du die Prozesse (Spec-Kit) und die Intelligenz (Cursor/LLM) klar trennst, behältst Du die Kontrolle über die Architektur und stellst sicher, dass Deine KI-Agenten Anwendungen bauen, die tatsächlich Deinen Vorstellungen entsprechen.

Die generierten Dokumente (spec.md, plan.md, tasks.md) sind dabei nicht nur Anweisungen für die KI, sondern werden zu einer lebenden Dokumentation für Dein Team und sind unschätzbare Werkzeuge für Code-Reviews. Du kannst diese Spezifikationen in Zukunft wiederverwenden, selbst wenn Du den gesamten Technologiestapel wechselst.

| Impressum | Mein GitHubRSS