red-proto 0.6.0 → 0.9.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, ...)
@@ -134,14 +143,6 @@ Danach noch fragen:
 ```typescript
 AskUserQuestion({
   questions: [
-    {
-      question: "Wie soll das GitHub-Repository heißen?",
-      header: "Repository-Name",
-      options: [
-        { label: "Ich gebe den Namen im Chat an", description: "Kurz, keine Leerzeichen (z.B. mein-projekt) – nur für GitHub, nicht der Code-Ordner" }
-      ],
-      multiSelect: false
-    },
     {
       question: "In welchem Verzeichnis soll der Programm-Code liegen?",
       header: "Code-Verzeichnis",
@@ -149,17 +150,26 @@ AskUserQuestion({
         { label: "projekt/", description: "Standard – neuer Ordner im Framework-Root" },
         { label: "src/", description: "Klassisch für viele Frameworks" },
         { label: "app/", description: "Üblich bei Django, Laravel etc." },
-        { label: "Anderer Name", description: "Ich gebe den Namen im Chat an" }
+        { label: "Anderer Name – ich nenne ihn im Chat", description: "Beliebiger Verzeichnisname" }
       ],
       multiSelect: false
-    },
+    }
+  ]
+})
+```
+
+Warte auf Antwort. Falls "Anderer Name": nachfragen im Chat.
+
+```typescript
+AskUserQuestion({
+  questions: [
     {
       question: "Soll ein GitHub-Repository angelegt werden?",
-      header: "GitHub",
+      header: "GitHub Repository",
       options: [
-        { label: "Ja, privat (private)", description: "Empfohlen – nur du siehst das Repo" },
-        { label: "Ja, öffentlich (public)", description: "Für Open-Source oder öffentliche Projekte" },
-        { label: "Nein, nur lokal", description: "Git lokal, kein GitHub" }
+        { label: "Ja, privat", description: "Empfohlen – nur du siehst das Repo" },
+        { label: "Ja, öffentlich", description: "Für Open-Source oder öffentliche Projekte" },
+        { label: "Nein, nur lokal", description: "Git lokal einrichten, kein GitHub" }
       ],
       multiSelect: false
     }
@@ -167,6 +177,26 @@ AskUserQuestion({
 })
 ```
 
