red-proto 0.7.0 → 0.9.0

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

@@ -143,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",
@@ -158,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
     }
@@ -176,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

package/commands/red:proto-requirements.md

@@ -98,51 +98,19 @@ Faustregel: Kann es unabhängig getestet werden? Hat es eine andere User-Rolle?
 
 Bei Zweifel: aufteilen und begründen.
 
-## Phase 4: Feature verstehen
+## Phase 4: Spec autonom erstellen
 
-```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
-    }
-  ]
-})
-```
-
-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 5: 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 6: Feature Spec schreiben
 

package/commands/red:proto-research.md

@@ -152,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
 

package/commands/red:proto-ux.md

@@ -59,62 +59,21 @@ 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
+## Phase 3: Autonome UX-Analyse
 
-```typescript
-AskUserQuestion({
-  questions: [
-    {
-      question: "Wo im Produkt lebt dieses Feature?",
-      header: "Einbettung",
-      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" }
-      ],
-      multiSelect: false
-    }
-  ]
-})
-```
+**Du entscheidest – nicht der Nutzer.** Leite alle UX-Entscheidungen selbst aus dem gelesenen Kontext ab: PRD, Personas, Feature-Spec, Design System, Flows.
 
-## Phase 4: Komponenten-Entscheidung durch UX Designer
+Analysiere und dokumentiere intern:
 
-**Du fragst – der Designer entscheidet:**
+**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").
 
-```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
-    }
-  ]
-})
-```
+**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").
 
-Nimm die genannte Liste entgegen. Dann:
+**Komponenten-Auswahl:** Wähle alle benötigten Komponenten eigenständig aus `design-system/components/`. Begründe jede Wahl kurz. Prüfe dann:
 
-### DS-Validierung
+## Phase 4: DS-Validierung
 
-Prüfe für jede genannte Komponente ob eine Spec in `design-system/components/` existiert:
+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
@@ -168,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:**
 
@@ -187,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
@@ -200,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
 
@@ -268,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.7.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"