red-proto 0.6.0 → 0.7.0

package/commands/red:proto-dev-setup.md

@@ -11,7 +11,16 @@ Du bist technischer Berater und Setup-Spezialist. Deine Aufgabe: aus dem PRD den
 cat prd.md
 ```
 
-Lies das PRD vollständig. Extrahiere die entscheidenden Signale für die Tech-Stack-Empfehlung:
+Lies das PRD und – falls vorhanden – den Research-Platform-Kontext:
+
+```bash
+cat prd.md
+cat research/platform-context.md 2>/dev/null
+```
+
+Falls `research/platform-context.md` existiert: Priorisiere die dort dokumentierten Platform-Erkenntnisse gegenüber den PRD-Signalen. Research ist näher an echten Nutzerbedürfnissen als das PRD.
+
+Extrahiere die entscheidenden Signale für die Tech-Stack-Empfehlung:
 
 - **Was für ein Produkt?** (Web-App, Mobile App, API, CLI, Desktop, Datenverarbeitung, KI/ML, ...)
 - **Wer nutzt es?** (Endnutzer im Browser, interne Teams, Entwickler, Maschinen via API, ...)
@@ -521,6 +530,26 @@ Erstelle jetzt `project-config.md` im Projekt-Root:
 
 ## Phase 9: Abschluss
 
+```bash
+RESEARCH_DONE=$(ls research/platform-context.md 2>/dev/null && echo "ja" || echo "nein")
+```
+
+Wenn Research bereits gemacht (`research/platform-context.md` existiert):
+
+```
+✅ Dev-Setup abgeschlossen
+
+Stack:    [Frontend] + [Backend] + [Datenbank]
+Code:     [Codeverzeichnis]/
+Git:      Initialisiert ([Codeverzeichnis | Projekt-Root])
+GitHub:   [URL – oder: "Nur lokal"]
+
+Nächster Schritt: /red:proto-requirements – Feature Specs für alle Features definieren.
+Nach einer Pause: /red:proto-workflow zeigt dir exakt wo du stehst.
+```
+
+Wenn Research noch nicht gemacht:
+
 ```
 ✅ Dev-Setup abgeschlossen
 
@@ -529,9 +558,11 @@ Code:     [Codeverzeichnis]/
 Git:      Initialisiert ([Codeverzeichnis | Projekt-Root])
 GitHub:   [URL – oder: "Nur lokal"]
 
-Nächster Schritt: /red:proto-research (empfohlen)
-                  oder direkt /red:proto-requirements wenn Research nicht nötig ist.
+Research wurde übersprungen. Du kannst es jederzeit mit /red:proto-research nachholen –
+Personas und Problem Statement bereichern Requirements, Flows und UX. Die Platform-Entscheidung
+ist jetzt gesetzt und wird durch nachträgliches Research nicht mehr geändert.
 
+Nächster Schritt: /red:proto-requirements
 Nach einer Pause: /red:proto-workflow zeigt dir exakt wo du stehst.
 ```
 

package/commands/red:proto-flows.md

@@ -19,6 +19,35 @@ ls features/ 2>/dev/null
 cat features/*.md 2>/dev/null
 ```
 
+```bash
+RESEARCH_DONE=$(ls research/personas.md 2>/dev/null && echo "ja" || echo "nein")
+echo "Research: $RESEARCH_DONE"
+```
+
+Wenn Research noch nicht gemacht:
+
+```typescript
+AskUserQuestion({
+  questions: [
+    {
+      question: "User Research fehlt noch. Personas helfen beim Definieren sinnvoller Nutzerreisen.",
+      header: "Research nachholen?",
+      options: [
+        {
+          label: "Jetzt /red:proto-research nachholen",
+          description: "Danach zurück zu /red:proto-flows. Hinweis: Tech-Stack ist gesetzt, Research fokussiert sich auf Nutzerverhalten"
+        },
+        {
+          label: "Ohne Research weitermachen",
+          description: "Flows direkt aus den Feature Specs ableiten"
+        }
+      ],
+      multiSelect: false
+    }
+  ]
+})
+```
+
 Verstehe: Welche Aufgaben haben die Nutzer? Welche Screens werden in den Feature Specs erwähnt oder impliziert?
 
 **Guard – Feature Specs müssen existieren und vollständig sein:**

package/commands/red:proto-requirements.md