+Falls GitHub gewünscht:
+
+```typescript
+AskUserQuestion({
+  questions: [
+    {
+      question: "Wie soll das GitHub-Repository heißen?",
+      header: "Repository-Name",
+      options: [
+        { label: "Produktname in Kleinbuchstaben", description: "z.B. mein-projekt – empfohlen, klar und einprägsam" },
+        { label: "Anderer Name – ich nenne ihn im Chat", description: "Eigener Name, keine Leerzeichen, Bindestriche statt Unterstriche" }
+      ],
+      multiSelect: false
+    }
+  ]
+})
+```
+
+Warte auf Antwort. Falls "Anderer Name": nachfragen im Chat.
+
 Falls GitHub Ja:
 
 ```typescript
@@ -521,6 +551,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 +579,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,53 +98,21 @@ Faustregel: Kann es unabhängig getestet werden? Hat es eine andere User-Rolle?
 
 Bei Zweifel: aufteilen und begründen.
 
-## Phase 3: Feature verstehen
-
-```typescript
-AskUserQuestion({
-  questions: [
-    {
-      question: "Welche Persona(s) nutzt dieses Feature primär?",
-      header: "Zielgruppe",
-      options: [] // Dynamisch befüllen aus /research/personas.md falls vorhanden
-      // Fallback: offene Frage im Chat
-    },
-    {
-      question: "Was ist der kritischste Acceptance Criterion – ohne den das Feature wertlos wäre?",
-      header: "Core AC",
-      options: [
-        { label: "Ich beschreibe es im Chat", description: "" }
-      ],
-      multiSelect: false
-    }
-  ]
-})
-```
+## Phase 4: Spec autonom erstellen
 
-Stelle so lange Follow-up-Fragen bis du wirklich Klarheit über Scope, Nutzer und Kernwert hast.
+Leite aus PRD, Research und Feature-Beschreibung selbstständig ab:
+- **Zielgruppe:** Welche Persona(s) aus `research/personas.md` nutzen dieses Feature? Falls kein Research: aus PRD ableiten.
+- **Kernwert:** Was ist das wichtigste Acceptance Criterion – ohne das das Feature wertlos wäre?
+- **Out of Scope:** Was ist bewusst nicht Teil dieses Features (naheliegende Abgrenzungen)?
+- **User Stories:** Mindestens 3–5, rollen-spezifisch, aus Nutzerperspektive.
+- **Acceptance Criteria:** Mindestens 5, konkret und testbar, kein Konjunktiv.
+- **Edge Cases:** Mindestens 3–5 – leite sie aus dem Feature-Kontext ab und entscheide das Verhalten selbst auf Basis von PRD, Research und gesundem Menschenverstand.
 
-## Phase 4: Edge Cases klären
-
-```typescript
-AskUserQuestion({
-  questions: [
-    {
-      question: "Was passiert bei [kritischstem Edge Case]?",
-      header: "Edge Case",
-      options: [
-        { label: "Option A", description: "..." },
-        { label: "Option B", description: "..." },
-        { label: "Noch nicht entschieden", description: "Wir klären das" }
-      ],
-      multiSelect: false
-    }
-  ]
-})
-```
+Nur nachfragen wenn etwas genuiner Klärungsbedarf hat der sich nicht aus den vorhandenen Artefakten ableiten lässt – das sollte die Ausnahme sein, nicht die Regel.
 
-Identifiziere mindestens 3–5 Edge Cases. Stelle für jeden unklar gebliebenen eine gezielte Frage.
+Schreibe die vollständige Spec direkt. Zeige sie im Chat bevor du speicherst.
 
-## Phase 5: Feature Spec schreiben
+## Phase 6: Feature Spec schreiben
 
 Datei: `/features/FEAT-X-feature-name.md`
 
@@ -144,7 +155,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:
 
@@ -50,7 +152,109 @@ Gute Forschungsfragen sind:
 - Verhaltensbezogen, nicht meinungsbezogen
 - Relevant für Produkt-Entscheidungen
 
-Präsentiere 5–8 Forschungsfragen zur Diskussion. Frage den User ob etwas fehlt oder falsch priorisiert ist.
+Entwickle 5–8 Forschungsfragen. Nummeriere sie klar (1. / 2. / ...) und präsentiere sie im Chat.
+
+Frage den User ob etwas fehlt oder falsch priorisiert ist – passe die Liste an bis sie stimmt.
+
+## Phase 3b: Beantwortung der Forschungsfragen
+
+```typescript
+AskUserQuestion({
+  questions: [
+    {
+      question: "Die Forschungsfragen sind bereit. Wie möchtest du vorgehen?",
+      header: "Research-Methode",
+      options: [
+        {
+          label: "Jetzt interaktiv beantworten",
+          description: "Ich führe dich Frage für Frage durch – du antwortest direkt im Chat auf Basis deiner Annahmen, Erfahrungen oder vorhandenem Wissen"
+        },
+        {
+          label: "Pause – echten Research durchführen",
+          description: "Ich speichere die offenen Fragen. Du führst Interviews, Umfragen oder Beobachtungen durch und rufst /red:proto-research danach erneut auf"
+        }
+      ],
+      multiSelect: false
+    }
+  ]
+})
+```
+
+**Bei "Pause – echten Research durchführen":**
+
+Speichere die Forschungsfragen in `research/research-questions.md`:
+
+```markdown
+# Forschungsfragen
+*Erstellt von: /red:proto-research — [Datum]*
+*Status: Offen – noch nicht beantwortet*
+
+## Offene Fragen
+
+1. [Frage 1]
+2. [Frage 2]
+...
+
+## Methoden-Empfehlung
+- Nutzerinterviews (30–45 min, 3–5 Teilnehmer)
+- Kontextuelle Beobachtung wenn möglich
+- Kurze Online-Umfrage für quantitative Einschätzung
+
+## Nächster Schritt
+Beantworte diese Fragen durch echten User Research.
+Danach: `/red:proto-research` erneut aufrufen – ich verarbeite deine Antworten.
+```
+
+Dann stoppen und dem User sagen:
+```
+Forschungsfragen gespeichert in research/research-questions.md.
+
+Führe deinen Research durch (Interviews, Umfragen, Beobachtungen) und trage
+die Antworten direkt in die Datei ein – oder beschreibe sie mir beim nächsten Aufruf.
+
+Wenn du fertig bist: /red:proto-research erneut aufrufen.
+```
+
+**Bei "Jetzt interaktiv beantworten":**
+
+Gehe jede Frage einzeln durch. Stelle eine Frage im Chat und warte auf die Antwort bevor du zur nächsten gehst:
+
+```
+Frage 1 von [N]:
+[Vollständiger Fragetext]
+
+(Deine Antwort kann eine Vermutung, eine Beobachtung oder eine Erfahrung sein –
+kein perfektes Research nötig, wir arbeiten mit dem was du weißt)
+```
+
+Sammle alle Antworten. Speichere danach `research/research-questions.md`:
+
+```markdown
+# Forschungsfragen & Antworten
+*Erstellt von: /red:proto-research — [Datum]*
+*Status: Interaktiv beantwortet (Hypothesen)*
+
+## Fragen & Antworten
+
+### 1. [Frage 1]
+**Antwort:** [Antwort des Users]
+
+### 2. [Frage 2]
+**Antwort:** [Antwort des Users]
+
+...
+
+## Hinweis
+Diese Antworten basieren auf Annahmen und Hypothesen, nicht auf echtem User Research.
+Sie sind ein valider Ausgangspunkt – können aber durch spätere echte Interviews ergänzt werden.
+```
+
+Danach dem User mitteilen:
+```
+Antworten gespeichert. Weiter mit Phase 4 – Problem Statement Map.
+```
+
+Und direkt mit Phase 4 fortfahren.
 
 ## Phase 4: Problem Statement Map erstellen
 
@@ -122,7 +326,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 +346,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,42 +24,23 @@ 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."
 ```
 
