Zum Hauptinhalt springen
Fortgeschritten

Spec-getriebene Entwicklung mit Spec Kit

Vibe-Coding — „Bau mir ein Dashboard“, und nimm einfach an, was zurückkommt — funktioniert wunderbar, bis das Feature groß wird. Dann driftet der Agent ab: Er vergisst eine frühere Entscheidung, erfindet eine Funktion neu oder liefert etwas, das technisch läuft, aber nicht das ist, was du gemeint hast. Spec-getriebene Entwicklung (Spec-Driven Development, SDD) ist die Lösung, die sich 2026 in der Agentic-Coding-Szene durchgesetzt hat: Statt den Prompt als Wegwerfware zu behandeln, machst du eine geschriebene, prüfbare Spezifikation zur einzigen Wahrheitsquelle und lässt den Agenten Code daraus generieren.

GitHubs Open-Source-Werkzeug Spec Kit macht aus dieser Idee einen konkreten Workflow, den du heute direkt in Claude Code ausführen kannst.

What you'll learn
  • Verstehen, was spec-getriebene Entwicklung ist und welches Problem sie löst
  • Die Spec-Kit-Phasen durchgehen: constitution → specify → plan → tasks → implement
  • Die Specify-CLI installieren und in Claude Code einbinden
  • Die optionalen Qualitäts-Gates kennen (clarify, analyze, checklist)
  • Entscheiden, wann sich SDD trotz Mehraufwand lohnt und wann nicht

Warum Specs statt nur Prompts​

Ein Prompt ist verschwunden, sobald der Turn endet. Eine Spec ist ein Artefakt: Sie kann gelesen, in einem PR geprüft, korrigiert und erneut ausgeführt werden. Diese eine Verschiebung behebt die drei Arten, auf die große agentische Builds schiefgehen:

  • Drift — der Agent widerspricht einer früheren Entscheidung, weil sie nirgends festgehalten wurde. Die Spec ist das Gedächtnis.
  • Mehrdeutigkeit — „mach es schön“ bedeutet zehn verschiedene Dinge. Anforderungen in Prosa zu zwingen, deckt die Lücken auf, bevor Code existiert, wo sie billig zu beheben sind.
  • Nicht prüfbare Diffs — ein generierter PR mit 2.000 Zeilen ist schwer zu beurteilen. Eine geprüfte Spec + ein geprüfter Plan machen den Diff erwartbar statt überraschend.

Das mentale Modell: Intent ist das wertvolle, langlebige Ding; Code ist ein nachgelagertes, regenerierbares Artefakt. SDD ist der disziplinierte Cousin von Claude Codes eigenem Plan Mode — erst planen, dann bauen — hochskaliert auf ein ganzes Feature und in Dateien deines Repos festgehalten.

Der Spec-Kit-Workflow​

Spec Kit strukturiert ein Feature als kurze Pipeline von Slash-Commands. Jeder davon schreibt Markdown-Artefakte in dein Repo (unter .specify/), sodass jede Phase einsehbar und versionskontrolliert ist.

Guided walkthrough1 of 5
  1. Führe /speckit.constitution einmal pro Projekt aus. Es schreibt leitende Prinzipien — Code-Stil, Test-Anspruch, architektonische Nicht-Verhandelbares — in .specify/memory/constitution.md. Jede spätere Phase wird dagegen geprüft, das ist also dein dauerhaftes Leitplanken-Element (denk daran wie an eine CLAUDE.md, die sich auf Prinzipien fokussiert).

Optionale Qualitäts-Gates​

Drei weitere Befehle ziehen die Schleife enger, wenn ein Feature folgenreich ist:

  • /speckit.clarify — durchleuchtet die Spec nach unzureichend spezifizierten Bereichen und stellt dir gezielte Fragen vor der Planung. Am besten direkt nach specify ausführen.
  • /speckit.analyze — gleicht Spec, Plan und Tasks auf Konsistenz und Abdeckungslücken ab.
  • /speckit.checklist — erzeugt eine Validierungs-Checkliste, damit „fertig“ definiert und testbar ist.
Pro tip
  • Führe /speckit.clarify vor /speckit.plan aus — Mehrdeutigkeit zu beheben ist am billigsten, bevor die Architektur festgelegt ist.
  • Behandle jedes generierte Artefakt wie einen PR: lies es, korrigiere es, und gehe erst dann zur nächsten Phase weiter.
  • Committe die .specify/-Artefakte — sie sind die prüfbare Aufzeichnung der Intention hinter dem Code.