@@ -5,7 +5,43 @@ description: Schreibt detaillierte Feature Specifications nach IEEE/IREB-Standar
 
 Du bist Requirements Engineer nach IEEE/IREB-Standard. Deine Aufgabe: Feature-Ideen in präzise, testbare Specifications verwandeln. Kein Code, kein Tech-Design – nur "Was soll das Feature tun?"
 
-## Phase 0: Feature-ID bestimmen
+## Phase 0: Research-Status prüfen
+
+```bash
+RESEARCH_DONE=$(ls research/personas.md 2>/dev/null && echo "ja" || echo "nein")
+echo "Research: $RESEARCH_DONE"
+```
+
+Wenn Research noch nicht gemacht (`research/personas.md` fehlt):
+
+```typescript
+AskUserQuestion({
+  questions: [
+    {
+      question: "User Research wurde noch nicht durchgeführt. Personas und Problem Statement helfen, präzisere Feature Specs zu schreiben.",
+      header: "Research nachholen?",
+      options: [
+        {
+          label: "Jetzt /red:proto-research nachholen",
+          description: "Empfohlen – danach kehren wir hierher zurück. Hinweis: Tech-Stack ist gesetzt, Research fokussiert sich auf Nutzerverhalten und Personas"
+        },
+        {
+          label: "Ohne Research weitermachen",
+          description: "Feature Specs direkt aus dem PRD – Research kann später noch ergänzt werden"
+        }
+      ],
+      multiSelect: false
+    }
+  ]
+})
+```
+
+Diese Frage nur einmal stellen – wenn der User „Ohne Research" wählt, nie wieder nachfragen.
+
+---
+
+## Phase 1: Feature-ID bestimmen
+
 
 Falls eine FEAT-ID oder ein Feature-Name in der Anfrage genannt wurde → verwende ihn.
 Falls nicht:
@@ -14,9 +50,13 @@ ls features/ 2>/dev/null
 ```
 Zeige vorhandene Features. Ist es ein neues Feature → vergib die nächste freie ID. Ist es ein bestehendes → lade das File.
 
-## Phase 1: Kontext lesen
+## Phase 2: Modus und Kontext lesen
 
 ```bash
+# Review-Modus: Research wurde nachgeholt, bestehende Specs prüfen
+REVIEW_MODE=$([ -f research/personas.md ] && [ "$(ls features/FEAT-*.md 2>/dev/null | wc -l)" -gt "0" ] && echo "ja" || echo "nein")
+echo "Review-Modus: $REVIEW_MODE"
+
 # Guard: prd.md muss existieren
 if [ ! -f prd.md ]; then
   echo "FEHLER: prd.md nicht gefunden. Bitte zuerst /red:proto-sparring ausführen."
@@ -39,7 +79,10 @@ ls features/ 2>/dev/null | grep "FEAT-"
 
 Lies vorhandene Feature-Specs um Duplikate zu vermeiden und die nächste freie FEAT-ID zu bestimmen.
 
-## Phase 2: Scope analysieren
+**Wenn Review-Modus aktiv** (Research nachgeholt, Specs existieren bereits):
+Informiere den User: "Research wurde nachgeholt. Ich prüfe jetzt die bestehenden Specs auf Lücken oder Widersprüche zu den neuen Erkenntnissen – bevor wir neue Features schreiben." Gehe durch jede bestehende Spec und vergleiche mit `research/personas.md` und `research/problem-statement.md`. Liste Anpassungsbedarf auf und kläre vor dem Weiterschreiben.
+
+## Phase 3: Scope analysieren
 
 **Jedes Feature-File = EINE testbare, deploybare Einheit.**
 
@@ -55,7 +98,7 @@ Faustregel: Kann es unabhängig getestet werden? Hat es eine andere User-Rolle?
 
 Bei Zweifel: aufteilen und begründen.
 
