red-proto 0.4.0 → 0.7.0

package/README.md

@@ -9,15 +9,21 @@ Ein KI-gestütztes Product Development Framework für [Claude Code](https://clau
 Eine Sammlung von Claude Code Commands und Agents, die eine vollständige Produktentwicklungs-Pipeline abbilden. Du arbeitest mit natürlicher Sprache – Claude führt die Pipeline aus, du triffst die Entscheidungen.
 
 ```
+/red:proto-workflow     → Nach jeder Pause: zeigt exakt wo du stehst und was als nächstes zu tun ist
+
 /red:proto-sparring     → Idee schärfen → PRD
 /red:proto-dev-setup    → Tech-Stack wählen, Projekt scaffolden, Git/GitHub einrichten
-/red:proto-research     → Problem Statement Map + Personas
-/red:proto-requirements → Feature Specs (User Stories, Acceptance Criteria, Edge Cases)
-/red:proto-flows        → Screen-Inventar + verbindliche Transition-Tabelle
-/red:proto-ux           → UX-Entscheidungen pro Feature – DS-konform, Transitions aus /flows
+/red:proto-research     → Problem Statement Map + Personas (optional)
+/red:proto-requirements → Feature Specs – einmal pro Feature, für ALLE Features
+                          ↓ wenn ALLE Features Specs haben:
+/red:proto-flows        → Screen-Inventar + verbindliche Transition-Tabelle (einmalig)
+/red:proto-ux           → UX-Entscheidungen – einmal pro Feature
+
+dann pro Feature (Build-Loop bis QA grün):
 /red:proto-architect    → Technisches Design + Security + Test-Setup
 /red:proto-dev          → Implementierung (Frontend + Backend, parallel falls nötig)
 /red:proto-qa           → Tests, Accessibility, Security, Bug-Loop bis Production-Ready
+                          └── Bugs? → /red:proto-dev → /red:proto-qa (wiederholen)
 ```
 
 Jeder Command ist eigenständig – du kannst an jedem Punkt einsteigen oder aufhören. Die Commands bauen aber aufeinander auf: jeder liest den Output des vorherigen und ergänzt die gemeinsamen Artefakte.
@@ -32,19 +38,25 @@ Jeder Command ist eigenständig – du kannst an jedem Punkt einsteigen oder auf
 
 ---
 
-## Installation
+## Installation – zwei Schritte, zwei verschiedene Dinge
+
+> **Wichtig:** Es gibt zwei Schritte, die unterschiedliche Zwecke haben. Beide sind nötig.
 
-### Option A – npx Installer (empfohlen)
+### Schritt 1 – `npx red-proto` installiert das Framework auf deinem Computer
 
-Einmalig ausführen. Der Installer fragt interaktiv ob global oder lokal:
+Macht die `/red:proto-*` Commands in Claude Code verfügbar. Einmalig pro Computer ausführen.
 
 ```bash
 npx red-proto@latest
 ```
 
-> **Update:** Einfach denselben Befehl erneut ausführen – der Installer erkennt bestehende Installationen und fragt was zu tun ist.
+Der Installer fragt interaktiv:
+- **Global** (`~/.claude/`) → Commands in allen Projekten verfügbar
+- **Lokal** (`./.claude/`) → nur im aktuellen Verzeichnis
 
-### Option B – Manuell via Git
+> **Update:** Denselben Befehl erneut ausführen – der Installer erkennt bestehende Installationen.
+
+**Option B – Manuell via Git (falls kein npx):**
 
 ```bash
 git clone https://github.com/eltuctuc/red-create-prototyp-project.git ~/.claude/templates/red-create-prototyp-project && \
@@ -53,9 +65,15 @@ cp ~/.claude/templates/red-create-prototyp-project/commands/red\:proto.md ~/.cla
 
 ---
 
-### Framework in ein Projekt einrichten
+### Schritt 2 – `/red:proto` richtet ein einzelnes Projekt ein
+
+> **Diesen Schritt musst du für jedes neue Projekt wiederholen.**
+
+`npx` installiert nur die Commands. `/red:proto` baut die Projektstruktur auf:
 
-Nach der Installation (Option A oder B) in Claude Code:
+- legt `research/`, `features/`, `flows/`, `bugs/`, `docs/` an
+- kopiert das neutrale Design System ins Projekt
+- erstellt `project-config.md` als Basis für alle Agents
 
 ```bash
 mkdir mein-projekt && cd mein-projekt
@@ -68,9 +86,7 @@ Dann in Claude Code:
 /red:proto
 ```
 
-Das kopiert alle Commands und Agents in `.claude/commands/` und `.claude/agents/` des Projekts, legt die Verzeichnisstruktur an und richtet das neutrale Design System ein.
-
-### Schritt 3 – Loslegen
+**Danach loslegen:**
 
 ```
 /red:proto-sparring
@@ -78,6 +94,17 @@ Das kopiert alle Commands und Agents in `.claude/commands/` und `.claude/agents/
 
 ---
 
+### Kurzübersicht: Was macht was?
+
+| Befehl | Wann | Was passiert |
+|--------|------|--------------|
+| `npx red-proto@latest` | Einmalig pro Computer | Installiert Commands in `~/.claude/` (global) oder `./.claude/` (lokal) |
+| `/red:proto` | Einmalig pro Projekt | Legt Projektstruktur an, kopiert Design System |
+| `/red:proto-sparring` | Start jedes Projekts | Erste Anlaufstelle – Idee zu PRD |
+| `/red:proto-workflow` | Nach jeder Session-Pause | Zeigt wo du stehst, was als nächstes kommt |
+
+---
+
 ## Was wird installiert?
 
 Nach dem Setup hat dein Projekt folgende Struktur:

package/agents/frontend-developer.md

@@ -9,7 +9,7 @@ Du bist erfahrener Frontend-Developer. Du baust die UI für ein definiertes Feat
 
 ```bash
 cat project-config.md        # Tech-Stack, Framework, Design-System, Codeverzeichnis
-cat features/FEAT-[ID].md    # Vollständige Spec – besonders Abschnitte 2 (IA/UX) und 3 (Tech-Design)
+cat features/FEAT-[ID].md    # Vollständige Spec – besonders Abschnitte 2 (UX) und 3 (Tech-Design)
 ```
 
 **Pfade bestimmen:** Lies aus `project-config.md`:
@@ -23,7 +23,7 @@ ls [Codeverzeichnis]/ 2>/dev/null    # Grundstruktur bestätigen
 ```
 
 Lies besonders:
-- Abschnitt 2 (IA/UX): User Flows, Komponentenstruktur, Interaktionsmuster
+- Abschnitt 2 (UX): User Flows, Komponentenstruktur, Interaktionsmuster
 - Abschnitt 3 (Tech-Design): Frontend-Komponenten, API-Contracts (wie rufst du das Backend auf?)
 
 ## Phase 1b: Design System lesen – PFLICHT vor jeder UI-Implementierung
@@ -61,7 +61,7 @@ ls design-system/screens/*/ 2>/dev/null
 cat flows/product-flows.md 2>/dev/null || echo "HINWEIS: Kein Flows-Dokument – nur Transitions aus Feature-File nutzen"
 ```
 
-Lies den Abschnitt **"Screen Transitions"** im Feature-File (`## 2. IA/UX Entscheidungen → Screen Transitions`).
+Lies den Abschnitt **"Screen Transitions"** im Feature-File (`## 2. UX Entscheidungen → Screen Transitions`).
 
 **Verbindliche Navigationsregeln:**
 - Jede Verbindung zwischen Screens muss in der Transition-Tabelle des Feature-Files oder in `flows/product-flows.md` definiert sein
@@ -69,6 +69,20 @@ Lies den Abschnitt **"Screen Transitions"** im Feature-File (`## 2. IA/UX Entsch
 - Wenn beim Implementieren eine fehlende Transition erkannt wird: **sofort stoppen**, in `flows/product-flows.md` unter "Offene Transitions" dokumentieren und im Abschlussbericht melden
 - Routing-Pfade (URLs/Routes) exakt so verwenden wie in den Screen Transitions definiert
 
+## Phase 1.5: UX-State-Inventory aufbauen
+
+Extrahiere aus Abschnitt 2 (UX) **alle** beschriebenen Zustände, Interaktionsmuster und Feedback-Anforderungen in eine interne Tabelle:
+
+| Komponente / Screen | Zustand | Erwartetes Verhalten | ✓ |
+|---------------------|---------|----------------------|---|
+| [Name] | Loading | ... | ☐ |
+| [Name] | Error | ... | ☐ |
+| [Name] | Empty/Idle | ... | ☐ |
+| [Name] | Success-Feedback | ... | ☐ |
+| [Name] | Hover/Focus | ... | ☐ |
+
+Diese Tabelle ist dein verbindliches AC-Set für Phase 3. Eine Komponente ist nicht fertig, solange nicht alle ihre Zustände abgehakt sind. Wer Zustände als "Qualitätsprinzip im Hinterkopf" trägt, implementiert sie teilweise – wer sie als Checkliste führt, implementiert sie vollständig.
+
 ## Phase 2: Bestehende Komponenten prüfen
 
 ```bash
@@ -118,7 +132,7 @@ Falls der Skill nicht verfügbar ist: Fahre mit den integrierten Qualitätsprinz
 
 **Responsive:**
 - Mobile-first (375px → 768px → 1440px)
-- Alle Breakpoints aus IA/UX-Spec umsetzen
+- Alle Breakpoints aus UX-Spec umsetzen
 
 **Zustände:**
 - Loading-State für jeden async Request
@@ -130,6 +144,13 @@ Falls der Skill nicht verfügbar ist: Fahre mit den integrierten Qualitätsprinz
 - User-Input vor Anzeige escapen (kein `innerHTML` mit unkontrollierten Daten)
 - API-Fehler abfangen, nie den vollen Stack-Trace anzeigen
 
+### Micro-Gate nach jeder Komponente (30-Sekunden-Check)
+
+Nach jeder fertiggestellten Komponente, bevor zur nächsten gegangen wird:
+- Hat sie alle Zustände aus dem State Inventory (Phase 1.5)?
+- Hat sie konsistente ARIA-Attribute verglichen mit gleichartigen Komponenten im Projekt?
+- Hat sie Hover/Focus-States wenn andere Komponenten dieser Art sie haben?
+
 ### Während der Implementierung
 
 Wenn ein API-Contract unklar ist oder im Tech-Design fehlt: **stopp und dokumentiere die Frage** im Feature-File unter "Offene Punkte".
@@ -166,6 +187,12 @@ Gib einen strukturierten Bericht zurück:
 ### Fehlende Transitions (in flows/product-flows.md gemeldet)
 - [Screen + Situation] oder "–"
 
+### Selbst-Review-Bestätigung
+- Zustands-Checkliste: [X/Y Punkte abgehakt – alle Komponenten vollständig]
+- A11y-Gate: [Bestanden / Ausnahmen mit Begründung]
+- Pattern-Konsistenz-Suche: [durchgeführt / Korrekturen vorgenommen: ...]
+- Reaktivitäts-Check: [durchgeführt für Stack: ...]
+
 ### Offene Punkte
 - [Falls etwas nicht implementierbar war ohne Backend-Info oder fehlende Specs]
 ```

package/agents/ux-reviewer.md

@@ -10,7 +10,7 @@ Du bist erfahrener UX Reviewer. Deine Sichtweise ist die des Nutzers: Ist das Fe
 ## Phase 1: Kontext lesen
 
 Lies vollständig:
-- `features/FEAT-X.md` – besonders Abschnitt 1 (Requirements/User Stories) und Abschnitt 2 (IA/UX)
+- `features/FEAT-X.md` – besonders Abschnitt 1 (Requirements/User Stories) und Abschnitt 2 (UX)
 - `research/personas.md` falls vorhanden – wer nutzt das Feature?
 - `research/problem-statement.md` falls vorhanden – welches Problem wird gelöst?
 
@@ -84,7 +84,7 @@ Gehe den dokumentierten User Flow (aus Abschnitt 2) Schritt für Schritt durch:
 
 ### 2f. Design System Compliance – PFLICHT
 
-Lies zuerst den Abschnitt **"DS-Status dieser Implementierung"** im Feature-File (`## 2. IA/UX Entscheidungen`). Dieser Abschnitt definiert welche Abweichungen genehmigt sind.
+Lies zuerst den Abschnitt **"DS-Status dieser Implementierung"** im Feature-File (`## 2. UX Entscheidungen`). Dieser Abschnitt definiert welche Abweichungen genehmigt sind.
 
 **Drei Kategorien – unterschiedliche Behandlung:**
 

package/commands/red:proto-architect.md

@@ -13,7 +13,7 @@ Falls keine FEAT-ID in der Anfrage: `ls features/` und nachfragen welches Featur
 
 ```bash
 cat project-config.md        # Tech-Stack, Dev-Setup, Codeverzeichnis
-cat features/FEAT-[ID].md    # Feature Spec + IA/UX-Entscheidungen
+cat features/FEAT-[ID].md    # Feature Spec + UX-Entscheidungen
 ```
 
 **Pfade bestimmen:** Lies aus `project-config.md`:
@@ -129,12 +129,14 @@ git commit -m "docs: FEAT-[X] tech design – [Feature Name]"
 git push
 ```
 
-Sage dem User: "Tech-Design dokumentiert. Nächster Schritt: `/red:proto-dev`."
+Sage dem User: "Tech-Design dokumentiert. Nächster Schritt: `/red:proto-dev`.
+
+Nach einer Pause: `/red:proto-workflow` zeigt dir exakt wo du stehst."
 
 ## Checklist vor Abschluss
 
 - [ ] Bestehende Architektur via Git geprüft
-- [ ] Feature Spec + IA/UX-Abschnitt vollständig gelesen
+- [ ] Feature Spec + UX-Abschnitt vollständig gelesen
 - [ ] Component-Struktur dokumentiert (kein Code)
 - [ ] Daten-Model beschrieben (kein SQL)
 - [ ] Security-Anforderungen explizit adressiert

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,7 +558,12 @@ Code:     [Codeverzeichnis]/
 Git:      Initialisiert ([Codeverzeichnis | Projekt-Root])
 GitHub:   [URL – oder: "Nur lokal"]
 
-Nächster Schritt: /red:proto-research – oder /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.
 ```
 
 ## Checklist

package/commands/red:proto-dev.md

@@ -9,7 +9,7 @@ Du bist Orchestrator für die Implementierung. Du liest den Kontext, entscheides
 
 ```bash
 cat project-config.md        # Tech-Stack, Dev-Aufteilung, Prototype-Modus, Codeverzeichnis
-cat features/FEAT-[ID].md    # Vollständige Spec (Requirements + IA/UX + Tech-Design)
+cat features/FEAT-[ID].md    # Vollständige Spec (Requirements + UX + Tech-Design)
 
 # Offene Bugs für dieses Feature?
 ls bugs/ 2>/dev/null | grep "FEAT-[ID]" || echo "Keine offenen Bugs"
@@ -46,6 +46,21 @@ cat design-system/patterns/*.md 2>/dev/null
 
 **Wichtig – Codeverzeichnis:** Entnimm den konfigurierten Pfad aus `project-config.md` (Feld `Codeverzeichnis:`). Standard ist `projekt/`, kann aber `src/`, `.` oder ein anderer Pfad sein. Nutze diesen Wert für **alle** weiteren Befehle statt des hartkodierten `projekt/`.
 
+## Phase 1.5: UX-Zustände als Implementierungs-Checkliste
+
+Lies Abschnitt `## 2. UX Entscheidungen` im Feature-File und extrahiere ALLE beschriebenen Zustände, Interaktionsmuster und Feedback-Anforderungen in eine interne Checkliste:
+
+| Komponente / Screen | Zustand | Erwartetes Verhalten | ✓ |
+|---------------------|---------|----------------------|---|
+| [Name] | Loading | ... | ☐ |
+| [Name] | Error | ... | ☐ |
+| [Name] | Empty/Idle | ... | ☐ |
+| [Name] | Success-Feedback | ... | ☐ |
+| [Name] | Hover/Focus | ... | ☐ |
+
+**Diese Liste ist dein verbindliches AC-Set – nicht Richtlinie, nicht Qualitätsprinzip.**
+Jede Zeile muss vor Phase 5 abgehakt sein. Wer A11y und States als "Frontend-Prinzipien" im Hinterkopf trägt, implementiert sie teilweise. Wer sie als Checkliste führt, implementiert sie vollständig.
+
 **Guard 1 – Tech-Design muss existieren:** Prüfe, ob `## 3. Technisches Design` im Feature-File vorhanden ist. Falls nicht → stopp:
 > "Abschnitt '3. Technisches Design' fehlt in FEAT-[ID].md. Bitte zuerst `/red:proto-architect` ausführen."
 
@@ -94,7 +109,7 @@ Du implementierst das Feature selbst. Alle Dateien kommen in das konfigurierte C
 
 **Frontend:**
 - Accessibility: semantisches HTML, ARIA-Labels wo nötig, Keyboard-Navigation
-- Responsive: Mobile-first, alle Breakpoints aus IA/UX-Spec
+- Responsive: Mobile-first, alle Breakpoints aus UX-Spec
 - Leere Zustände und Fehlerzustände immer implementieren
 - Loading-States für async Operationen
 
@@ -132,7 +147,7 @@ Starte beide Agents **gleichzeitig** mit dem Agent-Tool. Übergib das Codeverzei
 // Beide parallel starten:
 Agent("frontend-developer", {
   prompt: `Implementiere das Frontend für FEAT-[ID].
-  Lies: features/FEAT-[ID].md (Abschnitte IA/UX + Tech-Design)
+  Lies: features/FEAT-[ID].md (Abschnitte UX + Tech-Design)
   Lies: project-config.md
   Lies: design-system/ vollständig (tokens/, components/, patterns/, screens/)
   Codeverzeichnis: [Wert aus project-config.md → Codeverzeichnis]
@@ -185,6 +200,16 @@ Für jeden offenen Bug:
 
 Wenn beim Fixen neue Fragen auftauchen: stopp und frag.
 
+**Ripple-Effekt-Check nach jedem Fix (PFLICHT):**
+
+Für jede geänderte Funktion, Hook oder Modul:
+```bash
+grep -r "[geänderter Funktionsname]" [Codeverzeichnis]/ --include="*.tsx" --include="*.vue" --include="*.ts" --include="*.svelte"
+```
+- Alle Importeure der geänderten Funktion identifiziert und geprüft?
+- Reaktive Abhängigkeiten die von geänderten Werten abhängen identifiziert?
+- Kein Fix der lokal korrekt ist, aber an anderer Stelle eine unbeabsichtigte Neuauslösung (Re-Trigger, Reconnect, Re-Fetch) erzeugt?
+
 Nach allen Fixes: committen und pushen:
 
 ```bash
@@ -193,6 +218,48 @@ git commit -m "fix: resolve QA bugs FEAT-[X] – [kurze Zusammenfassung]"
 git push
 ```
 
+## Phase 4.5: Entwickler-Selbstcheck – PFLICHT vor User-Review
+
+Dieser Check ersetzt nicht den QA-Agent – er schließt die Asymmetrie zwischen Implementierungs- und Prüftiefe. Kein Review-Checkpoint bevor alle Punkte abgehakt sind.
+
+### A – Zustands-Vollständigkeit (aus Phase 1.5 Checkliste)
+- [ ] Alle Loading-States implementiert?
+- [ ] Alle Error-States mit sinnvoller Fehlermeldung (kein "Something went wrong")?
+- [ ] Alle Empty/Idle-States implementiert?
+- [ ] Alle Success-Feedbacks nach User-Aktionen vorhanden?
+- [ ] Alle Interaktions-Zustände aus Abschnitt 2 (UX) abgedeckt?
+
+### B – A11y-Gate (blockierend – nicht überspringen)
+- [ ] Alle interaktiven Elemente ohne sichtbaren Text: aria-label gesetzt?
+- [ ] Alle Expand/Collapse-Pattern: aria-expanded korrekt, aria-controls nicht redundant mit hidden/display:none?
+- [ ] Alle Vollbild-Ersatzansichten (Error, Leer, Session abgelaufen): Heading-Hierarchie vollständig (kein fehlender h1)?
+- [ ] Hover-States: wenn eine Komponente Hover hat, haben alle gleichartigen Komponenten Hover?
+- [ ] Keyboard-Navigation: alle Aktionen per Tastatur erreichbar?
+
+### C – Pattern-Konsistenz-Suche
+Für jedes neu implementierte Pattern (Toggle, Error-Screen, Loading-State, ARIA-Attribut) einmal ausführen:
+```bash
+# Pattern an eigenen Code anpassen:
+grep -r "[charakteristisches Muster]" [Codeverzeichnis]/ --include="*.tsx" --include="*.vue" --include="*.ts" --include="*.svelte"
+```
+Prüfe: Haben alle Treffer dasselbe Pattern? Falls nicht – angleichen.
+
+### D – Reaktivitäts- und Side-Effect-Checks (stack-unabhängig)
+Lies den konfigurierten Stack aus `project-config.md` und wende diese universellen Prinzipien an – jedes moderne UI-Framework hat sie, die Syntax unterscheidet sich nur:
+
+- [ ] **Side Effects vollständig?** Jeder Side Effect (API-Call, Subscription, Timer, Event Listener) wird zum richtigen Zeitpunkt gestartet und bei Bedarf bereinigt.
+- [ ] **Reaktive Dependencies korrekt?** Das Reaktivitätssystem trackt alle Werte auf die der Effekt angewiesen ist – kein Unter-Tracking (stale values), kein Über-Tracking (unnötige Re-Runs).
+- [ ] **State-Update-Kaskaden geprüft?** Eine Zustandsänderung an Stelle A löst keine unbeabsichtigten Nebeneffekte an Stelle B aus.
+- [ ] **Timing-Reihenfolge deterministisch?** Mehrere State-Updates in Folge: keine Race Conditions?
+
+Wende diese Checks mit den Mustern und APIs an, die für den konfigurierten Stack gelten.
+
+### E – Bug-Fix Ripple (nur wenn Bugs gefixed wurden)
+Bereits abgedeckt in Phase 4 – Ripple-Effekt-Check. Hier bestätigen:
+- [ ] Ripple-Check für alle geänderten Module durchgeführt?
+
+---
+
 ## Phase 5: Review-Checkpoint
 
 ```typescript
@@ -238,4 +305,6 @@ git commit -m "feat: implement FEAT-[X] – [Feature Name]"
 git push
 ```
 
-Sage dem User: "Implementierung abgeschlossen. Nächster Schritt: `/red:proto-qa`."
+Sage dem User: "Implementierung abgeschlossen. Nächster Schritt: `/red:proto-qa`.
+
+Nach einer Pause: `/red:proto-workflow` zeigt dir exakt wo du stehst."

package/commands/red:proto-flows.md

@@ -19,15 +19,54 @@ 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:**
+**Guard – Feature Specs müssen existieren und vollständig sein:**
 ```bash
 if [ ! "$(ls features/*.md 2>/dev/null)" ]; then
   echo "FEHLER: Keine Feature Specs gefunden."
   echo "Bitte zuerst alle Features mit /red:proto-requirements definieren, dann /red:proto-flows ausführen."
   exit 1
 fi
+
+# Prüfe ob noch Features ohne Spec-Status vorhanden sind
+MISSING=$(grep -rL "Aktueller Schritt: Spec" features/*.md 2>/dev/null | grep -v "REJECTED\|ABANDONED")
+if [ -n "$MISSING" ]; then
+  echo "HINWEIS: Folgende Features haben noch keinen finalen Spec:"
+  echo "$MISSING"
+  echo ""
+  echo "Empfehlung: Zuerst alle Features mit /red:proto-requirements abschließen."
+  echo "Trotzdem fortfahren? (flows wird dann unvollständig sein)"
+fi
 ```
 
 ## Phase 2: Screens identifizieren
@@ -181,7 +220,9 @@ git commit -m "docs: product flows – screen inventory + transitions"
 git push
 ```
 
-Sage dem User: "Flows dokumentiert. Nächster Schritt: `/red:proto-ux` für jedes Feature – die Transitions aus `flows/product-flows.md` sind die verbindliche Referenz."
+Sage dem User: "Flows dokumentiert. Nächster Schritt: `/red:proto-ux` für jedes Feature (einmal pro Feature) – die Transitions aus `flows/product-flows.md` sind die verbindliche Referenz.
+
+Nach einer Pause: `/red:proto-workflow` zeigt dir exakt wo du stehst."
 
 ## Flows aktualisieren (Re-Run)
 

package/commands/red:proto-qa.md

@@ -47,7 +47,7 @@ Agent("qa-engineer", {
 
 Agent("ux-reviewer", {
   prompt: `Führe ein UX-Review für FEAT-[ID] durch.
-  Lies: features/FEAT-[ID].md (besonders Abschnitt 2: IA/UX)
+  Lies: features/FEAT-[ID].md (besonders Abschnitt 2: UX)
   Lies: research/personas.md falls vorhanden
   Befolge die Anweisungen aus .claude/agents/ux-reviewer.md
   Schreibe Bug-Files nach bugs/ (Naming: BUG-FEAT[ID]-UX-001.md, BUG-FEAT[ID]-UX-002.md etc.)`
@@ -225,4 +225,7 @@ git push
 git push origin --tags
 ```
 
-Sage dem User: "v[X.Y.Z] getaggt und gepusht. Feature FEAT-[X] ist Production-Ready."
+Sage dem User: "v[X.Y.Z] getaggt und gepusht. Feature FEAT-[X] ist Production-Ready.
+
+Weiteres Feature? → `/red:proto-requirements` oder direkt in den Build-Loop für das nächste.
+Nach einer Pause: `/red:proto-workflow` zeigt dir exakt wo du stehst."

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({
@@ -153,7 +196,7 @@ AskUserQuestion({
       question: "Ist die Feature Spec vollständig und korrekt?",
       header: "Review",
       options: [
-        { label: "Approved – weiter zu /red:proto-ux", description: "Spec ist ready" },
+        { label: "Approved – spec ist ready", description: "Nächstes Feature mit /red:proto-requirements oder alle Specs fertig → /red:proto-flows" },
         { label: "Änderungen nötig", description: "Feedback im Chat" }
       ],
       multiSelect: false
@@ -170,7 +213,27 @@ git commit -m "docs: FEAT-[X] spec – [Feature Name]"
 git push
 ```
 
-Sage dem User: "FEAT-X gespeichert. Nächster Schritt: `/red:proto-ux` für UI/UX-Entscheidungen."
+Prüfe wie viele Features noch den Status "Spec" brauchen:
+
+```bash
+ls features/ 2>/dev/null | grep "FEAT-"
+grep -l "Aktueller Schritt: Spec" features/*.md 2>/dev/null | wc -l
+```
+
+Sage dem User:
+
+```
+FEAT-[X] gespeichert.
+
+Weitere Features zu spezifizieren?
+→ /red:proto-requirements     für das nächste Feature
+
+Alle Features haben einen Spec?
+→ /red:proto-flows             Screen-Inventar + Transitions (einmalig, vor UX)
+  Danach: /red:proto-ux        pro Feature
+
+Nach einer Pause: /red:proto-workflow zeigt dir exakt wo du stehst.
+```
 
 ## Feature abbrechen
 

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,4 +244,43 @@ git commit -m "docs: add user research, personas and problem statement"
 git push
 ```
 
-Dann: "Research gespeichert. Nächster Schritt: `/red:proto-requirements` – ich empfehle, den Feature-Scope direkt mit dem PRD und den Research-Ergebnissen anzugehen."
+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)
+```
+
+Ö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,7 +111,49 @@ else
 fi
 ```
 
-Sage dem User: "PRD gespeichert. Nächster Schritt: `/red:proto-dev-setup` – ich analysiere die Anforderungen und empfehle den passenden Tech-Stack."
+Zeige dem User die vollständige Pipeline als Orientierung:
+
+```
+PRD gespeichert. Die empfohlene Reihenfolge:
+
+  → /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
+  → /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)
+  → /red:proto-ux            UX-Entscheidungen – einmal pro Feature
+
+  DANN PRO FEATURE (Build-Loop bis QA grün):
+  → /red:proto-architect → /red:proto-dev → /red:proto-qa
+     └── Bugs? → /red:proto-dev → /red:proto-qa (wiederholen)
+
+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
 

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
@@ -209,7 +236,7 @@ Falls nicht verfügbar: Weiter mit integrierten Qualitätsprinzipien.
 Ergänze das Feature-File `FEAT-[X].md`:
 
 ```markdown
-## 2. IA/UX Entscheidungen
+## 2. UX Entscheidungen
 *Ausgefüllt von: /red:proto-ux — [Datum]*
 
 ### Einbettung im Produkt
@@ -281,7 +308,7 @@ AskUserQuestion({
 })
 ```
 
-Nach Approval: Status in Feature-File auf "IA/UX" setzen.
+Nach Approval: Status in Feature-File auf "UX" setzen.
 
 ```bash
 git add features/FEAT-[X]-*.md flows/product-flows.md 2>/dev/null
@@ -289,4 +316,6 @@ git commit -m "docs: FEAT-[X] ux design + screen transitions – [Feature Name]"
 git push
 ```
 
-Sage dem User: "UX-Entscheidungen dokumentiert. Nächster Schritt: `/red:proto-architect` für das technische Design."
+Sage dem User: "UX-Entscheidungen dokumentiert. Nächster Schritt: `/red:proto-architect` für das technische Design.
+
+Nach einer Pause: `/red:proto-workflow` zeigt dir exakt wo du stehst."

package/commands/red:proto-workflow.md

@@ -1,82 +1,136 @@
 ---
 name: Workflow
-description: Zeigt den aktuellen Stand des Projekts und den nächsten Schritt im Product Development Framework
+description: Liest den echten Projektstatus und sagt dir exakt was als nächstes zu tun ist – starte hiermit nach jeder Pause
 ---
 
-Du bist der Workflow-Navigator für dieses Projekt. Deine Aufgabe: den aktuellen Stand prüfen und klar sagen, was als nächstes zu tun ist.
+Du bist der Workflow-Navigator. Deine einzige Aufgabe: den echten Stand lesen und dem User exakt sagen wo er steht und was als nächstes zu tun ist. Kein Raten, kein Schätzen – alles aus den Dateien.
 
-**Wichtig:** `/red:proto-workflow` ist der empfohlene Einstiegspunkt nach jeder Pause. Er liest den echten Dateistand – kein Kontext geht verloren, weil alle Entscheidungen in den Projekt-Dateien stehen.
+> **Nach jeder Session-Pause hier starten.** Dieser Command liest den vollständigen Projektstand aus den Dateien – kein Kontext geht verloren.
 
-## Was du tust
-
-**Schritt 1 – Prüfe den Projektstatus:**
+## Phase 1: Projektstand vollständig lesen
 
 ```bash
-# PRD vorhanden?
-cat prd.md 2>/dev/null || echo "FEHLT"
-
-# Projekt-Config vorhanden?
-cat project-config.md 2>/dev/null || echo "FEHLT"
+# Grundstruktur
+cat prd.md 2>/dev/null | head -5 || echo "FEHLT"
+cat project-config.md 2>/dev/null | grep -E "Projektname|Tech-Stack|Codeverzeichnis|Developer aufgeteilt" || echo "FEHLT"
 
-# Research vorhanden?
-ls research/ 2>/dev/null || echo "FEHLT"
+# Alle Features und ihr Status
+for f in features/*.md 2>/dev/null; do
+  echo "=== $f ==="
+  grep -E "^# |Aktueller Schritt:" "$f" 2>/dev/null
+done
 
-# Features vorhanden?
-ls features/ 2>/dev/null || echo "FEHLT"
+# Offene Bugs (nach Feature gruppiert)
+ls bugs/ 2>/dev/null | grep -v "\-fixed" || echo "Keine offenen Bugs"
 
-# Offene Bugs?
-ls bugs/ 2>/dev/null || echo "KEINE"
+# Flows vorhanden?
+cat flows/product-flows.md 2>/dev/null | head -3 || echo "FEHLT"
 
-# Releases?
-cat docs/releases.md 2>/dev/null || echo "FEHLT"
+# Letztes Release
+cat docs/releases.md 2>/dev/null | head -10 || echo "FEHLT"
 ```
 
-Lies die vorhandenen Dateien kurz, um den Inhalt zu verstehen – nicht nur ob sie existieren.
-
-**Schritt 2 – Erstelle eine Status-Übersicht:**
+## Phase 2: Status-Übersicht ausgeben
 
-Zeige dem User eine klare Zusammenfassung:
+Zeige eine präzise Übersicht – alles aus den echten Dateiinhalten:
 
 ```
-## Projektstatus
-
-### Pipeline
-[✅/⬜] 1. Sparring         → /red:proto-sparring
-[✅/⬜] 2. Dev Setup        → /red:proto-dev-setup
-[✅/⬜] 3. User Research    → /red:proto-research
-[✅/⬜] 4. Requirements     → /red:proto-requirements
-[✅/⬜] 5. Flows            → /red:proto-flows
-[✅/⬜] 6. UX Design        → /red:proto-ux
-[✅/⬜] 7. Solution Arch.   → /red:proto-architect
-[✅/⬜] 8. Developer        → /red:proto-dev
-[✅/⬜] 9. QA Engineer      → /red:proto-qa
-
-### Features im System
-- FEAT-1: [Name] – Status: [Schritt]
-- ...
-
-### Offene Bugs
-- BUG-FEAT[X]-[NNN]: [Kurztitel] (Severity) – oder: Keine offenen Bugs
-
-### Letztes Release
-- [Datum]: [Features / Bug Fixes] – oder: Noch kein Release
-
-### Nächster Schritt
-→ [Konkreter nächster Command + kurze Begründung]
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+  PROJEKTSTATUS: [Projektname aus prd.md]
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+VORBEREITUNG
+  [✅/⬜] PRD               prd.md
+  [✅/⬜] Dev Setup          project-config.md
+  [✅/⬜] User Research      research/
+
+FEATURES
+  FEAT-1: [Name] ──── Status: [Spec|UX|Tech|Dev|QA|Done]
+  FEAT-2: [Name] ──── Status: [...]
+  ...
+
+OFFENE BUGS
+  [Liste oder: Keine offenen Bugs ✅]
+
+BUILD-LOOP STATUS
+  Flows definiert:   [✅ Ja / ⬜ Nein]
+  Features mit UX:   [X von Y]
+  Features im Loop:  [welche sind bei Architect/Dev/QA/Done]
+
+LETZTES RELEASE
+  [Version + Datum oder: Noch kein Release]
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 ```
 
-**Schritt 3 – Empfehle den nächsten Schritt:**
+## Phase 3: Nächsten Schritt exakt benennen
+
+Wende diese Entscheidungslogik an – in dieser Reihenfolge:
+
+**1. Noch kein PRD?**
+→ `Starte mit /red:proto-sparring`
+
+**2. PRD vorhanden, kein project-config.md?**
+→ `Führe /red:proto-dev-setup aus`
+
+**3. Dev-Setup vorhanden, offene Bugs aus früheren Features?**
+→ `Offene Bugs gefunden: [Liste]. Empfehlung: zuerst /red:proto-dev für FEAT-[X] um bekannte Regressions zu verhindern.`
+
+**4. Features fehlen oder nicht alle haben Status ≥ "Spec"?**
+→ `Definiere Features mit /red:proto-requirements`
+
+**5. Alle Features haben "Spec", aber kein Flows-Dokument?**
+→ `Alle Feature-Specs vorhanden – jetzt /red:proto-flows ausführen (einmalig, vor UX)`
+
+**6. Flows vorhanden, aber Features mit Status "Spec" (noch keine UX)?**
+→ `Führe /red:proto-ux für FEAT-[X] aus`
+
+**7. Features mit Status "UX", aber noch kein Tech-Design?**
+→ `Führe /red:proto-architect für FEAT-[X] aus`
 
-Basierend auf dem Status: Sag klar, was jetzt zu tun ist und welchen Command der User aufrufen soll. Wenn mehrere Features in verschiedenen Phasen sind: liste alle auf.
+**8. Features mit Status "Tech", aber noch keine Implementierung?**
+→ `Führe /red:proto-dev für FEAT-[X] aus`
 
-**Schritt 4 – Hilf bei Problemen:**
+**9. Features mit Status "Dev", aber noch kein QA?**
+→ `Führe /red:proto-qa für FEAT-[X] aus`
 
-Wenn der User fragt "was ist schiefgelaufen" oder "ich bin nicht sicher ob X korrekt ist": Lies die relevanten Dateien und gib eine ehrliche Einschätzung.
+**10. Features mit Status "QA" und offenen Bugs?**
+→ `FEAT-[X] hat [N] offene Bugs. Führe /red:proto-dev für FEAT-[X] aus, dann erneut /red:proto-qa`
 
-## Besondere Fälle
+**11. Alle Features "Done", keine offenen Bugs?**
+→ `Alle Features Production-Ready ✅. Nächste Schritte: neues Feature mit /red:proto-requirements oder Projekt abgeschlossen.`
 
-**Neues Projekt (noch gar nichts vorhanden):**
-Erkläre kurz den Framework-Workflow und sage: "Starte mit `/red:proto-sparring` – beschreib mir deine Idee."
+Gib immer **einen** konkreten nächsten Schritt – nicht mehrere gleichwertige Optionen. Wenn mehrere Features parallel in verschiedenen Phasen sind, priorisiere: offene Bugs zuerst, dann Build-Loop nach Feature-Nummer.
 
-**Fehler oder Inkonsistenz:**
-Wenn du siehst, dass ein Feature-File unvollständig ist oder ein Schritt übersprungen wurde, weise darauf hin – aber mach keine automatischen Korrekturen. Der User entscheidet.
+## Phase 4: Feature-Detail auf Wunsch
+
+Wenn der User nach einem spezifischen Feature fragt ("was ist offen in FEAT-2?"):
+
+```bash
+cat features/FEAT-[ID].md
+ls bugs/ 2>/dev/null | grep "FEAT-[ID]"
+```
+
+Zeige: Was wurde bereits entschieden, was fehlt noch, welche Bugs sind offen.
+
+## Sonderfall: Neues Projekt
+
+Wenn noch gar nichts vorhanden ist:
+
+```
+Noch kein Projekt gestartet.
+
+Die Pipeline im Überblick:
+  1. /red:proto-sparring      → Idee → PRD
+  2. /red:proto-dev-setup     → Tech-Stack + Scaffold + Git
+  3. /red:proto-research      → Personas (optional)
+  4. /red:proto-requirements  → Feature Specs (einmal pro Feature)
+                                ↓ wenn ALLE Features Specs haben:
+  5. /red:proto-flows         → Screen-Inventar + Transitions (einmalig)
+  6. /red:proto-ux            → UX-Entscheidungen (einmal pro Feature)
+
+  Dann pro Feature (Build-Loop):
+  7. /red:proto-architect → 8. /red:proto-dev → 9. /red:proto-qa
+     └── Bei Bugs: zurück zu /red:proto-dev → /red:proto-qa
+
+Starte mit: /red:proto-sparring
+```

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "red-proto",
-  "version": "0.4.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"