-## Phase 2: Design System laden – PFLICHT
-
-```bash
-cat design-system/components/*.md 2>/dev/null
-cat design-system/patterns/*.md 2>/dev/null
-ls design-system/screens/ 2>/dev/null
-ls design-system/screens/*/ 2>/dev/null
-```
-
-Erstelle intern eine Liste aller verfügbaren Komponenten aus `design-system/components/`.
-
-## Phase 3: UX-Entscheidungen klären
+Wenn Research noch nicht gemacht:
 
 ```typescript
 AskUserQuestion({
   questions: [
     {
-      question: "Wo im Produkt lebt dieses Feature?",
-      header: "Einbettung",
+      question: "User Research fehlt noch. Personas helfen beim Treffen von UX-Entscheidungen die zur Zielgruppe passen.",
+      header: "Research nachholen?",
       options: [
-        { label: "Neue Seite / eigener Screen", description: "Eigene Route, Navigation-Eintrag" },
-        { label: "Modal / Overlay", description: "Über bestehenden Content" },
-        { label: "Erweiterung einer bestehenden Seite", description: "Neuer Bereich auf existierender Page" },
-        { label: "Noch unklar", description: "Lass uns das herausfinden" }
-      ],
-      multiSelect: false
-    },
-    {
-      question: "Welches primäre Interaktionsmuster passt?",
-      header: "Interaktion",
-      options: [
-        { label: "Formular", description: "User gibt Daten ein und submitted" },
-        { label: "Liste + Detailansicht", description: "Übersicht → Drill-Down" },
-        { label: "Wizard / Schritt-für-Schritt", description: "Geführter Prozess" },
-        { label: "Dashboard / Übersicht", description: "Informationsanzeige" },
-        { label: "Inline-Editing", description: "Direkte Bearbeitung" }
+        {
+          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
     }
@@ -64,30 +48,32 @@ AskUserQuestion({
 })
 ```
 
-## Phase 4: Komponenten-Entscheidung durch UX Designer
-
-**Du fragst – der Designer entscheidet:**
+## Phase 2: Design System laden – PFLICHT
 