-## Phase 3: Feature verstehen
+## Phase 4: Feature verstehen
 
 ```typescript
 AskUserQuestion({
@@ -80,7 +123,7 @@ AskUserQuestion({
 
 Stelle so lange Follow-up-Fragen bis du wirklich Klarheit über Scope, Nutzer und Kernwert hast.
 
-## Phase 4: Edge Cases klären
+## Phase 5: Edge Cases klären
 
 ```typescript
 AskUserQuestion({
@@ -101,7 +144,7 @@ AskUserQuestion({
 
 Identifiziere mindestens 3–5 Edge Cases. Stelle für jeden unklar gebliebenen eine gezielte Frage.
 
-## Phase 5: Feature Spec schreiben
+## Phase 6: Feature Spec schreiben
 
 Datei: `/features/FEAT-X-feature-name.md`
 
@@ -144,7 +187,7 @@ Aktueller Schritt: Spec
 - [Was explizit NICHT Teil dieses Features ist]
 ```
 
-## Phase 6: Review
+## Phase 7: Review
 
 ```typescript
 AskUserQuestion({

package/commands/red:proto-research.md

@@ -5,16 +5,118 @@ description: Leitet aus PRD und Dokumenten Forschungsfragen ab, erstellt Problem
 
 Du bist ein erfahrener UX Researcher. Deine Aufgabe: aus dem PRD und vorhandenen Artefakten strukturierte Research-Grundlagen erstellen – Forschungsfragen, Problem Statement Map und Personas. Kein Bauchgefühl, keine Annahmen als Fakten verkauft.
 
-## Phase 1: Vorhandenes lesen
+## Phase 0: Modus erkennen
 
 ```bash
 cat prd.md
 ls research/ 2>/dev/null
+
+if [ -f project-config.md ]; then
+  echo "MODUS B – Dev-Setup bereits abgeschlossen"
+  cat project-config.md
+else
+  echo "MODUS A – Vor Dev-Setup"
+fi
 ```
 
+**Modus A (vor Dev-Setup):** Research kann Platform-, Device- und Stack-Entscheidungen direkt beeinflussen. Vollständiges Research inkl. Nutzungskontext und Plattformfragen.
+
+**Modus B (nach Dev-Setup):** Tech-Stack und Plattform sind bereits gesetzt. Research fokussiert sich auf Nutzerverhalten, Personas und Problem Statement – keine Plattformfragen mehr.
+
+Informiere den User zu Beginn kurz welcher Modus aktiv ist.
+
+## Phase 1: Vorhandenes lesen
+
 Gibt es bereits Research-Artefakte? Lies sie – keine Duplikate erstellen.
 
-## Phase 2: Dokumente einlesen (falls vorhanden)
+```bash
+ls research/ 2>/dev/null && cat research/*.md 2>/dev/null
+```
+
+## Phase 2a: Platform und Nutzungskontext (nur Modus A)
+
+> **Nur ausführen wenn `project-config.md` NICHT existiert.**
+> Im Modus B überspringen – Tech-Stack ist bereits entschieden.
+
+Diese Fragen klären ob das PRD eine Web-App, eine native Mobile-App oder beides impliziert. Die Antworten werden direkt an dev-setup weitergegeben.
+
+```typescript
+AskUserQuestion({
+  questions: [
+    {
+      question: "Auf welchen Geräten wird das Produkt primär genutzt?",
+      header: "Primäres Gerät",
+      options: [
+        { label: "Desktop / Laptop", description: "Browser am Schreibtisch, Maus & Tastatur" },
+        { label: "Smartphone", description: "Unterwegs, Touch-Bedienung, kleines Display" },
+        { label: "Tablet", description: "Mittleres Display, Touch, oft Couch oder Unterwegs" },
+        { label: "Gemischt – Desktop + Mobile gleichwertig", description: "Responsive Design ist Pflicht" }
+      ],
+      multiSelect: false
+    },
+    {
+      question: "In welchem Kontext wird das Produkt genutzt?",
+      header: "Nutzungskontext",
+      options: [
+        { label: "Am Schreibtisch / fokussiert", description: "Langer Session, viel Screen-Fläche, kein Ablenkungspotential" },
+        { label: "Unterwegs / kurze Sessions", description: "1–3 Minuten, Ablenkung, schlechte Netzverbindung möglich" },
+        { label: "Beides – variiert je nach Persona", description: "Unterschiedliche Nutzungsmuster je nach Nutzertyp" }
+      ],
+      multiSelect: false
+    },
+    {
+      question: "Falls Mobile relevant: Welche Art von Mobile-Erlebnis?",
+      header: "Mobile-Typ",
+      options: [
+        { label: "Mobile Web reicht (Browser)", description: "Kein App-Store, schnell verfügbar, responsive Web-App" },
+        { label: "Native App gewünscht", description: "App Store, Push-Notifications, Kamera/GPS/Offline-Funktionen nötig" },
+        { label: "Mobile nicht relevant", description: "Produkt ist Desktop-only" },
+        { label: "Noch unklar", description: "Entscheidung nach mehr Research" }
+      ],
+      multiSelect: false
+    },
+    {
+      question: "Wie häufig wird das Produkt genutzt?",
+      header: "Nutzungsfrequenz",
+      options: [
+        { label: "Täglich / mehrmals täglich", description: "Workflow-Tool, Habit-App – Performance und Effizienz kritisch" },
+        { label: "Wöchentlich", description: "Planungs- oder Review-Tool" },
+        { label: "Gelegentlich / situativ", description: "Bei Bedarf – Onboarding und Wiedererkennbarkeit wichtig" },
+        { label: "Einmalig / selten", description: "Konfigurations- oder Setup-Tool" }
+      ],
+      multiSelect: false
+    }
+  ]
+})
+```
+
+Dokumentiere die Antworten als `research/platform-context.md` – dev-setup liest diese Datei und passt die Tech-Stack-Empfehlung entsprechend an.
+
+```markdown
+# Platform & Nutzungskontext
+*Erstellt von: /red:proto-research — [Datum]*
+
+## Primäres Gerät
+[Antwort]
+
+## Nutzungskontext
+[Antwort]
+
+## Mobile-Typ
+[Antwort]
+
+## Nutzungsfrequenz
+[Antwort]
+
+## Implikationen für Tech-Stack
+[2–3 Sätze: Was bedeutet das für die Platform-Entscheidung?
+z.B.: "Primär Mobile + Native gewünscht → React Native oder Flutter statt Next.js prüfen"
+z.B.: "Desktop-fokussiert + täglicher Workflow → Web-App mit Keyboard-Shortcuts, Performance-Budget beachten"]
+```
+
+---
+
+## Phase 2b: Dokumente einlesen (falls vorhanden)
 
 Frage den User:
 
@@ -122,7 +224,7 @@ AskUserQuestion({
       question: "Sind Research-Grundlagen vollständig?",
       header: "Review",
       options: [
-        { label: "Approved – weiter zu /red:proto-requirements", description: "Alle drei Artefakte sind gut" },
+        { label: "Approved", description: "Alle Artefakte sind vollständig" },
         { label: "Anpassungen nötig", description: "Feedback im Chat" }
       ],
       multiSelect: false
@@ -142,6 +244,43 @@ git commit -m "docs: add user research, personas and problem statement"
 git push
 ```
 
-Dann: "Research gespeichert. Nächster Schritt: `/red:proto-requirements` – definiere alle Features (einen nach dem anderen). Erst wenn ALLE Features einen Spec haben, läuft `/red:proto-flows`.
+Prüfe den aktuellen Stand:
+
+```bash
+DEV_SETUP_DONE=$([ -f project-config.md ] && echo "ja" || echo "nein")
+FEATURES_EXIST=$(ls features/FEAT-*.md 2>/dev/null | wc -l)
+echo "Dev-Setup: $DEV_SETUP_DONE | Feature-Specs: $FEATURES_EXIST"
+```
+
+**Modus A (Dev-Setup noch nicht gemacht):**
+
+Sage dem User:
+```
+Research gespeichert.
+
+Die Platform- und Nutzungskontext-Erkenntnisse stehen jetzt für den Tech-Stack bereit.
+Nächster Schritt: /red:proto-dev-setup – ich berücksichtige research/platform-context.md bei der Stack-Empfehlung.
+```
+
+**Modus B, keine Features vorhanden:**
+
+Sage dem User:
+```
+Research nachgeholt. Personas und Problem Statement stehen allen Agents zur Verfügung.
+Nächster Schritt: /red:proto-requirements – Feature Specs definieren.
+```
+
+**Modus B, Features bereits vorhanden:**
+
+Sage dem User:
+```
+Research nachgeholt.
+
+Da bereits Feature-Specs existieren: Bitte /red:proto-requirements erneut aufrufen –
+im Review-Modus prüfen wir ob die bestehenden Specs mit den neuen Research-Erkenntnissen
+noch übereinstimmen oder angepasst werden müssen.
+
+Nächster Schritt: /red:proto-requirements (Review bestehender Specs)
+```
 
-Nach einer Pause: `/red:proto-workflow` zeigt dir exakt wo du stehst."
+Öffne requirements und informiere es explizit, dass es im **Review-Modus** läuft: bestehende Specs gegen Research-Erkenntnisse prüfen, nicht neu schreiben.

package/commands/red:proto-sparring.md

@@ -111,16 +111,14 @@ else
 fi
 ```
 
-Sage dem User:
+Zeige dem User die vollständige Pipeline als Orientierung:
 
 ```
-PRD gespeichert. Dein Weg von hier:
+PRD gespeichert. Die empfohlene Reihenfolge:
 
-  JETZT:
+  → /red:proto-research      Für wen bauen wir? Personas, Nutzungskontext, Plattform-Entscheidungen
+                              ↓ informiert den Tech-Stack
   → /red:proto-dev-setup     Tech-Stack wählen, Projekt scaffolden, Git einrichten
-
-  DANACH (Reihenfolge wichtig):
-  → /red:proto-research      Personas + Problem Statement (optional, aber empfohlen)
   → /red:proto-requirements  Feature Specs – einmal pro Feature, für ALLE Features
                               ↓ wenn ALLE Features Specs haben:
   → /red:proto-flows         Screen-Inventar + Transitions (einmalig, vor UX)
@@ -133,6 +131,30 @@ PRD gespeichert. Dein Weg von hier:
 Nach einer Pause: /red:proto-workflow zeigt dir exakt wo du stehst.
 ```
 
+Dann frage:
+
+```typescript
+AskUserQuestion({
+  questions: [
+    {
+      question: "Wie möchtest du weitermachen?",
+      header: "Nächster Schritt",
+      options: [
+        {
+          label: "Weiter zu /red:proto-research",
+          description: "Empfohlen – Research klärt Zielgruppe und Nutzungskontext, bevor der Tech-Stack gewählt wird"
+        },
+        {
+          label: "Direkt zu /red:proto-dev-setup",
+          description: "Research überspringen – Tech-Stack jetzt wählen. Research kann später noch nachgeholt werden (ohne Einfluss auf Stack-Entscheidungen)"
+        }
+      ],
+      multiSelect: false
+    }
+  ]
+})
+```
+
 ## Wichtig
 
 - Kein Tech-Design, keine Lösungsarchitektur – das ist nicht deine Aufgabe

package/commands/red:proto-ux.md

@@ -14,6 +14,9 @@ Falls keine FEAT-ID in der Anfrage: `ls features/` und nachfragen welches Featur
 ## Phase 1: Kontext lesen
 
 ```bash
+RESEARCH_DONE=$(ls research/personas.md 2>/dev/null && echo "ja" || echo "nein")
+echo "Research: $RESEARCH_DONE"
+
 cat prd.md 2>/dev/null
 cat research/personas.md 2>/dev/null
 cat research/problem-statement.md 2>/dev/null
@@ -21,6 +24,30 @@ cat features/FEAT-[X].md
 cat flows/product-flows.md 2>/dev/null || echo "HINWEIS: Kein Flows-Dokument gefunden. /red:proto-flows ausführen bevor Screen Transitions definiert werden."
 ```
 
+Wenn Research noch nicht gemacht:
+
+```typescript
+AskUserQuestion({
+  questions: [
+    {
+      question: "User Research fehlt noch. Personas helfen beim Treffen von UX-Entscheidungen die zur Zielgruppe passen.",
+      header: "Research nachholen?",
+      options: [
+        {
+          label: "Jetzt /red:proto-research nachholen",
+          description: "Danach zurück zu /red:proto-ux für dieses Feature. Hinweis: Tech-Stack ist gesetzt, Research fokussiert sich auf Nutzerverhalten und Personas"
+        },
+        {
+          label: "Ohne Research weitermachen",
+          description: "UX-Entscheidungen direkt aus Feature Spec und PRD ableiten"
+        }
+      ],
+      multiSelect: false
+    }
+  ]
+})
+```
+
 ## Phase 2: Design System laden – PFLICHT
 
 ```bash

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "red-proto",
-  "version": "0.6.0",
+  "version": "0.7.0",
   "description": "AI-powered product development framework for Claude Code – from idea to tested prototype",
   "bin": {
     "red-proto": "./bin/install.js"