# Spec Kit in Claude Code: Specify, Plan, Tasks und Implement > So richtest du GitHub Spec Kit in Claude Code ein: 4 Phasen – Specify, Plan, Tasks, Implement. Hier erfährst du, was den Ansatz des improvisierten Vibe Coding ersetzt. Source: https://ailoot.ai/blog/de/spec-kit-claude-code-spec-driven-development/ Canonical: https://ailoot.ai/blog/de/spec-kit-claude-code-spec-driven-development/ Language: de Publisher: Ailoot (https://ailoot.ai/) Translation: guide-219 Revision: sha256-a18400b42405ff9327ea734c5501aeaa161cafbfc6c999df951fa2a3141a8cb9
Das Wichtigste Spec Kit ist ein Tool von GitHub, mit dem du eine Aufgabenbeschreibung in natürlicher Sprache verfassen kannst. Anschließend erstellt Claude Code einen Plan, unterteilt ihn in Aufgaben und schreibt den Code. Das ist keine Theorie: 107.000 GitHub-Sterne in 8 Monaten, AWS nutzte diese Methode, um ein Wirkstoffforschungsprojekt in 3 Wochen statt in mehreren Monaten zu entwickeln, und . Dieser Leitfaden behandelt die Installation, Vorlagen, die 4 Phasen des Workflows mit einer abschließenden Prüfung und die Verknüpfung mit deiner CLAUDE.md.
[Ailoot-Dokumentation](https://ailoot.ai/docs/) – Referenzmaterialien zur Nutzung des Dienstes.
## Was ist im Mai 2026 aus Vibe Coding geworden?
Das Wichtigste Over 8 months GitHub Spec Kit gathered 107,000 stars, and AWS published a case study reporting savings of 80+ hours on one feature. Der Trend der Woche im Mai: Spezifikationen als Ersatz für Improvisation.
Ein Jahr später, am 4. Februar 2026, veröffentlichte er einen Rückblick-Thread: In seinem Vortrag bei Sequoia Ascent 2026 formulierte er es noch präziser: „Vibe Coding hebt den Boden an – also das, was jeder in der Softwareentwicklung leisten kann. Agentisches Engineering erhält die Decke – den Qualitätsmaßstab professioneller Entwicklung.“ Auf derselben Bühne sagte er einen Satz, der in den Branchenwortschatz einging: „Man darf nicht wegen Vibe Coding Schwachstellen einführen. Du bist weiterhin für deine Software verantwortlich, wie zuvor.“ Zwei Dinge geschahen parallel. Im September 2025 veröffentlichte GitHub das Tool [Spec Kit](https://github.com/github/spec-kit) – in 8 Monaten sammelte es 107.000 Sterne. Im Februar 2026 veröffentlichte AWS [eine ausführliche Fallstudie zur Wirkstoffforschung](https://aws.amazon.com/blogs/industries/from-spec-to-production-a-three-week-drug-discovery-agent-using-kiro/) und meldete: „95 % der Geschäftslogik wurden aus der Spezifikation generiert, wodurch mehr als 80 Stunden eingespart wurden.“ Ende Mai 2026 hatte sich im englischsprachigen Informationsraum ein Konsens gebildet: Vibe Coding als Arbeitsmethode ist die Anfängerstufe. Danach kommt Spec-Driven Development. Dieser Leitfaden erklärt, wie du den Ansatz installierst und anwendest. ## Was sind Spec Kit und Spec-Driven Development?
Das Wichtigste Spec-Driven Development (SDD) stellt den üblichen Ansatz für KI-Agenten auf den Kopf. Früher war der Code die maßgebliche Grundlage und die Spezifikation begleitendes Papierwerk. Jetzt ist die Spezifikation die maßgebliche Grundlage, und der Code wird zum letzten Schritt – zu ihrer Umsetzung. Spec Kit ist ein CLI-Tool von GitHub, das 4 Phasen (Specify, Plan, Tasks, Implement) und eine abschließende Converge-Prüfung als sofort nutzbare Befehle in Claude Code, Cursor, Copilot und mehr als 30 weiteren Agenten bereitstellt.
Die Grundidee der Methode lässt sich in einer Zeile aus der offiziellen GitHub-Dokumentation zusammenfassen:

Spec-Driven Development verändert die Hierarchie: Spezifikationen dienen nicht dem Code – der Code dient den Spezifikationen. Die Spezifikation wird zum primären Artefakt, und der Code ist ihr Ausdruck in einer bestimmten Sprache und einem bestimmten Framework.

— GitHub Spec Kit Docs, https://github.com/github/spec-kit/blob/main/spec-driven.md
In der Praxis läuft das in 4 Phasen ab (Spec Kit fügt eine weitere hinzu, Phase null – die Verfassung, die weiter unten beschrieben wird): 1. **Specify** – Schreibe in natürlicher Sprache eine Spezifikation dessen, was du möchtest. WAS zu tun ist und WARUM. Nicht WIE. 2. **Plan** – Der Agent nimmt die Spezifikation und erstellt einen technischen Plan: welche Technologien, welche Architektur und welche Komponenten. 3. **Tasks** – Der Agent unterteilt den Plan in konkrete, überprüfbare Aufgaben mit Abhängigkeiten. 4. **Implement** – Der Agent (oder seine Subagenten) arbeitet die Aufgaben ab und schreibt den Code. Nach Implement bietet die aktuelle Version von Spec Kit einen Prüfschritt namens **Converge**: Der Agent gleicht den fertigen Code mit der Spezifikation, dem Plan und den Aufgaben ab und ergänzt alles Fehlende in `tasks.md`. Führe Implement und Converge wiederholt aus, bis Converge mit „Converged“ antwortet. Jede Phase ist eine eigene Markdown-Datei im Repo. Jede Phase ist ein eigener Slash-Befehl in Claude Code: `/speckit-specify`, `/speckit-plan`, `/speckit-tasks`, `/speckit-implement`, während die Prüfung `/speckit-converge` lautet. In der Spec-Kit-Dokumentation werden dieselben Befehle mit einem Punkt geschrieben (`/speckit.specify`), aber in Claude Code installiert Spec Kit sie als Skills, und sie werden mit einem Bindestrich aufgerufen. Wenn an einem beliebigen Schritt etwas schiefläuft, bearbeite die Markdown-Datei und führe die nächste Phase erneut aus. Spec Kit ist eine konkrete Umsetzung von SDD. Im Mai 2026 bot es bereits mehr als 30 Integrationen mit verschiedenen KI-Agenten. Innerhalb eines Repos funktioniert Spec Kit mit Claude Code, Cursor, GitHub Copilot, Codex CLI, Windsurf, Qwen, Tabnine, Amazon Q, Gemini, Goose und einem Dutzend weiteren auf dieselbe Weise. | Spec-Kit-Phase | Slash-Befehl | Artefakt im Repo | |----|----|----| | Constitution | `/speckit-constitution` | `.specify/memory/constitution.md` | | Specify | `/speckit-specify` | `specs/###-feature/spec.md` | | Clarify (optional) | `/speckit-clarify` | Änderungen in `spec.md` | | Plan | `/speckit-plan` | `specs/###-feature/plan.md` | | Checklist (optional) | `/speckit-checklist` | Checkliste zur Qualität der Anforderungen | | Tasks | `/speckit-tasks` | `specs/###-feature/tasks.md` | | Analyze (optional) | `/speckit-analyze` | Bericht zu Spezifikation, Plan und Aufgaben | | Implement | `/speckit-implement` | Code im Projekt | | Converge | `/speckit-converge` | Urteil „Converged“ oder neue Aufgaben in `tasks.md` | Nach einem Durchlauf enthält dein Repo also nicht nur Code, sondern auch die dazugehörige Spezifikation, den Plan und die Aufgaben. Einen Monat später kannst du zum Projekt zurückkehren, `spec.md` lesen und verstehen, was getan wurde und warum. Das ist nicht mehr „Vibe Coding und den Code vergessen“ – es ist das Arbeitsgedächtnis des Projekts. ## Warum braucht ein Vibe Coder, der keinen Code schreibt, das?
Das Wichtigste Der größte Schmerzpunkt beim Vibe Coding ist die Unvorhersehbarkeit. Heute baut der Agent dir in 20 Minuten ein funktionierendes Feature; morgen produziert er bei einer ähnlichen Aufgabe Spaghetticode. Spec Kit beseitigt die Ursache dieser Unvorhersehbarkeit – eine vage formulierte Aufgabe. Wenn du eine Spezifikation anhand einer Vorlage schreibst, arbeitet der Agent konsistent, weil er eine eindeutige maßgebliche Grundlage hat. Außerdem erhältst du ein dauerhaftes Artefakt im Repo, zu dem du einen Monat später zurückkehren kannst.
Spec Kit formalisiert Planung über separate Schritte mit 4 Slash-Befehlen. Die Logik: „gründlich durchdenken“ und „umsetzen“ voneinander trennen, damit sie in verschiedenen Kontextfenstern stattfinden. Jede Phase erhält einen sauberen Kontext, der nicht durch die vorherige Phase überladen wurde. Drei konkrete Vorteile für Vibe Coder: - **Vorhersehbarkeit.** Wenn du dem Agenten sagst: „Erstelle ein Registrierungsformular mit E-Mail-Bestätigung“, errät er selbst 10 Details – und liegt bei dreien davon falsch, verglichen mit dem, was du im Sinn hattest. Wenn du eine `spec.md` mit User Stories, Acceptance Scenarios und `[NEEDS CLARIFICATION]`-Markierungen an jeder unklaren Stelle hast, gibt es nichts zu erraten. - **Projektgedächtnis.** Einen Monat später wirst du dich nicht mehr daran erinnern, was du mit dem Agenten im Chat besprochen hast. Aber `spec.md`, `plan.md` und `tasks.md` liegen im Repo, im Ordner `specs/###-feature/` neben dem Code. Sie zeigen dir nicht nur, was erledigt wurde, sondern auch warum. - **Skalierung.** Bei einem Feature mit 1-2 Dateien ist der Unterschied kaum bemerkbar. Bei einem Feature mit 20 Dateien und 5 Dateneinheiten liegt der Unterschied zwischen „nach 4 Stunden alles neu schreiben“ und „nach 4 Stunden ist alles im Hauptzweig angekommen“. AWS Kiro demonstrierte beim Projekt TargetID, dass 95 % der Geschäftslogik anhand einer Spezifikation automatisiert wurden. Die größte Illusion beim Vibe Coding ist, dass es am Anfang schneller aussieht. Eine halbe Stunde, und es gibt einen Prototyp. Doch nach einer Woche geht der Prototyp kaputt, und es ist einfacher, ihn wegzuwerfen. Spec-Driven Development dauert am Anfang etwas länger (eine Stunde statt einer halben Stunde), aber eine Woche später arbeitest du immer noch im selben Repo. ## So installierst du Spec Kit in Claude Code (4 Schritte)
Das Wichtigste Spec Kit wird über uv installiert, einen Python-Paketmanager von Astral. Der Befehl selbst besteht aus einer Zeile. Gehe nach der Installation in dein Repo, führe `specify init` mit dem Flag `--integration claude` aus (oder wähle Claude Code aus der Liste der Agenten), und du erhältst eine fertige Struktur mit Vorlagen für Constitution, Spec, Plan und Tasks sowie eine Reihe von `/speckit-*`-Befehlen direkt in Claude Code. Die Installation dauert 5 Minuten, wenn uv bereits installiert ist, und 10 Minuten, wenn du es von Grund auf installierst.
**Schritt 1. uv installieren.** Das musst du nur einmal tun; es bleibt auf deinem System. ```bash # macOS / Linux curl -LsSf https://astral.sh/uv/install.sh | sh # Windows powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex" ``` Prüfe, ob uv installiert wurde: ```bash uv --version ``` **Schritt 2. Spec Kit installieren.** Ein Befehl: ```bash uv tool install specify-cli --from git+https://github.com/github/spec-kit.git ``` Prüfen: ```bash specify --version ``` **Schritt 3. Repo initialisieren.** Wechsle in deinen Projektordner (oder erstelle einen neuen) und führe Folgendes aus: ```bash specify init --here --integration claude ``` Das Flag `--integration claude` wählt Claude Code direkt aus. Ohne dieses Flag fordert Spec Kit dich auf, in einer interaktiven Liste einen Agenten auszuwählen, und fragt möglicherweise auch nach einem Skripttyp (für macOS und Linux kannst du `sh` beibehalten). Wenn der Ordner nicht leer ist, warnt Spec Kit, dass es seine Dateien mit deinen zusammenführt: Committe zuerst deine Arbeit und wiederhole dann den Befehl mit dem Flag `--force`. Anschließend erscheinen im Repo folgende Dateien: ``` .specify/ memory/ constitution.md # project rules, filled in by /speckit-constitution scripts/ templates/ spec-template.md plan-template.md tasks-template.md .claude/ skills/ speckit-constitution/SKILL.md speckit-specify/SKILL.md speckit-clarify/SKILL.md speckit-plan/SKILL.md speckit-checklist/SKILL.md speckit-tasks/SKILL.md speckit-analyze/SKILL.md speckit-implement/SKILL.md speckit-converge/SKILL.md speckit-taskstoissues/SKILL.md ``` **Schritt 4. Claude Code öffnen und die Slash-Befehle prüfen.** Führe das im selben Ordner aus: ```bash claude ``` Gib in der Sitzung `/speckit` ein – die Befehle `speckit-*` sollten in den Vorschlägen erscheinen. Falls nicht, starte Claude Code neu, damit es `.claude/skills/` erneut einliest. Wenn du `CLAUDE.md` bereits im Stammverzeichnis des Projekts hast, lässt Spec Kit sie unangetastet – es funktioniert parallel dazu in `.specify/memory/constitution.md`. Spec Kit funktioniert auch ohne Claude Code (es unterstützt mehr als 30 Agenten), aber dieser Leitfaden behandelt die Einrichtung speziell mit Claude. Wenn du gleich zwei Tools installieren möchtest, findest du separate Anleitungen unter [CLAUDE.md einrichten](https://ailoot.ai/blog/de/claude-md-template/) und [Planmodus in Claude Code](https://ailoot.ai/blog/de/claude-code-plan-mode/). Spec Kit ist der erste Baustein eines „Arbeitsvertrags für Agenten“. Die vollständige Einrichtung umfasst alle drei: einen KI-Klon (deine Methode in Form von Skills und Subagenten), ein Second Brain (die `business/`-Struktur, zu der der Agent jedes Mal zurückkehrt) und Context Engineering (Spec Kit, Planmodus, /compact). Das sind die drei Säulen, ohne die KI halluziniert. ## So schreibst du deine erste Spezifikation (Specify)
Das Wichtigste Spec Kit fordert dich auf, ein Feature in freier Form zu beschreiben, und erweitert diese Beschreibung dann mithilfe einer Vorlage zu einer `spec.md`-Datei: User Stories mit Prioritäten P1/P2/P3, Acceptance Scenarios im Given/When/Then-Format, Functional Requirements (FR-001, FR-002 usw.) und Success Criteria mit messbaren Ergebnissen. An jeder Stelle, an der der Agent unsicher ist, fügt er eine Markierung wie `[NEEDS CLARIFICATION: ...]` ein – diese beantwortest du, bevor du zum Plan übergehst.
Gib in Claude Code Folgendes ein: ``` /speckit-specify ``` Dann bittet dich der Agent um eine Beschreibung des Features. Verwende in diesem Schritt einfache Sprache ohne Fachjargon: ``` Ich möchte ein Registrierungsformular in meiner App. Der Nutzer gibt E-Mail und Passwort ein, erhält eine Bestätigungsmail und landet nach der Bestätigung im Dashboard. Die Bestätigung läuft nach 48 Stunden ab. Ist die E-Mail dann noch unbestätigt, lösche das Konto spätestens 5 Minuten nach dieser Frist. Lösche niemals ein bestätigtes Konto. ``` In diesem Beispiel wurde eine Löschverzögerung von 5 Minuten nach der 48-Stunden-Frist vereinbart. Kläre diese Toleranz für ein echtes Produkt vor Plan. Eine exakt bei 48 Stunden geltende Frist verlangt ein entsprechend strengeres Design samt Tests. Der Agent erstellt `specs/001-registration/spec.md`. Öffne die Datei; die Struktur sieht etwa so aus: ```markdown # Feature Specification: User Registration **Feature Branch**: `001-registration` **Created**: 2026-05-31 **Status**: Draft **Input**: User Description: "I want a registration form..." ## User Scenarios & Testing *(mandatory)* ### Primary User Story As a new user, I want to register an account with email confirmation, so that I can access the dashboard with a verified identity. ### Acceptance Scenarios 1. **Given** I am on the registration page, **When** I submit valid email and password, **Then** I receive a confirmation email within 1 minute. 2. **Given** I clicked the confirmation link within 48 hours, **When** I land on the dashboard, **Then** I see my email confirmed in profile. 3. **Given** Das Konto ist nach 48 Stunden noch unbestätigt, **When** die Bereinigung innerhalb der nächsten 5 Minuten läuft, **Then** wird das Konto gelöscht und die E-Mail für Neuregistrierung frei. 4. **Given** Das Konto ist knapp unter 48 Stunden alt oder bereits bestätigt, **When** die Bereinigung läuft, **Then** wird es nicht gelöscht. ## Requirements *(mandatory)* ### Functional Requirements - **FR-001**: System MUST accept registration via [NEEDS CLARIFICATION: email/password only, or also SSO/OAuth?] - **FR-002**: System MUST send confirmation email within 60 seconds - **FR-003**: Die Bestätigung MUST nach 48 Stunden ablaufen; das System MUST weiterhin unbestätigte Konten spätestens 5 Minuten nach dieser Frist löschen und MUST NOT bestätigte Konten löschen - **FR-004**: System MUST log all registration attempts for [NEEDS CLARIFICATION: how long do we retain logs - 30 days, 90 days, forever?] ### Key Entities - User: email, password_hash, email_verified_at, created_at, deleted_at - ConfirmationToken: token, user_id, expires_at, used_at ## Success Criteria *(mandatory)* - **SC-001**: 95% of confirmation emails delivered within 60 seconds (p95) - **SC-002**: 0 accidental deletions of confirmed accounts - **SC-004**: Keine Löschung vor 48 Stunden; jedes berechtigte unbestätigte Konto wird unter geprüfter Last bis zum Alter 48 Stunden 5 Minuten gelöscht - **SC-003**: Registration completion rate > 60% (from form open to dashboard) ``` Beachte die Markierungen `[NEEDS CLARIFICATION: ...]`. Spec Kit fügt sie gezielt an allen Stellen ein, an denen der Agent aus deinem Text keine eindeutige Antwort erhalten hat. Bevor du zur Plan-Phase übergehst, musst du sie entweder manuell in `spec.md` beantworten oder `/speckit-clarify` ausführen; dann geht der Agent die unklaren Punkte durch und stellt Fragen im Dialog. In Spec Kit ersetzt der integrierte Befehl `/speckit-clarify` das gesprochene „Stell mir Fragen“. Die Wirkung ist dieselbe: Du gehst erst dann zum Plan über, wenn keine Markierungen `[NEEDS CLARIFICATION]` mehr in `spec.md` stehen. In `spec.md` sollten keine Technologien stehen. Keine Erwähnungen von React, Postgres, Prisma oder Redis. Die Spezifikation beschreibt, was das System aus Sicht der Nutzer und des Geschäfts tut. Der Technologie-Stack kommt in der nächsten Phase. ## Was macht Claude in der Plan-Phase?
Das Wichtigste Der Befehl `/speckit-plan` nimmt die fertige Spezifikation und erstellt einen technischen Plan: welche Technologien verwendet werden sollen, welche Architektur, welche Module, Dateneinheiten und API-Verträge. Der Plan wird in `specs/###-feature/plan.md` geschrieben, Verträge werden in einen separaten Ordner `contracts/` exportiert und das Datenmodell kommt in `data-model.md`. In diesem Schritt kennt Claude deinen Stack bereits aus der CLAUDE.md und der Constitution, sodass der Plan zum bestehenden Projekt passt, statt vorzuschlagen: „Schreiben wir doch alles in Rust neu.“
Wenn `spec.md` fertig ist, führe Folgendes aus: ``` /speckit-plan ``` Optional kannst du Technologiehinweise direkt im Befehl übergeben: ``` /speckit-plan Next.js App Router, Prisma, PostgreSQL, Resend for email ``` Claude liest drei Quellen: deine `spec.md`, deine `CLAUDE.md` (oder `memory/constitution.md`) und den vorhandenen Code im Repo. Die Ausgabe ist eine `plan.md` mit ungefähr folgender Struktur: ```markdown # Implementation Plan: User Registration ## Technical Context - Framework: Next.js 14 App Router - Database: PostgreSQL via Prisma - Email: Resend (single transport) - Validation: Zod schema in shared lib - Auth: NextAuth.js with credentials provider ## Architecture Decisions ### 1. Token storage Tokens stored in DB (table ConfirmationToken), not in JWT. Reason: need server-side revoke on email re-register. ### 2. Email delivery Async via cron `/api/cron/send-confirmation` triggered immediately after registration. Retries handled by Resend. ### 3. Auto-delete cron Führe `/api/cron/cleanup-unconfirmed` jede Minute aus. Lösche nur Zeilen mit created_at <= NOW() - INTERVAL '48 hours' AND email_verified_at IS NULL. Das präzisierte Beispiel erlaubt höchstens 5 Minuten Löschverzögerung. Prüfe Schedulerverzug und Abschlussdauer gegen diese Grenze. Eine Grenzüberschreitung ist ein Fehler, kein erfolgreicher täglicher Cleanup. ## Data Model See data-model.md ## API Contracts See contracts/ - POST /api/auth/register - POST /api/auth/confirm - GET /api/auth/resend-confirmation ## Implementation Phases 1. Database migration (Prisma schema + migration file) 2. API routes (3 endpoints) 3. UI: registration form + confirmation success page 4. Cron jobs (send + cleanup) 5. Email template 6. Integration tests ``` `data-model.md` beschreibt die Entitäten und ihre Beziehungen. `contracts/` enthält API-Vertragsstubs (entweder OpenAPI-YAML oder TypeScript-Request-/Response-Typen). Das ist kein Code – es ist eine Absichtserklärung, die Claude später in echte Routen umsetzt. Der Hauptvorteil der Plan-Phase ist der saubere Kontext. Claude versucht nicht, Spezifikation und Implementierung gleichzeitig im Kopf zu behalten. Zuerst denkt es die Dinge durch, hält die Entscheidung in einer Datei fest und macht dann weiter. Danach gibt es den optionalen Befehl `/speckit-analyze`. Er wird nach der Tasks-Phase und vor Implement ausgeführt: Er prüft die Kombination aus `spec.md + plan.md + tasks.md` auf Widersprüche und kontrolliert, ob alle Anforderungen der Spezifikation durch Plan und Aufgaben abgedeckt sind. Er bearbeitet keine Dateien, sondern erstellt nur einen Bericht. Im Wesentlichen ist es eine formale Plausibilitätsprüfung vor der Implementierung. ## So unterteilst du die Arbeit in Aufgaben (Tasks)
Das Wichtigste Der Befehl `/speckit-tasks` unterteilt den Plan in konkrete Aufgaben. Jede Aufgabe enthält Abhängigkeiten, eine Schätzung und eine Markierung, ob sie „parallelisierbar“ oder „streng sequenziell“ ist. Die Ausgabe ist `tasks.md`, in der Aufgaben das Checklistenformat `[ ] T-001: ...` verwenden. Anschließend kannst du diese Aufgaben mit `/speckit-implement` zur Umsetzung übergeben oder mit `/speckit-taskstoissues` in GitHub-Issues umwandeln – und sie auf ein Team oder mehrere parallele Claude-Code-Sitzungen verteilen.
Sobald du `spec.md` und `plan.md` hast, führe Folgendes aus: ``` /speckit-tasks ``` Claude erweitert den Plan zu `tasks.md`: ```markdown # Tasks: User Registration ## Phase 1: Database (no dependencies) - [ ] T-001: Add User model to prisma/schema.prisma (parallel-safe) - [ ] T-002: Add ConfirmationToken model to prisma/schema.prisma (after T-001) - [ ] T-003: Generate migration `add-user-registration` (after T-002) ## Phase 2: API contracts (no dependencies) - [ ] T-004: Create Zod schemas in shared/validation/auth.ts - [ ] T-005: Define TypeScript types in shared/types/auth.ts (after T-004) ## Phase 3: Routes (depends on Phase 1+2) - [ ] T-006: Implement POST /api/auth/register - [ ] T-007: Implement POST /api/auth/confirm - [ ] T-008: Implement GET /api/auth/resend-confirmation ## Phase 4: UI (parallel with Phase 3) - [ ] T-009: Build /register page with form - [ ] T-010: Build /register/confirm/[token] page - [ ] T-011: Build /register/success page ## Phase 5: Cron + integration (depends on Phase 3+4) - [ ] T-012: Cron /api/cron/send-confirmation - [ ] T-013: Cron /api/cron/cleanup-unconfirmed - [ ] T-014: Email template registration-confirmation.tsx - [ ] T-015: Integrationstests (Playwright): Bereinigung knapp vor 48h, genau bei 48h, Löschung bis 48h 5m, Fehler bei verspätetem Job und Schutz bestätigter Konten ## Notes - T-001, T-004, T-009-T-011 are parallel-safe (different files) - T-002 conflicts with T-001 (same file: schema.prisma) - run sequentially - T-006 needs T-003 (migration applied) and T-005 (types) ``` Beachte die Markierungen `parallel-safe` und `after T-NNN`. Das ist der Abhängigkeitsgraph, mit dem du später mehrere Phasen parallel ausführen kannst. Die gesamte Spec-Kit-Beschleunigung beruht auf diesem Mechanismus: Einige Aufgaben können gleichzeitig an fünf verschiedene Claude-Code-Sitzungen übergeben werden, während andere streng nacheinander ausgeführt werden müssen. Spec Kit erledigt das automatisch mit einem einzigen Befehl, direkt nach der Installation. Der optionale Befehl `/speckit-taskstoissues` nimmt `tasks.md` und erstellt GitHub-Issues aus der Liste, jedes mit einem Link zurück zu `spec.md`. Das ist nützlich, wenn du im Team arbeitest oder den Fortschritt über GitHub Projects verfolgen möchtest. ## So implementierst du mit Subagenten (Implement)
Das Wichtigste Die abschließende Phase `/speckit-implement` startet die Implementierung. Claude arbeitet `tasks.md` von oben nach unten ab und markiert erledigte Aufgaben mit `[x]`. Du kannst mehrere parallele Claude-Code-Sitzungen gleichzeitig ausführen – eine pro Phase. Innerhalb jeder Sitzung startet Claude Subagenten für verschiedene Arten von Arbeit: einen Reviewer für den Code, einen Tester für Prüfungen und einen Dokumentationsautor für die README. Das ist der Ansatz der „1000 parallelen Subagenten“, über den Anthropic bei der Veröffentlichung von Opus 4.8 schrieb – in Spec Kit ist es einfach eine Arbeitsweise und kein separates Produkt.
``` /speckit-implement ``` Claude beginnt mit der ersten Aufgabe in `tasks.md`. Jede Aufgabe durchläuft einen kurzen Zyklus: relevante Dateien lesen, einen Diff schreiben, die Tests ausführen und `[x]` markieren. Subagenten werden bei Bedarf automatisch aufgerufen: einer für die Codeprüfung, einer für den Linter und einer zur Prüfung auf Regressionen. Und gesondert zum Thema Regeln: In Spec Kit wird dieser Zyklus formalisiert. Du hast `spec.md` als maßgebliche Grundlage, `plan.md` für technische Entscheidungen und `tasks.md` als Checkliste. Wenn Claude an irgendeinem Schritt vom Kurs abkommt, kehrst du zur Spezifikation zurück und sagst: „Das entspricht nicht FR-003; mach es noch einmal.“ Keine langen Prompts mit „Denk daran, worüber wir gesprochen haben ...“ – der gesamte Verlauf steht in den Dateien. Wenn du [Dynamic Workflows in Opus 4.8](https://ailoot.ai/blog/de/claude-code-dynamic-workflows/) angebunden hast, kannst du Spec Kit vollständig automatisiert einsetzen: Ein Befehl `/speckit-implement`, und Claude parallelisiert die Arbeit, führt die Ergebnisse zusammen und prüft sie. Das Limit liegt bei 1000 Subagenten gleichzeitig. Für die meisten Features reichen 10-30. Wenn alle `[x]`-Kästchen markiert sind und die Prüfung im nächsten Abschnitt „Converged“ meldet, überprüfst du den PR (oder mehrere PRs, falls es viele Aufgaben gibt) und mergst ihn. Die Artefakte – `spec.md`, `plan.md`, `tasks.md` – bleiben als Dokumentation des Features im Repo. Ein Jahr später musst du die Logik nicht aus dem Code zurückentwickeln. ## So prüfst du, ob der Agent etwas übersehen hat (Converge)
Das Wichtigste Nach Implement hat die aktuelle Version von Spec Kit einen Prüfschritt namens `/speckit-converge`. Der Agent vergleicht den fertigen Code mit `spec.md`, `plan.md` und `tasks.md`. Wenn alles übereinstimmt, antwortet er mit „Converged“ und lässt die Dateien unverändert. Wenn er Auslassungen findet, fügt er sie als neue Aufgaben am Ende von `tasks.md` hinzu. Führe anschließend erneut `/speckit-implement` und danach wieder `/speckit-converge` aus, bis du „Converged“ erhältst.
``` /speckit-converge ``` Zuerst gibt der Agent eine Zusammenfassung seiner Feststellungen mit Schweregraden aus, dann folgt eines von zwei Ergebnissen. „Converged“ bedeutet, dass es keine Auslassungen gibt, `tasks.md` bytegenau unverändert bleibt und du mit der Prüfung fortfahren kannst. „Tasks appended“ bedeutet, dass Auslassungen gefunden und im Abschnitt Convergence in `tasks.md` ergänzt wurden. Der Agent teilt dir mit, wie viele es sind. Converge bearbeitet oder löscht keinen Code; es schreibt ausschließlich neue Aufgaben in `tasks.md`. Du kannst den Befehl also unbesorgt ausführen, aber erst, nachdem `/speckit-implement` die aktuelle `tasks.md` abgearbeitet hat. Bei jedem weiteren Durchlauf werden weniger Auslassungen gefunden. ## Worin unterscheidet sich Spec Kit von CLAUDE.md und dem Planmodus?
Das Wichtigste Das ist eine häufige Frage beim Vergleich dieser Tools. Die Kurzfassung: CLAUDE.md ist der „Arbeitsvertrag“ des Agenten und die einzige maßgebliche Grundlage für das gesamte Projekt. Der Planmodus ist eine einmalige Planung vor einer konkreten Aufgabe. Spec Kit bildet den vollständigen Lebenszyklus eines Features ab: von der Beschreibung bis zur Implementierung, mit Artefakten im Repo. Sie ersetzen einander nicht, sondern bilden gemeinsam ein dreischichtiges System: globaler Kontext (CLAUDE.md) → Projektkontext (Spec-Kit-Constitution) → Featurekontext (spec.md + plan.md + tasks.md).
Vergleiche sie anhand von 5 Merkmalen: | Merkmal | CLAUDE.md | Planmodus | Spec Kit | |----|----|----|----| | Wann es läuft | Jede Sitzung | Auf Anfrage (Shift+Tab oder /plan) | Über den Slash-Befehl /speckit-* | | Gültigkeitsdauer | Gesamtes Projekt | Eine Sitzung | Ein Feature | | Wo es liegt | Repo-Stammverzeichnis | Im Claude-Kontext | `specs/###-feature/*` | | Was es speichert | Stack, Regeln, Glossar | Aktueller Plan + Beobachtungen | spec + plan + tasks + Verträge | | Vorlage | Freie Form (Repo-Regeln) | Keine | Strukturiertes Markdown | | Beste Rolle | Projektregeln und Stack | Gegenprüfung vor einer größeren Änderung | Vollständiger Feature-Zyklus: vom WAS bis zum CODE | In den Begriffen von Spec Kit ist das `.specify/memory/constitution.md`. Bei der Initialisierung kann Spec Kit entweder deine vorhandene CLAUDE.md als Grundlage für die Constitution verwenden oder daneben eine separate Datei erstellen. Ich behalte CLAUDE.md üblicherweise als globalen „Vertrag“ (Stack, Glossar, Deployment-Protokoll) und verwende die Spec-Kit-Constitution für workflowbezogene Regeln – zum Beispiel: „Alle Formulare werden mit Zod validiert; keine manuellen Prüfungen.“ Die Verbindung zum Planmodus ist einfacher. Der Planmodus ist ein schneller Modus „Planen, bevor man Code schreibt“ innerhalb einer Sitzung. Er eignet sich gut für kleine Änderungen (einen Fehler beheben, eine Funktion refaktorisieren). Bei einem großen Feature ist der Planmodus im Nachteil, weil das Kontextfenster einer Sitzung für einen 3000 Zeilen langen Plan zu klein ist – wie ich in der Live-Sitzung direkt erläutere: Spec Kit ist ein konkretes Context-Engineering-Tool. Es verlagert das „Architektur-Tischtuch“ aus dem Chat in Dateien. `Spec.md` bleibt im Repo, und jede neue Claude-Sitzung liest sie erneut – du musst dich nicht wiederholen. Eine Einrichtung für ein großes Projekt: 1. **CLAUDE.md** – Stack, Glossar und Dinge, die zu vermeiden sind. Sie liegt im Stammverzeichnis. 2. **.specify/memory/constitution.md** für Spec Kit – Regeln speziell für diesen Workflow. 3. **specs/001-feature-A/spec.md, plan.md, tasks.md** – erstes Feature. 4. **specs/002-feature-B/spec.md, plan.md, tasks.md** – zweites Feature. 5. Für die tägliche Arbeit entweder `/speckit-implement` (für fertige Aufgaben) oder `/plan` (eine schnelle Gegenprüfung vor einer Änderung). ## Welche Fälle aus der Praxis funktionieren?
Das Wichtigste Der Spec-Kit- und SDD-Ansatz hat bei großen Unternehmen bereits messbare Ergebnisse erzielt. AWS in einem Wirkstoffforschungsprojekt: 95 % der Geschäftslogik aus einer Spezifikation generiert, mehr als 80 Stunden bei einem Feature eingespart. Rackspace Technology: 52 Wochen Arbeit auf 3 Wochen verdichtet, Effizienzsteigerung von 90 %. Spec Kit selbst sammelte in 8 Monaten 107.000 GitHub-Sterne.
Konkrete Fälle: - **AWS Kiro – Wirkstoffforschungsagent.** In einem [Blogbeitrag von AWS Industries](https://aws.amazon.com/blogs/industries/from-spec-to-production-a-three-week-drug-discovery-agent-using-kiro/) vom 18. Februar 2026 beschreibt das Team das Projekt TargetID. Drei Entwickler, drei Wochen, ein Wirkstoffforschungsagent. Die Zahlen im Artikel: Kiro generierte mehr als 95 % des Codes für die Geschäftslogik und sparte mehr als 80 Entwicklungsstunden. Außerdem: „Die von Kiro verfasste README-Dokumentation sparte uns schätzungsweise 8 Stunden“ und „40 % weniger iterative Prompt-und-Fix-Zyklen“. - **Rackspace Technology.** Im selben AWS-Blog berichtet Rackspace: „52 Wochen geschätzte Arbeit in nur 3 Wochen abgeschlossen“ und „Effizienzsteigerung von 90 %“. Das ist kein kleines Feature mehr – es ist ein vollständiges Unternehmensprojekt. Für dich als Leser bedeutet das: Der Ansatz ist keine Theorie. Seriöse Teams setzen ihn bereits in der Produktion ein. ## Wann eignet sich Spec Kit NICHT?
Das Wichtigste Spec Kit eignet sich nicht für jede Situation. Es gibt drei klare Gegenbereiche: kleine Änderungen (einen Fehler beheben, eine Variable umbenennen), Experimente und Prototypen (bei denen gerade das Nichtwissen, was man möchte, den Kern von Vibe Coding ausmacht) und Legacy-Code mit komplexem Zustand (bei dem die Spezifikation schneller veraltet, als du sie fertigschreiben kannst). Es gibt ernst zu nehmende Kritiker dieser Fälle. Ihre Argumente solltest du kennen, damit du keine Zeit mit Spezifikationen verschwendest, die nicht helfen.
**Nicht geeignet #1 – kleine Änderungen.** Wenn die Aufgabe lautet „eine Variable umbenennen“, „einen Tippfehler im Text beheben“ oder „ein Log hinzufügen“, dauert der Durchlauf Specify → Plan → Tasks länger als die Änderung selbst. Bei kleinen Änderungen ist der Planmodus oder einfach ein direkter Prompt in Claude Code schneller. **Nicht geeignet #2 – Live-Experimente.** Wenn du noch nicht weißt, was du möchtest, und die Oberfläche „erkunden“ oder schnell einen Prototyp zusammenstellen musst, um zu sehen, „ob es ankommt“, ist eine Spezifikation sinnlos. Der Wert liegt gerade darin, dass du improvisierst. Beim „Spielen mit einer Idee“ funktioniert Vibe Coding genau deshalb und nicht eine Spezifikation. **Nicht geeignet #3 – Legacy-Code mit komplexem Zustand.** Ein starkes Gegenargument: Die Realität verändert sich schneller als Spezifikationen. Als Beispiel dient die Abrechnung von Abonnements: Das Team beschrieb Abrechnungszyklen und Steuerregeln, doch eine Woche später verlangte die Finanzabteilung europäische Mehrwertsteuer – die Spezifikation war schon vor der Veröffentlichung veraltet. Wenn sich Geschäftslogik schnell weiterentwickelt, wird die Pflege von Spezifikationen zur Last. Ein zusätzliches Risiko ist ein falsches Gefühl der Kontrolle: Strukturen sind elegant, aber Agenten ignorieren Anweisungen oft oder befolgen Vorlagen im Gegenteil zu wörtlich. Das Ergebnis ist Code, der strukturell korrekt ist, aber nicht zu deinem konkreten Repo passt – die Spezifikation garantiert nicht, dass der Agent sie so verstanden hat, wie du es beabsichtigt hast. Im April 2026 warnten Branchenanalysten vor Wasserfallmodellen: Eine große Spezifikation vor dem Code zu schreiben, ist ein Weg, der die Branche schon einmal versenkt hat – damals, in der Zeit von Anforderungen mit 200 Seiten. Seitdem gehen Entwickler mit diesem Ansatz vorsichtig um, und diese Vorsicht ist berechtigt. **Was ist zu tun?** Ich schlage eine einfache Regel vor: Größe des Features im Verhältnis zur Zeit, die das Schreiben einer Spezifikation kostet. Wenn ein Feature weniger als 2 Stunden für die Umsetzung benötigt, schreibe keine Spezifikation – der Planmodus ist schneller. Wenn ein Feature eine Woche dauert, verwende unbedingt Spec Kit; die Zeitersparnis wird die einstündige Spezifikation um das Fünffache aufwiegen. Bei allem zwischen 2 Stunden und einer Woche entscheide nach eigenem Ermessen. Ich persönlich schreibe aber selbst für Features, die einen halben Tag dauern, eine Spezifikation, weil das Artefakt im Repo mehr wert ist als die eingesparten 30 Minuten. ## Wie geht es weiter: Spec Kit in dein Projekt integrieren?
Das Wichtigste Der einfachste erste Schritt ist, Spec Kit an einem neuen kleinen Feature auszuprobieren, nicht am gesamten bestehenden Projekt. Installiere es, initialisiere es in einem Repo, führe `/speckit-specify` für ein Feature aus und sieh dir die Artefakte an. In ein bis zwei Wochen bekommst du ein Gefühl dafür, wann du darauf umsteigen und wann du bei schnellen Prompts bleiben solltest. Die vollständige Methode kombiniert CLAUDE.md + Spec Kit + Skills + Subagenten.
Ein konkreter Plan für die nächsten 7 Tage: - **Tag 1.** Installiere uv und Spec Kit (5-10 Minuten). Prüfe, ob die Befehle `/speckit-*` in Claude Code erschienen sind. Versuche nicht, sie auf ein bestehendes Projekt anzuwenden – beginne mit einem neuen. - **Tag 2.** Wähle ein echtes Feature aus, das du entwickeln möchtest. Führe `/speckit-specify` mit einer freien Beschreibung aus. Öffne `spec.md`, lies sie und beantworte alle Markierungen `[NEEDS CLARIFICATION]`. Wechsle nicht überstürzt zum Plan. - **Tag 3.** Führe `/speckit-plan` mit Hinweisen zu deinem Stack aus. Lies `plan.md`, besonders den Abschnitt Architecture Decisions. Wenn dir etwas nicht zusagt, bearbeite es manuell. - **Tag 4-5.** Führe `/speckit-tasks` aus, danach `/speckit-analyze`, um die Kombination aus Spezifikation, Plan und Aufgaben zu prüfen, und anschließend `/speckit-implement`. Beobachte, wie Claude die Aufgaben in `tasks.md` mit `[x]` markiert. Vielleicht bleibt der Agent irgendwo stecken – das ist normal. Kehre zu `spec.md` zurück, präzisiere die Anforderung und starte `/speckit-implement` mit einer konkreten Aufgabe erneut. Wenn alle Aufgaben erledigt sind, führe `/speckit-converge` aus und wiederhole die Folge aus Implement und Converge, bis der Agent mit „Converged“ antwortet. - **Tag 6-7.** Prüfe den PR (oder mehrere PRs). Merge ihn. Lies `spec.md` und `plan.md` – sie sind deine Dokumentation des Features für das kommende Jahr. Was ich parallel dazu lesen würde: - [CLAUDE.md 2026 einrichten](https://ailoot.ai/blog/de/claude-md-template/) – die Grundlage für Spec Kits Constitution. - [Planmodus in Claude Code](https://ailoot.ai/blog/de/claude-code-plan-mode/) – eine schnelle Alternative für kleine Aufgaben. - [Context Engineering 2026](https://ailoot.ai/blog/de/context-engineering/) – warum Spec Kit überhaupt funktioniert. - [Skills, Subagents, MCP oder Plugins](https://ailoot.ai/blog/de/skills-subagents-mcp-plugins-claude-code/) – was du deinem Spec-Kit-Workflow hinzufügen kannst. - [Dynamic Workflows in Claude Code](https://ailoot.ai/blog/de/claude-code-dynamic-workflows/) – wie du während der Implement-Phase viele Subagenten gleichzeitig startest.
### Quellen - [GitHub Spec Kit – Repository](https://github.com/github/spec-kit) - [GitHub Spec Kit – offizielle Dokumentation](https://github.github.com/spec-kit/) - [Spec-Driven Development – offizieller Methodentext](https://github.com/github/spec-kit/blob/main/spec-driven.md) - [Spec-Vorlage – GitHub](https://github.com/github/spec-kit/blob/main/templates/spec-template.md) - [AWS Industries Blog – Von der Spezifikation zur Produktion: Kiro-Wirkstoffforschungsagent (18. Februar 2026)](https://aws.amazon.com/blogs/industries/from-spec-to-production-a-three-week-drug-discovery-agent-using-kiro/) - [Claude-Code-Dokumentation – Subagenten](https://code.claude.com/docs/en/sub-agents) - [Claude-Code-Dokumentation – Skills](https://code.claude.com/docs/en/skills) - [Claude-Code-Dokumentation – Befehle](https://code.claude.com/docs/en/commands)
Der vollständige Kontext-Workflow: KI-Klon + Second Brain + Context Engineering. Weitere Materialien findest du auf [Ailoot](https://ailoot.ai/). ## Fragen und Antworten ### Warum genügt ein täglicher Cleanup nicht für eine Löschfrist von 48 Stunden? Ein Konto kann die Frist kurz nach dem Tageslauf erreichen und dann fast einen weiteren Tag warten. Kläre die tolerierte Verzögerung in der Spezifikation, wähle einen passenden Zeitplan und teste 48-Stunden-Schwelle sowie maximale Verzögerung. ### Was tue ich bei einem Widerspruch zwischen plan.md und spec.md? Gehe vor der Umsetzung zur Anforderung zurück und kläre die Abweichung. Aktualisiere Spezifikation, Plan, Aufgaben und Abnahmeprüfungen gemeinsam. Prüfe danach mit Analyze und Implementierungsprüfungen dasselbe vereinbarte Verhalten. ## Ailoot · Das Unternehmen und sein Projektportfolio Ailoot baut auf bewährte Betriebserfahrung, einen großen Kundenstamm, stabilen Service und kontinuierliche KPI-Kontrolle. Das Unternehmen und sein Projektportfolio: Millionen von Kunden; monatliche Umsätze in Milliardenhöhe. Ailoot nutzt diese Betriebserfahrung für den API-Zugang zu KI-Funktionen in Kundenprodukten, Agenten, Anwendungen und Automatisierungen.