Wichtig: Wir stoppen bewusst vor der Implementierung. Ziel ist, den Spec-Workflow zu erleben, nicht ein ganzes Feature zu bauen. So bleibt die Übung kurz und der Fokus liegt auf den Artefakten.
Ziel
Für eine kleine Erweiterung des Kanban-Boards aus Lab 2 lässt du Kiro eine Spec erstellen — also requirements.md und design.md — und hältst vor dem Code an. Dadurch wird der Unterschied zum schnellen Chat-Modus greifbar.
Vorbereitung
- Das Projekt aus Lab 2 (Kanban-Board) geöffnet.
- In Kiro den Spec-Modus wählen (statt Chat).
Schritt 1 – Spec starten
Formuliere das gewünschte Feature. Beispiel:
Erstelle eine Spec für ein Filter-Feature im Kanban-Board:
Man soll die Karten nach Fälligkeitsdatum filtern können
(z. B. "nur heute fällige", "diese Woche", "alle").
Erzeuge zunächst nur die Requirements. Noch keinen Code.
Schritt 2 – requirements.md prüfen
- Kiro erzeugt
requirements.mdmit User Stories und Akzeptanzkriterien (oft in EARS-Notation: „WENN … DANN soll das System …“). - Gemeinsam lesen: Ist das „Was“ vollständig und verständlich?
- Bei Bedarf verfeinern (z. B. „Ergänze ein Kriterium für den leeren Filterzustand“).
Schritt 3 – design.md erzeugen
Erstelle jetzt das Design (design.md) für dieses Feature:
Datenfluss, betroffene Funktionen/Strukturen und wie der Filter im
bestehenden Board integriert wird. Weiterhin kein Code.
design.mdansehen: Architektur, Datenfluss, ggf. ein kleines Diagramm.
Schritt 4 – Hier bewusst aufhören
- Wir gehen nicht weiter zum Code. Klicke also nicht auf „Tasks generieren“ oder „Implementieren“, auch wenn Kiro es anbietet.
- Schau dir stattdessen in Ruhe die beiden erstellten Dateien an:
requirements.md(das Was) unddesign.md(das Wie). - Kurz für dich festhalten: Was ist hier anders als im Chat-Modus, wo sofort Code kommt?
Erwartetes Ergebnis
Zwei nachvollziehbare Artefakte (requirements.md, design.md) im Ordner .kiro/specs/…, die das Feature beschreiben — ohne dass Code entstanden ist.
Lernpunkte
- Spec-Driven erzwingt eine „Denk-Pause“ vor dem Coden (Think before Typing).
- Die drei Artefakte: requirements (Was) → design (Wie) → tasks (Ausführung).
- Ergebnisse sind nachvollziehbar und für Teams prüf-/freigebbar (auditierbar).
- Spec-Driven für Produktion, Chat-Modus für schnelle Prototypen.