Mit Claude Code zum Laufen bringen​

Spec Kit liefert eine CLI, Specify, die die Slash-Commands in dein Projekt scaffoldet. Sie unterstützt über 30 Coding-Agenten, Claude Code darunter.

Guided walkthrough1 of 3
  1. Verwende uv, um sie aus dem Repo zu installieren. (Python + uv erforderlich.)

Install the Specify CLI (uv)

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git

Scaffold spec-driven workflow into a project

# new project
specify init my-feature

# or in the current repo
specify init --here

Then, inside Claude Code, run the pipeline

/speckit.constitution Establish principles: TypeScript strict, tests for every public function, no secrets in code.
/speckit.specify Build a CSV export for the reports page: users pick a date range and download a CSV of matching rows.
/speckit.clarify
/speckit.plan Next.js App Router, server action for the query, stream the CSV; no new dependencies.
/speckit.tasks
/speckit.implement
Watch out
  • Das genaue Flag zur Agentenauswahl für specify init ändert sich zwischen Releases — prüfe den README-Quickstart, statt ein Flag blind zu kopieren.
  • SDD macht die Notwendigkeit der Verifikation nicht überflüssig: lies den generierten Code und führe ihn aus. Die Spec macht den Diff prüfbar, nicht automatisch korrekt.
  • Lege niemals Secrets oder Zugangsdaten in der Spec, im Plan oder in der Constitution ab — sie werden wie jede andere Datei committet.

Wann man es nutzt (und wann nicht)​

SDD tauscht anfängliche Zeremonie gegen Kontrolle. Dieser Tausch lohnt sich, wenn die Arbeit groß, mehrdeutig oder von anderen geprüft werden muss — und ist reiner Mehraufwand, wenn nicht.

What you'll learn
  • Greif zu SDD: Greenfield-Features, Multi-File-Builds, alles, was ein Teammitglied prüfen muss, oder Arbeit, die du an eine Subagenten-Flotte übergibst.
  • Überspring SDD: einmalige Skripte, winzige Fixes, explorativer Wegwerf-Code — ein einfacher Prompt oder der Plan Mode ist schneller.
  • Brownfield funktioniert auch: richte /speckit.specify auf eine Erweiterung einer bestehenden Codebasis, nicht nur auf neue Projekte.
SDD at a glance
Drücke Enter oder die Leertaste, um die Karte umzudrehen. Nutze die Pfeiltasten links und rechts, um zwischen den Karten zu wechseln.Begriff angezeigt.
1 / 5

Teste dich selbst​

Check yourself

0/3
  1. Was ist die Kernidee der spec-getriebenen Entwicklung?
  2. Welche Spec-Kit-Phase sollte den Technologie-Stack und die Architektur erfassen?
  3. Wann lohnt sich spec-getriebene Entwicklung den Mehraufwand NICHT?
Key takeaways
  • Spec-getriebene Entwicklung macht eine prüfbare Spec — nicht den Prompt — zur Wahrheitsquelle und tötet damit Drift, Mehrdeutigkeit und nicht prüfbare Diffs.
  • GitHubs Spec Kit (die Specify-CLI) bringt SDD als /speckit.*-Slash-Commands in Claude Code.
  • Die Pipeline ist constitution → specify → (clarify) → plan → (analyze) → tasks → (checklist) → implement, wobei jede Phase einsehbare Artefakte schreibt.
  • Halte das WAS/WARUM in der Spec und das WIE im Plan; prüfe jedes Artefakt wie einen PR, bevor du weitergehst.
  • Nutze es für große, mehrdeutige oder geprüfte Features; überspring es bei Wegwerf-Arbeit — und verifiziere immer trotzdem den generierten Code.

Weiter​

  • Plan Mode — die eingebaute, leichtgewichtigere „erst planen, dann bauen“-Schleife
  • Slash Commands — wie die /speckit.*-Befehle in Claude Codes Command-System passen
  • CLAUDE.md & Memory Files — die Prinzipien-als-Gedächtnis-Idee hinter der Constitution
  • Subagents — übergib eine geprüfte Aufgabenliste an eine Flotte von Agenten
  • Coding & Software Development — die Alles-verifizieren-Haltung, auf der SDD beruht

Quellen & weiterführende Literatur​