-```typescript
-AskUserQuestion({
-  questions: [
-    {
-      question: "Welche Komponenten möchtest du in diesem Feature einsetzen?",
-      header: "Komponenten",
-      options: [
-        { label: "Ich nenne sie im Chat", description: "Liste alle Komponenten die du brauchst" }
-      ],
-      multiSelect: false
-    }
-  ]
-})
+```bash
+cat design-system/components/*.md 2>/dev/null
+cat design-system/patterns/*.md 2>/dev/null
+ls design-system/screens/ 2>/dev/null
+ls design-system/screens/*/ 2>/dev/null
 ```
 
-Nimm die genannte Liste entgegen. Dann:
+Erstelle intern eine Liste aller verfügbaren Komponenten aus `design-system/components/`.
+
+## Phase 3: Autonome UX-Analyse
+
+**Du entscheidest – nicht der Nutzer.** Leite alle UX-Entscheidungen selbst aus dem gelesenen Kontext ab: PRD, Personas, Feature-Spec, Design System, Flows.
+
+Analysiere und dokumentiere intern:
+
+**Einbettung:** Wo lebt das Feature im Produkt? Leite ab aus: Feature-Scope, bestehenden Flows, Navigation-Struktur im DS. Begründe deine Wahl (z.B. "Modal, weil der Feature-Scope eng ist und kein eigener Navigation-Eintrag gerechtfertigt ist").
+
+**Interaktionsmuster:** Welches primäre Pattern passt? Leite ab aus: Feature-Ziel, Persona-Verhalten, Datenmenge, Mobile-Kontext. Begründe deine Wahl (z.B. "Liste + Detailansicht, weil Personas täglich zwischen mehreren Einträgen navigieren müssen").
 
-### DS-Validierung
+**Komponenten-Auswahl:** Wähle alle benötigten Komponenten eigenständig aus `design-system/components/`. Begründe jede Wahl kurz. Prüfe dann:
 
-Prüfe für jede genannte Komponente ob eine Spec in `design-system/components/` existiert:
+## Phase 4: DS-Validierung
+
+Prüfe für jede selbst gewählte Komponente ob eine Spec in `design-system/components/` existiert:
 
 ```bash
 ls design-system/components/ 2>/dev/null
