Spec-Driven Development (SDD)-Umgebungen vergleichen: SpecKit vs. Kiro

Einführung

Dieser Artikel vergleicht zwei repräsentative Ansätze zur Implementierung von „Spec-Driven Development (SDD)", einer Methodik, die in letzter Zeit erheblich an Aufmerksamkeit gewonnen hat.

• VSCode + GitHub Copilot + SpecKit: Einem bestehenden Editor ein SDD-Toolkit hinzufügen
• Kiro IDE: Eine All-in-One-IDE mit integrierten SDD-Funktionen

Was ist Spec-Driven Development (SDD)?

Bei der traditionellen Entwicklung steht der Code im Mittelpunkt und Spezifikationen sind ergänzend. SDD kehrt dies um, indem Spezifikationen als ausführbare Ergebnisse behandelt werden.

Hauptvorteile von SDD

• Klärung und Dokumentation von Anforderungen
• Präzise Anweisungen für KI-Agenten
• Reduzierte Fehlanpassungen zwischen Teams
• Unterstützung für iterative Verbesserungsprozesse

Umgebung 1: VSCode + GitHub Copilot + SpecKit

Übersicht

SpecKit ist ein Open-Source-Toolkit zur Implementierung von SDD in bestehenden Entwicklungsumgebungen. Von GitHub bereitgestellt, ermöglicht es die Interaktion mit KI-Agenten durch Slash-Befehle.

Einrichtung

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

# Neues Projekt initialisieren
specify init my-project --ai copilot

# Oder in einem bestehenden Projekt
specify init . --ai copilot

Entwicklungsfluss

1. Projektverfassung festlegen

/speckit.constitution Create principles focused on code quality, 
testing standards, user experience consistency, and performance requirements

Dieser Befehl generiert .specify/memory/constitution.md und definiert projektweite Leitlinien.

2. Spezifikationen erstellen

/speckit.specify Build an application that can help me organize my photos 
in separate photo albums. Albums are grouped by date and can be re-organized 
by dragging and dropping on the main page.

Generierte Dateien:

• .specify/specs/001-feature-name/spec.md: Feature-Anforderungen und User Stories

3. Technischen Implementierungsplan erstellen

/speckit.plan The application uses Vite with minimal number of libraries. 
Use vanilla HTML, CSS, and JavaScript as much as possible.

Generierte Dateien:

• plan.md: Technische Architektur
• data-model.md: Datenmodell-Definition
• contracts/api-spec.json: API-Spezifikationen
• research.md: Technische Forschungsdokumentation

4. Aufgabenzerlegung

/speckit.tasks

Generierte Dateien:

• tasks.md: Implementierungsaufgabenliste (mit Abhängigkeiten und Markierungen für parallele Ausführung)

5. Implementierung ausführen

/speckit.implement

Die Implementierung erfolgt sequenziell basierend auf der Aufgabenliste.

SpecKit Prompt File-Details

SpecKit generiert mehrere Prompt-Dateien im Verzeichnis .github/prompts/.

speckit.constitution.prompt.md

Zweck: Grundlegende Prinzipien und Entwicklungsleitlinien für das Projekt definieren

Struktur:

---
description: Create or update project governing principles
---

# Project Constitution

Create a comprehensive constitution document that includes:

1. **Code Quality Standards**
   - Naming conventions
   - Documentation requirements
   - Code review processes

2. **Testing Standards**
   - Unit test coverage requirements
   - Integration test strategies
   - Test documentation

3. **Architecture Principles**
   - Design patterns to follow
   - Technology stack constraints
   - Performance requirements

4. **User Experience Guidelines**
   - Accessibility standards
   - Responsive design requirements
   - Internationalization considerations

Merkmale:

• KI-Agenten referenzieren dieses Dokument in allen nachfolgenden Phasen
• Erzwingt projektspezifische Best Practices
• Stellt Konsistenz zwischen Teams sicher

speckit.specify.prompt.md

Zweck: Feature-Anforderungen im User-Story-Format strukturieren

Struktur:

---
description: Define requirements and user stories
---

# Specification Template

## User Stories

**As a** [user type]
**I want** [goal]
**So that** [benefit]

### Acceptance Criteria
- [ ] Criterion 1
- [ ] Criterion 2

## Functional Requirements

### FR-001: [Requirement Name]
**Priority**: High/Medium/Low
**Description**: Detailed requirement description
**Dependencies**: [Other requirements]

Generierungsprozess:

1. Natürlichsprachliche Beschreibung vom Benutzer parsen
2. In User Stories umwandeln
3. Akzeptanzkriterien klären
4. Funktionale Anforderungs-IDs zuweisen

speckit.plan.prompt.md

Zweck: Technische Implementierungspläne detaillieren

Struktur:

---
description: Create technical implementation plans
---

# Implementation Plan

## Technology Stack
- Frontend: [Framework/Library]
- Backend: [Framework]
- Database: [Type]
- Deployment: [Platform]

## Architecture Overview
[Systemarchitekturdiagramme, Komponentendiagramme]

## Data Model
[Entity-Relationship-Diagramme, Tabellendefinitionen]

## API Specifications
[Endpunktdefinitionen, Request/Response-Formate]

## Implementation Phases
1. Phase 1: [Kernfunktionen]
2. Phase 2: [Erweiterte Funktionen]

## Technical Considerations
- Sicherheitsanforderungen
- Performance-Optimierung
- Skalierbarkeitsüberlegungen

Merkmale:

• Hält sich an constitution.md-Prinzipien
• Löst spec.md-Anforderungen technisch
• Vergleicht mehrere Technologieoptionen

speckit.tasks.prompt.md

Zweck: In konkrete, implementierbare Aufgaben zerlegen

Struktur:

---
description: Generate actionable task lists
---

# Task Breakdown

## User Story: [Story ID]

### Task 1: [Task Name]
**File**: `src/components/Feature.tsx`
**Type**: Implementation
**Dependencies**: None
**Parallel**: [P] (if parallelizable)
**Description**: Detailed task description
**Acceptance**: How to verify completion

### Task 2: [Task Name]
**File**: `tests/Feature.test.tsx`
**Type**: Testing
**Dependencies**: Task 1

Generierungsregeln:

• Abhängigkeiten explizit verwalten
• Dateipfade konkret angeben
• Test-Driven Development (TDD)-Reihenfolge berücksichtigen
• Aufgaben markieren, die parallel ausgeführt werden können

Beispiel generierter Dokumente

In einem tatsächlichen Projekt sieht die Verzeichnisstruktur so aus:

my-project/
├── .specify/
│   ├── memory/
│   │   └── constitution.md          # Projektprinzipien
│   ├── specs/
│   │   └── 001-photo-albums/
│   │       ├── spec.md               # Feature-Spezifikationen
│   │       ├── plan.md               # Implementierungsplan
│   │       ├── tasks.md              # Aufgabenliste
│   │       ├── data-model.md         # Datenmodell
│   │       ├── contracts/
│   │       │   └── api-spec.json    # API-Spezifikationen
│   │       └── research.md           # Technische Forschung
│   ├── scripts/
│   │   ├── create-new-feature.sh
│   │   └── setup-plan.sh
│   └── templates/
│       ├── spec-template.md
│       ├── plan-template.md
│       └── tasks-template.md
├── .github/
│   └── prompts/
│       ├── speckit.constitution.prompt.md
│       ├── speckit.specify.prompt.md
│       ├── speckit.plan.prompt.md
│       ├── speckit.tasks.prompt.md
│       ├── speckit.implement.prompt.md
│       ├── speckit.clarify.prompt.md
│       └── speckit.analyze.prompt.md
└── src/
    └── [Implementierungsdateien]

Vorteile

✅ Open Source: Kostenlos unter MIT-Lizenz verwendbar
✅ Flexibilität: Unterstützt mehrere KI-Agenten (Claude, Gemini, Copilot usw.)
✅ Schrittweise Einführung: Kann schrittweise beginnend mit benötigten Funktionen eingeführt werden

Nachteile

❌ Manuelle Einrichtung: Anfangskonfiguration erfordert mehrere Schritte
❌ Integrationskomplexität: Mehrere Tools müssen kombiniert werden
❌ UI-Erfahrung: Befehlszeilenorientiert mit begrenztem visuellem Feedback
❌ Lernkurve: Rolle und Reihenfolge jedes Befehls müssen verstanden werden

Umgebung 2: Kiro IDE

Übersicht

Kiro ist eine Agentic IDE, die vom Prototyp bis zur Produktion unterstützt und nativ integrierte SDD-Funktionen hat.

Einrichtung

1. IDE von kiro.dev herunterladen
2. Installieren und starten
3. Kann VS Code-Einstellungen und Plugins automatisch importieren

Entwicklungsfluss

1. Steering Docs generieren

