--- name: feature-intake description: Use when the user wants to discover, brainstorm, or collect features before planning, OR when the user wants to clarify open questions on existing Planungsbüro tickets. Triggers on: "was könnten wir als nächstes bauen", "schick gekko einen Fragebogen", "feature-ideen sammeln", "klär die offenen Fragen im Planungsbüro", "planungsbüro tickets klären", "plan-ready machen", "offene Fragen", "gekkomode", "frag gekko", "interview gekko", "was braucht gekko", "gekko befragen", or any pre-planning feature-discovery or ticket-clarification session. --- # feature-intake — Feature-Entdeckung, PM-Fragebogen & Planungsbüro-Klärung ## Überblick Dieser Skill ist dem `dev-flow-plan` **vorgelagert**: er sammelt Feature-Ideen und überführt sie in plan-ready Tickets. Vier Modi: | Modus | Wann | Ergebnis | |-------|------|---------| | **Planungsbüro-Klärung** | Bestehende `planning`-Tickets haben offene Fragen / fehlende Readiness-Flags | HTML-Klärungsformular pro Ticket → Antworten ins Ticket schreiben | | **Brainstorm** | User will jetzt live mitreden / frei ideieren | Strukturierte Feature-Liste → direkt zu `dev-flow-plan` | | **HTML-Formular** | Auswahl + Priorisierung neuer Ideen per Klick — **für Patrick oder gekko** | HTML-Formular → ausgefülltes Markdown → `dev-flow-plan` | | **GekkoMode** | Offenes Entdeckungs-Interview mit gekko — Schmerzen + Wünsche herauskitzeln | Interview-HTML-Formular → strukturierter Rücklauf → neue `planning`-Tickets | **Standard-Annahme:** Patrick füllt lieber ein **HTML-Formular** aus als inline zu tippen (siehe Memory „Grilling via HTML form"). Im Zweifel **generiere das Formular** und liefere es per `SendUserFile`. --- ## Modus-Wahl ``` User nennt "gekkomode" / "frag gekko" / "interview gekko" / "was braucht gekko" → GekkoMode (Modus D) — PRIORITÄT vor B und A User spricht von "Planungsbüro", "klären", "offene Fragen", "plan-ready", "Readiness", oder will bestehende planning-Tickets vorbereiten? → Planungsbüro-Klärung (Modus C) — PRIORITÄT vor B und A User will Features nur auswählen + priorisieren (wenig tippen), ODER "schick gekko einen Fragebogen" / "PM soll entscheiden" / "mach mir ein Formular" OHNE Entdeckungscharakter (Ideen bereits bekannt)? → HTML-Formular-Modus (Modus B) — Empfänger = Patrick oder gekko User will JETZT frei mitdenken / Cluster live durchgehen? → Brainstorm-Modus (Modus A) ``` --- ## Modus C: Planungsbüro-Klärungsrunde **Sage:** "Ich lade alle Planungsbüro-Tickets und leite offene Fragen ab." ### Schritt 1 — Tickets laden ```bash PLANNING_ROWS=$(kubectl exec -n workspace deploy/shared-db -- psql -U postgres -d website -t -A -F '|' -c \ "SELECT external_id, title, priority, COALESCE(value_prop,''), COALESCE(effort,''), array_to_string(areas,','), COALESCE(description,''), readiness::text, COALESCE(array_to_string(depends_on,','),'') FROM tickets.tickets WHERE status='planning' ORDER BY planning_rank ASC NULLS LAST, created_at DESC;" 2>/dev/null) if [[ -z "$PLANNING_ROWS" ]]; then echo "ℹ️ Keine planning-Tickets vorhanden. Modus C entfällt — stattdessen Modus A oder B starten?" exit 0 fi ``` ### Schritt 2 — Offene Fragen pro Ticket ableiten Für jedes Ticket prüfe die Readiness-Flags und leite daraus konkrete Fragen ab: #### Gültige Readiness-Schlüssel (alle 4 Pflicht-Flags) | Schlüssel | Bedeutung | Abzuleitende Frage wenn `false` | |-----------|-----------|--------------------------------| | `spec_skizziert` | Kernfunktionalität beschrieben | Beschreibe die Kernfunktionalität in 2-3 Sätzen. Was ist explizit NICHT im Scope? | | `abhaengigkeiten_klar` | Blockierende Tickets/Dienste bekannt | Welche anderen Tickets / Features müssen VORHER fertig sein? Welche externen Dienste werden benötigt? | | `offene_fragen_geklaert` | Domain-Fragen beantwortet | → Domain-spezifische Fragen (siehe unten) | | `aufwand_geschaetzt` | Aufwand grob geschätzt | Wie groß schätzt du den Aufwand? (klein ≤1d / mittel 2-4d / groß ≥1W) | > **Wichtig:** Nur diese exakten Schlüssel in `--readiness` verwenden — `ticket.sh` parst sie als freeform JSON, falsch geschriebene Keys werden stillschweigend ignoriert. #### Domain-spezifische Fragen nach `areas` **brett:** Welche Benutzerrollen sind betroffen? Soll das Feature auf Mobilgeräten vollständig funktionieren? Wie verhält sich das Feature bei Verbindungsunterbrechungen? Gibt es Abhängigkeiten zu bestehenden Brett-Figuren oder Board-States? **website:** Für welche Benutzergruppe? (Admin / Endkunde / beide) — Beide Brands oder nur eine? — Sollen Änderungen versioniert werden? — SEO-relevant? **chat:** Real-time (WebSocket) oder darf kurze Verzögerung akzeptabel sein? — Benachrichtigungen: E-Mail, Push oder nur in-App? — DSGVO-Löschkonzept nötig? **infra:** Beide Brands deployen oder nur eine? — Breaking Change? Rollout-Strategie? — Ressourcenschätzung bekannt? **auth:** Betrifft beide Keycloak-Realms? — Opt-in für bestehende User oder erzwungen? — Rollback-Plan? **ai/factory:** Welche Modelle (Claude / DeepSeek) betroffen? — Dry-run-Modus nötig? — Wie messen wir Erfolg? ### Schritt 3 — HTML-Klärungsformular generieren Generiere ein **eigenständiges HTML-Formular** (kein Backend, läuft via `file://`) direkt mit dem `Write`-Tool — **nicht** das pm-form-template.html kopieren (das ist Modus B). Dieses Formular wird **dynamisch aus den Ticket-Daten** aufgebaut. **Datei:** `/tmp/planungsbuero-klaerung-.html` **Formular-Struktur pro Ticket-Section:** ```
Ticket-Header: ID + Titel + Priorität-Badge Metadaten: Bereich, Aufwand, value_prop Readiness-Ampel: 🟢 true / 🔴 false pro Flag
— nur wenn abhaengigkeiten_klar: false Text-Input "Welche Tickets müssen vorher fertig sein?" + structured follow-ups
— nur wenn spec_skizziert: false Textarea für Kernflow-Beschreibung + Not-Scope
— immer wenn offene_fragen_geklaert: false Domain-spezifische Radio/Checkbox-Fragen basierend auf areas
``` **Technische Anforderungen:** - Dark Theme (`background: #0d1117; color: #c9d1d9`) - Alle Form-Felder mit `name="_"` — Ticket-Bezug für `buildMarkdown()` - Structured fields bevorzugen: Radio/Checkbox für Ja/Nein/Optionen, Textarea nur für Freitext - „Markdown kopieren"-Button mit `navigator.clipboard` + Fallback-Textarea für `file://` - Fortschrittsbalken (wie viele Tickets ausgefüllt) - `buildMarkdown()` erzeugt `### — ` pro Ticket mit allen `- **Frage**: Antwort`-Zeilen ### Schritt 4 — Formular liefern Liefere die Datei per `SendUserFile`. Sage: "Ausfüllen → ‚Markdown kopieren' → hier einfügen." ### Schritt 5 — Antworten verarbeiten (nach Rücklauf) Wenn das ausgefüllte Markdown zurückkommt, verarbeite **pro Ticket**: #### 5a — Kommentar im Ticket hinterlegen ```bash bash scripts/ticket.sh add-comment \ --id \ --author "feature-intake" \ --body "## Klärungsrunde $(date +%F) **Abhängigkeiten:** **Brand-Scope:** **Spec-Skizze:** **Domain-Fragen:** - : " ``` #### 5b — Vollständigkeits-Check (Vorbedingung für Spec-Generierung) Prüfe den Rücklauf auf Vollständigkeit bevor die Spec generiert wird: | Block | Prüfung | BLOCK wenn | |-------|---------|------------| | Block 1 — Ablauf | Textarea-Länge | < 20 Zeichen | | Block 1 — Nutzergruppe | Feld vorhanden + nicht leer | Fehlt | | Block 2 — Nicht-Scope | ≥1 Checkbox ODER Freitext | Beides leer | | Block 3 — Edge Cases | ≥1 Checkbox ODER Freitext | Beides leer | | Block 5 — Fehlerfall | Radio ausgewählt | Nicht gesetzt | | Block 6 — Erfolgsmetrik | Radio ODER Freitext | Beides leer | **Bei unvollständigem Rücklauf:** Gib aus: ``` ⛔ Spec-Generierung blockiert — folgende Blöcke fehlen oder sind leer: • [Liste der fehlenden Blöcke] → Bitte das Grilling-Formular erneut öffnen und die markierten Felder ausfüllen: /tmp/grilling--.html ``` Stoppe hier — führe Schritt 5c NICHT aus. **Bei vollständigem Rücklauf:** Fahre direkt mit Schritt 5c fort. #### 5c — Spec-Datei generieren und schreiben Destilliere die Grilling-Antworten in eine vollständige Spec. Dateiname: ```bash SPEC_SLUG=$(echo "" | tr '[:upper:]' '[:lower:]' | sed 's/[^a-z0-9]/-/g' | sed 's/--*/-/g' | sed 's/^-\|-$//g') SPEC_FILE="docs/superpowers/specs/$(date +%F)-${SPEC_SLUG}.md" # Bei Kollision: SPEC_FILE mit -v2 Suffix ``` Schreibe die Datei mit dem `Write`-Tool nach folgendem Schema (auf Deutsch): ```markdown --- ticket_id: plan_ref: docs/superpowers/plans/-.md status: active date: --- # Spec: ## Kern-Nutzerflow [Prosa aus Block 1 — Schritt-für-Schritt destilliert] ## Akzeptanzkriterien [Testbar formuliert aus Blocks 1/3/5/6 — z.B. "Wenn User X tut, erscheint Y"] ## Edge Cases [Liste aus Block 3] ## Fehlerfall-Behandlung [Aus Block 5] ## Erfolgsmetrik [Aus Block 6 — messbar oder beobachtbar] ## Technische Constraints [Aus Ticket-Areas + domain-spezifischen Blöcken + depends_on] ## Betroffene Dateien [Aus areas abgeleitet — grobe Hinweise] ``` Danach den Spec-Inhalt auch als Ticket-Kommentar schreiben: ```bash bash scripts/ticket.sh add-comment \ --id \ --author "feature-intake/spec-generator" \ --body "## Auto-generierte Spec $(date +%F) [vollständiger Spec-Inhalt] --- *Generiert aus Grilling-Rücklauf via feature-intake/spec-generator*" ``` #### 5d — Readiness-Flags aktualisieren Setze einen Flag auf `true` nur wenn die zugehörige Frage tatsächlich beantwortet wurde: ```bash bash scripts/ticket.sh plan-meta set \ --id \ --readiness offene_fragen_geklaert=true,abhaengigkeiten_klar=true,spec_skizziert=true ``` #### 5e — Abhängigkeiten eintragen (wenn konkrete IDs genannt) ```bash bash scripts/ticket.sh plan-meta set \ --id \ --depends-on T000571,T000573 ``` #### 5f — Automatischer Handoff zu dev-flow-plan Nach vollständiger Spec-Generierung übergib direkt an dev-flow-plan — kein STOP, kein manueller Eingriff: ```bash export TICKET_EXT_ID="" # dev-flow-plan erkennt TICKET_EXT_ID und überspringt Ticket-Erstellung ``` Sage: "Spec generiert ✓ — übergebe direkt an dev-flow-plan für die Implementierungsplanung." Rufe dann `dev-flow-plan` auf. #### 5g — Abschluss-Report Gib folgende Zusammenfassung aus: ``` Grilling + Spec-Generierung abgeschlossen für : ✓ Spec-Material als Kommentar hinterlegt (author: feature-intake/grilling) ✓ Auto-Spec generiert: docs/superpowers/specs/ ✓ Spec als Ticket-Kommentar hinterlegt (author: feature-intake/spec-generator) ✓ Readiness-Flags aktualisiert: spec_skizziert=true, offene_fragen_geklaert=true, abhaengigkeiten_klar=true ✓ Handoff zu dev-flow-plan eingeleitet [nur wenn noch Flags fehlen:] Verbleibende offene Flags: 🔴 abhaengigkeiten_klar — noch ausstehend 🔴 aufwand_geschaetzt — noch ausstehend ``` Zeige welche Tickets jetzt vollständig readiness-ready sind (alle 4 Flags true). --- ## Modus D: GekkoMode — Entdeckungs-Interview **Zweck:** Nicht aus einer vordefinierten Liste wählen, sondern *unbekannte* Schmerzen und Wünsche von gekko herauskitzeln — offener Entdeckungscharakter. Das Interview generiert Rohideen, die Claude anschließend in vollständige `planning`-Tickets überführt. **Bekannter Kontext über gekko (nicht abfragen):** - Nutzt die Plattform täglich - Primärgerät: Android-Smartphone → Handy-Usability ist implizit hochpriorisiert - Deadlines sind nebensächlich — kein Deadline-Block im Formular - Kein DocuSeal — Verträge werden intern selbst gebaut, also kein DocuSeal-Fieldset **Formular-Leitprinzipien:** - Kein "Was nutzt du aktiv?"-Filter (Block-1 ist weggefallen) — alle Schmerz-Bereiche direkt zeigen - Kein Ranking-Block — Priorität wird beim Ticket-Anlegen von Claude abgeleitet, nicht von gekko bewertet - Kein Kontext-/Timing-Block - Kernfokus: **Feature-Vorschläge mit Würfeln** + **Schmerz-Freitext** + **Wunschzettel** **Sage:** "Ich erstelle ein Entdeckungs-Interview-Formular für gekko." ### Schritt 1 — Bestehende Tickets laden (Duplikatschutz) ```bash EXISTING=$(kubectl exec -n workspace deploy/shared-db -- psql -U postgres -d website -t -A -F '|' -c \ "SELECT external_id, title, status FROM tickets.tickets WHERE status NOT IN ('done','archived') ORDER BY created_at DESC LIMIT 60;" 2>/dev/null) ``` Halte diese Liste im Arbeitsgedächtnis — sie dient später beim Ticket-Anlegen zum Duplikatcheck. ### Schritt 2 — Interview-HTML-Formular generieren Erstelle `/tmp/gekko-interview-.html` mit dem `Write`-Tool. Das Formular ist ein **eigenständiges, backend-freies HTML**, läuft via `file://`. **Formular-Design:** Dark Theme (`#0d1117` / `#c9d1d9`), große Schrift, viel Weißraum. Überschrift: „Hey gekko — was brauchst du?" Introtext: „5 Minuten. Keine falschen Antworten. Deine Inputs landen direkt im Planungsbüro." #### Formular-Blöcke (genau diese 3, keine anderen) **Block 1 — Feature-Vorschläge mit Würfeln** - Zeige **12 zufällige Features** aus einem großen Pool (~60 Einträge) als anklickbare Karten - Jede Karte: Bereichs-Tag + Feature-Text, Klick = auswählen/abwählen - **„🎲 Neu würfeln"-Button**: lädt 12 neue Karten aus dem Pool — bereits ausgewählte Karten bleiben erhalten und werden als Chips unterhalb angezeigt - Auswahlzähler: „Ausgewählt: N" Feature-Pool — Bereiche und Einträge: | Bereich | Beispiel-Einträge | |---------|------------------| | Brett | Board-Export PNG/PDF, Touch-Drag Android, Figuren-Animationen, Gruppen-Lobby, Zuschauer-Modus, Board-Templates, Verbindungslinien, Figuren filtern, Undo/Redo, Board-Kommentare, Board teilen (Link), Offline-Modus | | Website | Bild-Upload im Editor, Newsletter-Vorlagen, Referenzen-Galerie, SEO-Editor, Zeitgesteuertes Veröffentlichen, Vertrags-PDF-Preview, Kontaktformular-Admin, Mehrsprachigkeit DE/EN, Bewertungs-Modul, Content-Kalender | | Chat | Push-Notifications Android, Emoji-Reaktionen, Thread-Antworten, Datei-Anhänge >10 MB, Gelesen-Bestätigungen, Sprachnachrichten, Nachrichten bearbeiten, DMs, @mention, Link-Vorschau, Kanal-Archiv, Videoanruf | | Nextcloud | Auto-Backup Ordner, Gemeinsames Bearbeiten stabil, Offline Mobile, Ordner-Freigabe vereinfachen, Bilder-Sync | | Vaultwarden | Android Autofill zuverlässiger, Import aus anderem Manager, Ordner teilen, Passwort-Stärke-Bericht | | Login | Self-Service Passwort-Reset, Einladungs-Link, Login-Verlauf, Längere Session | | Allgemein | Plattformweite Suche, Benachrichtigungs-Zentrale, Performance-Dashboard, Kalender-Integration, To-do-Liste, Android-Widget | | AI | KI-Textzusammenfassung, Chat-Bot, Ticket-Auto-Triage, KI schlägt Newsletter vor | **Block 2 — Schmerzen** Alle Bereiche direkt anzeigen (kein Filter). Bereich **DocuSeal weglassen** — wird intern selbst gebaut. Bereiche: Brett (2 Fragen inkl. Handy), Website / Admin (2), Chat (1), Vaultwarden (1), Nextcloud (1), Keycloak / Login (1) **Block 3 — Wunschzettel** Drei Freitext-Felder: „Sofort hätte ich…", „In 6 Monaten…", „Vermisse von anderen Apps…" **Block 4 — Große Vision (Major-Feature)** Ein Freitext-Feld mit Leitfrage: „Wenn du die Plattform komplett neu erfinden könntest — was wäre anders?" Darunter eine Checkbox: „Ich bin offen, dass dieses Feature in mehrere unabhängige Teile zerlegt und parallel entwickelt wird." Dieser Block identifiziert Major-Features die via `dev-flow-batch` zerlegt werden können. **[FOOTER]** „Markdown kopieren"-Button + Fallback-Textarea #### Technische Anforderungen - Kein Block-1-Filter, kein Ranking, kein Kontext-Block - Feature-Karten: `display:grid`, anklickbar, selected-State via CSS-Klasse - Würfel-Button: Fisher-Yates shuffle auf verbleibenden Pool-Einträgen - `buildMarkdown()` erzeugt das Ausgabeformat (siehe unten) - `navigator.clipboard` mit `document.execCommand('copy')` Fallback-Textarea ### Schritt 3 — Formular liefern Liefere `/tmp/gekko-interview-.html` per `SendUserFile`. Sage Patrick: „Schick das an gekko — ausfüllen → ‚Markdown kopieren' → dir zurückschicken → du gibst es mir hier." ### Schritt 4 — Rücklauf verarbeiten Wenn das ausgefüllte Markdown zurückkommt: #### Markdown-Ausgabeformat (was der Button erzeugt) ```markdown ## GekkoMode Interview: Eingereicht von: gekko ### Block 1 — Ausgewählte Feature-Vorschläge - [Brett] Touch-Drag & Drop auf Android verbessern - [Chat] Push-Notifications auf Android (PWA) - [Website] Bild-Upload direkt im HTML-Editor ### Block 2 — Schmerzen **Brett:** - Nervt: "Figuren lassen sich nicht gruppieren" - Handy-Problem: "Buttons zu klein, kein Touch-Drag" **Website / Admin:** - Umständlich: "Newsletter-Bilder muss ich extern hochladen" - Zeigen will: "Referenzen-Galerie fehlt" **Chat:** - Greift auf anderes Tool zurück weil: "Datei-Anhänge > 5 MB" **Vaultwarden:** - Bremst Nutzung: "Android Autofill klappt nicht immer" **Nextcloud:** - Manuell statt automatisch: "Ordner-Struktur händisch anlegen" **Keycloak / Login:** - Probleme ignoriert: "Token läuft nach 30 min ab, nervt" ### Block 3 — Wunschzettel - Sofort: "Brett auf Handy benutzbar machen" - In 6 Monaten: "Newsletter komplett in der Plattform" - Vermisse: "Notion-ähnliche Datenbanken" ### Block 4 — Große Vision - Vision: "Eine App für alles — Brett, Chat, Dateien, Verträge in einem Flow" - Parallel-Entwicklung: ✓ (Checkbox gesetzt) ``` #### Tickets anlegen Pro Schmerz-Nennung + Wunsch aus Block 3 (der noch kein Ticket hat): ```bash # 1. Duplikatcheck gegen $EXISTING — nur anlegen wenn kein ähnlicher Titel TICKET_RESULT=$(bash scripts/ticket.sh create \ --type feature \ --brand mentolder \ --title "" \ --priority \ --description "" \ --status planning) TICKET_EXT_ID=$(echo "$TICKET_RESULT" | cut -d'|' -f1) bash scripts/ticket.sh plan-meta set --id "$TICKET_EXT_ID" \ --value-prop "" \ --effort \ --areas # Originalzitat als Kommentar hinterlegen bash scripts/ticket.sh add-comment \ --id "$TICKET_EXT_ID" \ --author "feature-intake/gekkomode" \ --body "## GekkoMode-Rücklauf $(date +%F) **Originalzitat:** \"\" **Kontext:** Primärgerät: , Nutzung: **Ranking-Position:** <1-5 oder 'unranked'>" ``` #### Major-Feature aus Block 4 Wenn Block 4 "Große Vision" ausgefüllt ist und die "Parallel-Entwicklung"-Checkbox gesetzt: ```bash # Major-Feature-Ticket mit speziellem Kommentar TICKET_RESULT=$(bash scripts/ticket.sh create \ --type feature \ --brand mentolder \ --title "" \ --priority hoch \ --description "" \ --status planning) TICKET_EXT_ID=$(echo "$TICKET_RESULT" | cut -d'|' -f1) bash scripts/ticket.sh plan-meta set --id "$TICKET_EXT_ID" \ --value-prop "" \ --effort gross \ --areas bash scripts/ticket.sh add-comment \ --id "$TICKET_EXT_ID" \ --author "feature-intake/gekkomode" \ --body "## Major-Feature aus GekkoMode $(date +%F) **Vision:** \"\" **Parallel-Entwicklung:** ✓ (vom User bestätigt) **Nächster Schritt:** via dev-flow-batch in Sub-Features zerlegen" ``` Nach dem Anlegen aller Tickets: Schlage vor, das Major-Feature via `dev-flow-batch` zu zerlegen. #### Priorisierungslogik für `--priority` Kein Ranking-Block — Claude leitet Priorität aus Kombination folgender Signale ab: | Signal | Priorität | |--------|-----------| | Feature aus Block 1 ausgewählt **und** passendes Schmerz-Zitat in Block 2 | `hoch` | | Feature aus Block 1 ausgewählt, aber kein Schmerz-Zitat | `mittel` | | Schmerz-Zitat in Block 2 ohne passende Block-1-Auswahl | `mittel` | | Nur Wunschzettel-Nennung (Block 3), kein Schmerz | `niedrig` | | Feature betrifft Handy / Android-Usability | Upgrade um eine Stufe (bekannter Kontext) | #### Readiness-Flags für GekkoMode-Tickets GekkoMode-Tickets starten mit partieller Readiness — setze direkt was bekannt ist: ```bash bash scripts/ticket.sh plan-meta set --id "$TICKET_EXT_ID" \ --readiness offene_fragen_geklaert=true # spec_skizziert=false (muss Patrick noch verfeinern) # abhaengigkeiten_klar=false (unbekannt aus Interview) # aufwand_geschaetzt=false (muss geschätzt werden, es sei denn Zitat gibt Hinweis) ``` ### Schritt 5 — Abschluss-Report Nach dem Anlegen: ``` GekkoMode-Ergebnis: Neue Tickets: Duplikate übersprungen: (bereits als TXXXxxx vorhanden) Neu angelegt: • T000xxx [hoch] — "" • T000xxx [mittel] — "" 🏗️ Major-Feature erkannt: • T000xxx [hoch/gross] → via dev-flow-batch in Sub-Features zerlegen? Deadline-Flag: T000xxx erwartet bis (aus Block 5) → Planungsbüro öffnen? Oder direkt T000xxx zu dev-flow-plan? → Major-Feature via dev-flow-batch starten? ``` --- ## Modus A: Interaktiver Brainstorm **Sage:** "Ich führe einen Feature-Brainstorm durch." ### Schritt 1 — Kontext laden Lies die planning-Tickets und offene Backlog-Einträge (nicht alle open-Tickets): ```bash bash scripts/ticket.sh list --status planning --limit 20 2>/dev/null | head -40 || true bash scripts/ticket.sh list --status backlog --limit 10 2>/dev/null | head -20 || true ``` ### Schritt 1.5 — Major-Feature-Frage Bevor du in die Ideation gehst, frage: ``` Möchtest du auch Major-Features in Betracht ziehen? Das sind große Features die in 2-6 unabhängige Sub-Features zerlegt und parallel entwickelt werden können (z.B. "Komplette Plattform-Überholung", "Neues Abrechnungssystem", "Mobile-First Redesign"). Die Sub-Features werden via dev-flow-batch parallel geplant und können unabhängig voneinander deployed werden. → Ja, zeig mir Major-Feature-Ideen → Nein, nur einzelne Features ``` Wenn **Ja**: Präsentiere nach den normalen Clustern einen zusätzlichen Block: ``` 🏗️ Major-Feature-Kandidaten (zerlegbar in 2-6 Sub-Features): • Plattform-Modernisierung — Neues UI-Framework, API v2, Mobile-First → Sub-Features: UI-Redesign, API-Migration, Responsive-Layout, PWA-Shell • Billing-Revolution — Abo-Modelle, Usage-Based, Invoice-Automation → Sub-Features: Abo-Engine, Usage-Tracking, Invoice-Gen, Payment-Integration • Collaboration-Suite — Echtzeit-Edit, Comments, Presence, Versioning → Sub-Features: CRDT-Editor, Comment-System, Presence-Indicator, Version-History → Interessiert dich ein Major-Feature? Welches? ``` Nutze diese Major-Feature-Vorlagen als Inspiration, aber passe sie an den Projekt-Kontext an. Wenn der User ein eigenes Major-Feature beschreibt, zerlege es in Sub-Features. ### Schritt 2 — Ideation-Runden Präsentiere Feature-Kandidaten in Clustern. Pro Cluster eine kurze Frage: ``` Cluster: [Bereich, z.B. "Brett / Gruppenarbeit"] Kandidaten: • — • — → Welche davon sind interessant? Gibt es Varianten oder andere Ideen? ``` Nutze bekannte Projektbereiche als Cluster-Vorlage: - **Brett** (3D-Board, Gruppenarbeit, Figuren, Animation) - **Website / Content-Hub** (Newsletter, Verträge, CMS) - **Chat / Messaging** (Kanäle, Notifications, Media) - **Infra / DevEx** (CI, Factory, Monitoring, Deployment) - **Keycloak / Auth** (SSO, Rollen, Onboarding) - **Nextcloud / Files** (Kollaboration, Office, Backup) - **AI / Factory** (Autopilot, Code-Review, Dispatcher) ### Schritt 3 — Priorisieren Für jeden ausgewählten Kandidaten: ``` Feature: Typ: feature | fix | task Brand: mentolder | korczewski | beide Priorität: kritisch | hoch | mittel | niedrig Aufwand (geschätzt): klein (≤1d) | mittel (2-4d) | groß (≥1W) Kern-Nutzen: Abhängigkeiten: ``` ### Schritt 4 — Tickets erstellen (optional, auf Anfrage) Lege ein neues Ticket mit `status=planning` an (statt `triage`), damit es im Planungsbüro landet: ```bash bash scripts/ticket.sh create \ --type \ --brand \ --title "" \ --priority \ --description "" \ --status planning ``` Nach dem Anlegen die Büro-Metadaten setzen: ```bash bash scripts/ticket.sh plan-meta set --id \ --value-prop "" --effort --areas ``` Danach: direkt zu **`dev-flow-plan`** für den gewählten Kandidaten. --- ## Modus B: HTML-Formular (für Patrick oder gekko) **Sage:** "Ich generiere ein HTML-Formular zum Ausfüllen." (Bei Empfänger gekko: "… für gekko.") ### Schritt 1 — Template nutzen, NICHT neu bauen Es gibt ein fertiges, getestetes Template: **`.claude/skills/feature-intake/pm-form-template.html`** (selbst-enthalten, dark theme, Bereich-Chips → Feature-Listen → Prio/Aufwand-Dropdowns → robuster "Markdown kopieren"-Button mit Fallback-Textfeld). ```bash cp .claude/skills/feature-intake/pm-form-template.html /tmp/feature-intake-$(date +%F).html ``` Dann **nur den `FEATURES`-Block anpassen** (JS-Objekt im `