@@ -141,7 +127,9 @@ AskUserQuestion({
 - **Fortfahren mit Tokens:** Notiere genehmigte Lücken für Phase 6 (DS-Status).
 - **Bewusste Abweichung:** Frage nach dem Testgrund und notiere ihn für Phase 6.
 
-## Phase 5: Screen Transitions definieren
+## Phase 5: Navigation nach Aktionen definieren
+
+*(Was passiert nach welcher Nutzer-Aktion? Z.B. nach "Speichern" → Wo landet der Nutzer? Nach "Abbrechen" → Zurück wohin?)*
 
 **Guard – Flows-Dokument prüfen:**
 
@@ -160,11 +148,11 @@ AskUserQuestion({
       options: [
         {
           label: "Jetzt /red:proto-flows ausführen",
-          description: "Empfohlen – definiert alle Screen Transitions übergreifend bevor wir weitermachen"
+          description: "Empfohlen – definiert übergreifend wo Nutzer nach jeder Aktion landen"
         },
         {
-          label: "Transitions nur für dieses Feature definieren",
-          description: "Nur die Transitions dieses Features werden dokumentiert – ohne übergreifenden Kontext"
+          label: "Nur für dieses Feature definieren",
+          description: "Nur die Navigations-Abfolge dieses Features wird dokumentiert – ohne übergreifenden Kontext"
         }
       ],
       multiSelect: false
@@ -173,27 +161,13 @@ AskUserQuestion({
 })
 ```
 
-**Transitions für dieses Feature erfassen:**
+**Navigation eigenständig ableiten:**
 
-Frage den Designer nach jeder Transition die dieses Feature betrifft:
+Leite alle Navigations-Abfolgen aus `flows/product-flows.md` und dem Feature-Scope ab: Welche Aktionen führt der Nutzer aus? Wo landet er danach jeweils? Definiere dies selbst und dokumentiere es in Phase 6.
 
-```typescript
-AskUserQuestion({
-  questions: [
-    {
-      question: "Welche Screen Transitions gehören zu diesem Feature? (Von welchem Screen, welcher Trigger, zu welchem Ziel?)",
-      header: "Transitions",
-      options: [
-        { label: "Ich definiere sie im Chat", description: "Format: Von Screen → Trigger → Ziel-Screen (+ Bedingung falls nötig)" },
-        { label: "Keine Transitions – Feature ist in-page", description: "Keine Navigationsänderungen" }
-      ],
-      multiSelect: false
-    }
-  ]
-})
-```
+Nur wenn genuiner Interpretations-Spielraum bleibt (z.B. ob ein Fehler als Inline-Meldung oder auf einer eigenen Seite erscheint), stelle diese eine gezielte Frage im Chat.
 
-Wenn Flows-Dokument vorhanden: Trage alle Transitions in `flows/product-flows.md` ein.
+Wenn Flows-Dokument vorhanden: Trage alle Navigations-Abfolgen in `flows/product-flows.md` ein.
 
 ## Skill: UI/UX Design Guidelines
 
@@ -241,13 +215,15 @@ Route (falls neu): `/[pfad]`
 | [Name]           | ⚠ Tokens-Build    | Keine Spec – genehmigt [Datum]            |
 | [Name]           | 🧪 Hypothesentest  | Abweichung von [Pattern] – Grund: [...]   |
 
-### Screen Transitions (verbindlich)
-| Von              | Trigger                  | Wohin            | Bedingung              |
+### Navigation nach Aktionen (verbindlich)
+*Was passiert nach welcher Nutzer-Aktion?*
+
+| Ausgangs-Screen  | Aktion des Nutzers       | Ziel             | Bedingung              |
 |------------------|--------------------------|------------------|------------------------|
 | [Screen]         | "[Aktion]"               | [Ziel-Screen]    | –                      |
-| [Screen]         | Submit (Fehler)          | gleiche Seite    | Inline-Fehler          |
+| [Screen]         | Speichern (mit Fehler)   | gleiche Seite    | Inline-Fehlermeldung   |
 
-*(Vollständige Transitions auch in flows/product-flows.md eingetragen)*
+*(Vollständige Navigations-Abfolgen auch in flows/product-flows.md eingetragen)*
 
 ### DS-Status dieser Implementierung
 - **Konforme Komponenten:** [Liste]

package/commands/red:proto.md

@@ -64,6 +64,52 @@ mkdir -p design-system/screens
 [ ! -f project-config.md ] && mkdir -p projekt
 ```
 
+**Schritt 2b – Terminal-Permissions einrichten (.claude/settings.json):**
+
+Damit du nicht bei jedem Bash-, Git- oder Node-Befehl manuell zustimmen musst, werden die Permissions einmalig gesetzt.
+
+**Wichtig:** Falls bereits eine `.claude/settings.json` existiert (z.B. durch MCP-Einstellungen), wird sie **erweitert**, nicht überschrieben.
+
+```bash
+if [ -f .claude/settings.json ]; then
+  echo "settings.json existiert bereits – wird erweitert"
+  cat .claude/settings.json
+else
+  echo "Keine settings.json vorhanden – wird neu erstellt"
+fi
+```
+
+Wenn die Datei **nicht existiert**: erstelle `.claude/settings.json` mit folgendem Inhalt:
+
+```json
+{
+  "permissions": {
+    "allow": [
+      "Bash(*)",
+      "Read(*)",
+      "Write(*)",
+      "Edit(*)",
+      "Glob(*)",
+      "Grep(*)"
+    ],
+    "deny": []
+  }
+}
+```
+
+Wenn die Datei **bereits existiert**: lies sie vollständig, prüfe ob ein `permissions`-Block vorhanden ist:
+- Falls **kein** `permissions`-Block → füge ihn zum bestehenden JSON hinzu (JSON korrekt mergen, alle anderen Felder erhalten)
+- Falls `permissions`-Block **bereits vorhanden** → nichts ändern, dem User mitteilen dass Permissions bereits konfiguriert sind
+
+Zeige dem User danach den aktuellen Stand der settings.json:
+```
+✅ Terminal-Permissions gesetzt – du wirst nicht mehr bei jedem Befehl gefragt.
+   Bash, Git, Read, Write und Edit sind für dieses Projekt vorab genehmigt.
+   (Konfiguriert in .claude/settings.json – jederzeit anpassbar)
+```
+
+---
+
 **Schritt 3a – Nur fehlende Dateien kopieren** (Modus: "Nur fehlende"):
 
 ```bash

package/package.json

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