Wählen Sie „Generate Steering Docs" aus dem Kiro-Panel, um folgendes in .kiro/steering/ zu generieren:

• Projekttechnologie-Stack-Informationen
• Coding-Konventionen
• Workflow-Leitlinien

2. Drei Phasen der Spec-Erstellung

Anforderungsphase

User Stories und Akzeptanzkriterien im EARS-Format (Easy Approach to Requirements Syntax) beschreiben:

WHEN [Bedingung/Ereignis]
THE SYSTEM SHALL [erwartetes Verhalten]

Generierte Datei: .kiro/specs/feature-name/requirements.md

Design-Phase

Technische Architektur und Sequenzdiagramme dokumentieren:

Generierte Datei: .kiro/specs/feature-name/design.md

Aufgaben-Phase

Detaillierten Plan für Implementierungsaufgaben:

Generierte Datei: .kiro/specs/feature-name/tasks.md

3. Automatisierung mit Hooks

Ereignisgesteuerte Automatisierung, die automatisch Aufgaben als Reaktion auf Dateiänderungen ausführt:

Beispiel: „Beim Speichern einer React-Komponente automatisch Testdateien generieren"

{
  "hooks": [
    {
      "trigger": "onFileSave",
      "pattern": "**/*.tsx",
      "action": "generateTests"
    }
  ]
}

Kiro-Dokumentstruktur

my-project/
├── .kiro/
│   ├── steering/
│   │   ├── tech-stack.md
│   │   ├── coding-standards.md
│   │   └── workflows.md
│   └── specs/
│       └── photo-albums/
│           ├── requirements.md    # EARS-Format-Anforderungen
│           ├── design.md          # Architekturdesign
│           └── tasks.md           # Implementierungsaufgaben
└── src/
    └── [Implementierungsdateien]

Vorteile

✅ Integrierte Erfahrung: Alle Funktionen nativ in der IDE integriert
✅ Visuelle UI: Visuelle Verwaltung von Spec-Listen und Aufgabenstatusanzeige
✅ Automatisierung: Hintergrundaufgabenausführung mit Hooks

Nachteile

❌ Dedizierte IDE erforderlich: Migration von bestehenden Editoren notwendig
❌ Vendor Lock-in: Abhängigkeit von Kiro-spezifischen Funktionen

Detaillierte Vergleichstabelle

Nutzungsempfehlungen

Wann SpecKit wählen

1. Bestehende VSCode-Umgebung beibehalten

   • Umfangreiche Plugins und Einstellungen wie gewohnt verwenden
   • Editor-Migrationskosten vermeiden

2. Gesamtes Team ist neu bei SDD

   • Schrittweise mit befehlsbasiertem Ansatz lernen
   • Dokumente einfach über Git teilen

3. Mehrere KI-Agenten ausprobieren

   • Zwischen Claude, Gemini, Copilot usw. wechseln
   • Vendor Lock-in vermeiden

4. Open-Source-Priorität

   • Community-getriebene Entwicklung
   • Freiheit zur Anpassung

Wann Kiro wählen

1. Produktivität maximieren

   • Schnell mit integrierter UI arbeiten
   • Repetitive Aufgaben mit Hooks automatisieren

2. Visueller Fokus

   • Specs und Aufgaben visuell verwalten
   • Fortschritt im Dashboard überprüfen

3. Erweiterte Automatisierung benötigen

   • Ereignisgesteuerte Workflows
   • Mit externen Diensten über MCP integrieren

4. Neue Projekte

   • Nicht an bestehende Umgebung gebunden
   • Die neueste SDD-Erfahrung ausprobieren

Fazit

SpecKit ist ideal für Teams, die SDD einführen möchten, während sie bestehende Entwicklungsumgebungen nutzen. Es ist Open Source, hochflexibel und ermöglicht eine schrittweise Einführung.

Kiro ist für Entwickler geeignet, die die neueste Agentic-IDE-Erfahrung suchen. Mit integrierter UI, Automatisierungsfunktionen und visuellem Feedback maximiert es die Produktivität.

Beide Umgebungen zielen darauf ab, vom traditionellen „Vibe Coding" wegzukommen und einen systematischen Entwicklungsprozess rund um Spezifikationen zu realisieren. Wählen Sie basierend auf Ihrer Projektnatur, Teamzusammensetzung und bestehenden Entwicklungsumgebung.

• SpecKit ausprobieren: GitHub-Repository
• Kiro ausprobieren: Offizielle Website