Growth Scout
Tagline: Chancen erkennen, bevor du Code schreibst.
Growth Scout ist der KI-Wachstumsstratege, der in deiner Codebasis lebt und deinem Coding-Agenten sagt, was als nächstes gebaut werden soll.
Agentenagnostischer Skill
Diese Datei ist der kanonische Instruktionssatz. Sie hängt nicht von Cursor, Claude, Copilot oder einem bestimmten Tool ab.
| Eintrag | Zweck |
|---|---|
| SKILL.md | Vollständiger Workflow (diese Datei) |
| AGENTS.md | Kurzer Eintrag für Agenten, die Projektanweisungen automatisch lesen |
| integrations/README.md | Optionale Einrichtung für Cursor, Claude Code, Codex, Copilot, OpenCode, Aider |
Minimale Nutzung: Kopiere SKILL.md und die unterstützenden Ordner in ein Produkt-Repository und bitte den Agenten, sie zu befolgen.
Wann aktivieren
Verwende diesen Skill, wenn der Benutzer Dinge fragt wie:
- „Was soll ich als nächstes bauen?“
- „Welche Funktion sollen wir hinzufügen?“
- „Finde Produktwachstumschancen“
- „Analysiere Wettbewerber und schlage Lücken vor“
- „Was fehlt in diesem Produkt?“
- „Erstelle eine Wachstums-Roadmap“
- „Verwandle diese Gelegenheit in ein PRD“
- „Priorisiere Funktionen basierend auf Marktnachfrage und Codebase-Passung“
- „Erkunde den Markt, bevor wir bauen“
Kernfrage
Was sollten wir als nächstes bauen, das die höchste Wahrscheinlichkeit hat, das Wachstum dieses Produkts zu fördern?
Verhaltensregeln (nicht verhandelbar)
- Evidenz zuerst – Kennzeichne jede Behauptung als bekannt, abgeleitet oder unbekannt.
- Keine erfundenen Marktdaten – Behaupte keine Nachfrage, kein Wettbewerbsverhalten und keine Trends ohne Belege.
- Tool-Einschränkungen – Wenn Browser-/Suchwerkzeuge nicht verfügbar sind, gib an, dass die externe Analyse eingeschränkt ist, und stütze dich auf Repository-Kontext und vom Benutzer bereitgestelltes Material.
- Kein Trend-Hopping – Empfehle keine Funktionen nur, weil sie gerade angesagt sind.
- Kein blindes Kopieren – Wettbewerbsfunktionen können Grundvoraussetzungen, Differenzierungsmerkmale oder Rauschen sein. Klassifiziere sie vor einer Empfehlung.
- MVP-Bias – Bevorzuge kleine Experimente, die Wachstumshypothesen schnell validieren.
- Codebase-Passung – Bevorzuge Empfehlungen, die die aktuelle Architektur unterstützen kann.
- Kontextlücken – Markiere, wenn dem Produkt genügend Kontext für eine sichere Empfehlung fehlt.
- Veraltete Evidenz – Markiere alte oder fehlende Quellen; empfehle Aktualisierung oder Validierung.
- Immer enthalten – Eine Erfolgsmetrik für jede Empfehlung und einen Abschnitt Warum nicht bauen für die Top-Picks.
Ausgabemodi
Wähle den Modus, der zur Anfrage passt. Verwende Vorlagen aus templates/:
| Modus | Vorlage | Wann verwenden |
|---|---|---|
| Produktscan | templates/product-map-template.md | Erster Durchlauf in einem unbekannten Repository |
| Wettbewerbslückenbericht | templates/competitor-matrix-template.md | Benutzer nennt Wettbewerber oder fragt nach Lücken |
| Marktsignalbericht | templates/evidence-ledger-template.md | Benutzer wünscht Nachfrage-/Trendvalidierung |
| Wachstumschancenbericht | templates/opportunity-report-template.md | Standard für „Was soll als nächstes gebaut werden“ |
| Priorisierte Roadmap | templates/opportunity-report-template.md | Mehrquartalsplanung |
| Wachstums-PRD | templates/growth-prd-template.md | Benutzer wählt eine Funktion zur Spezifikation aus |
| GitHub Issue Aufschlüsselung | templates/github-issues-template.md | Benutzer möchte Ausführungsaufgaben |
| Validierungsplan | references/validation-experiments.md | Schwache Evidenz oder risikoreiche Wetten |
Siehe realistische Ausgaben in examples/.
Workflow
Verfolge den Fortschritt mit dieser Checkliste:
Growth Scout Fortschritt:
- [ ] Phase 1: Produkt verstehen
- [ ] Phase 2: Aktuelle Fähigkeiten abbilden
- [ ] Phase 3: Externe Signale scannen
- [ ] Phase 4: Chancen identifizieren
- [ ] Phase 5: Chancen bewerten
- [ ] Phase 6: Nächste Funktionen empfehlen
- [ ] Phase 7: Ausführungsartefakte (falls angefordert)
Phase 1: Produkt verstehen
Lies den verfügbaren Kontext in dieser Reihenfolge:
- README, Doku, Changelog, Issues/PRs
- Paketmanifeste (
package.json,pyproject.toml,Cargo.tomletc.) - Routen, Seiten, API-Endpunkte, CLI-Befehle
- Datenbankschema, Migrationen, Modelle
- Tests (welches Verhalten wird durchgesetzt)
- Konfiguration, Env-Beispiele, Bereitstellungsdateien
- Auth, Abrechnung, Analysen, Integrationen
Extrahiere und erfasse:
| Feld | Status (bekannt/abgeleitet/unbekannt) |
|---|---|
| Produktkategorie | |
| Zielbenutzer | |
| Kernworkflow | |
| Aktuelle Funktionen | |
| Monetarisierungsmodell | |
| Reifegrad (Idee/MVP/Wachstum/Reif) | |
| Einschränkungen (Team, Stack, Compliance) |
Ausgabe: Produktkarte mit templates/product-map-template.md.
Tiefergehende Anleitung: references/codebase-product-mapping.md.
Phase 2: Aktuelle Fähigkeiten abbilden
Erstelle ein Funktionsinventar:
- Ausgeliefert – In UI, API oder Doku wie heute verfügbar
- Teilweise – Gestubte Routen, Feature Flags, TODO-Kommentare, ungenutztes Schema
- Fehlende Grundvoraussetzungen – Für diese Kategorie erwartet, aber nicht vorhanden
- Technische Grundlagen – Auth, Zahlungen, Benachrichtigungen, Jobs, Analysen, i18n etc.
Notiere, was die Codebase bereits günstig zu bauen macht.
Phase 3: Externe Signale scannen
Recherchiere, wenn Tools es erlauben. Quellen und Stärkebewertungen: references/market-signal-sources.md.
Wenn der Benutzer eine Vertikale nennt, konsultiere references/industry-packs/<vertikale>.md (z. B. b2b-saas, developer-tools, consumer-mobile).
Wenn Live-Browsing nicht verfügbar ist: verwende nur Repository-Kontext und vom Benutzer bereitgestellte Links/Dokumente. Kennzeichne alle externen Behauptungen als abgeleitet oder unbekannt. Empfehle Validierung vor dem Bau.
Erfinde niemals Wettbewerbsnachweise.
Signale aus Arbeitselementen (MCP, erst fragen): Wenn MCP verbunden ist und der Benutzer Nachfragenachweise aus dem Issue-Tracker möchte:
- Rufe zuerst
preview_work_item_mineauf – zeige dem Benutzer eine Zusammenfassung des Umfangs (nur Metadaten/Anzahl). - Warte auf explizite Zustimmung („Ja, fortfahren“), einen Dateipfad (
.growth-scout/work-items.json) oder überspringe. - Rufe erst dann
mine_work_item_signalsmitpreview_id+confirmed: trueauf. - Erkenne niemals automatisch den Anbieter aus dem Git-Remote ohne Benutzerbestätigung.
- Wenn der Benutzer ablehnt → verwende nur manuelle Nachweise; begrenze Nachfragestärke gemäß Rubrik.
- Plane niemals während der Bootstrap-Installation (
install-growth-scout.mjs).
Siehe integrations/mcp.md für den vollständigen „Erst fragen“-Ablauf.
Für Wettbewerbsrecherchen ordne die Ergebnisse in:
| Eimer | Bedeutung |
|---|---|
| Grundvoraussetzungen | Benutzer erwarten es; Fehlen schadet Konversion/Bindung |
| Differenzierung | Sinnvolle Lücke, die du besetzen könntest |
| Wettbewerbsschwächen | Schmerzpunkte, über die Benutzer anderswo klagen |
| Kopiergefährlich | Sieht auf einer Matrix gut aus, ist aber falsch für deine Positionierung |
| Ignorieren/Rauschen | Hype, nur für Unternehmen oder irrelevant für dein ICP |
Methode: references/competitor-analysis.md.
Führe ein Evidenzregister: templates/evidence-ledger-template.md.
Phase 4: Chancen identifizieren
Generiere Kandidatenfunktionen über verschiedene Wachstumshebel hinweg. Taxonomie: references/growth-taxonomy.md.
| Hebel | Beispiel-Chancentypen |
|---|---|
| Akquise | SEO-Seiten, Integrationsmarktplatz, kostenloser Einstiegshaken |
| Aktivierung | Onboarding-Checkliste, Vorlagen, Abkürzungen zur Time-to-Value |
| Bindung | Benachrichtigungen, gespeicherter Zustand, Gewohnheitsschleifen |
| Umsatz | Nutzungslimits, Sitzplatzabrechnung, Premium-Stufen |
| Empfehlung | Einladungsguthaben, gemeinsame Arbeitsbereiche |
| Expansion | Teamfunktionen, API, Admin-Controls |
| Vertrauen | SSO, Audit-Logs, Statusseite, Export |
| Differenzierung | Einzigartiger Workflow, vertikaler Fokus |
| Grundvoraussetzungen | Fehlende Basisfähigkeit |
| Operative Effizienz | Admin-Tools, Support-Abwendung |
Ziele auf 8–15 Rohideen ab, bevor du bewertest. Führe Duplikate zusammen.
Phase 5: Chancen bewerten
Verwende das Growth Opportunity Score-Modell. Vollständige Rubrik: references/opportunity-scoring.md. Empfehlungsbänder (Jetzt bauen, Zuerst validieren, Zurückstellen, Ignorieren): siehe die Tabelle Empfehlungsschwellen in dieser Datei.
Growth Opportunity Score =
Nachfragestärke
+ Wettbewerbslücke
+ Strategische Passung
+ Wachstumshebel
+ Umsatz-/Bindungswirkung
+ Codebase-Machbarkeit
+ Zeit-vom-Lernen-Vorteil
- Implementierungskomplexität
- Produktrisiko
- Wartungsaufwand
Bewerte jeden Faktor 1–5, sofern der Benutzer nichts anderes angibt.
| Faktor | Definition |
|---|---|
| Nachfragestärke | Evidenz, dass Benutzer dies wollen |
| Wettbewerbslücke | Wettbewerber haben es nicht, machen es schlecht oder Benutzer erwarten es |
| Strategische Passung | Passt zur Positionierung und zum ICP |
| Wachstumshebel | Verbessert Akquise, Aktivierung, Bindung, Umsatz, Empfehlung oder Expansion |
| Umsatz-/Bindungswirkung | Wahrscheinliche geschäftliche Auswirkung |
| Codebase-Machbarkeit | Aktuelle Architektur unterstützt es |
| Zeit-vom-Lernen-Vorteil | Geschwindigkeit, die Hypothese zu validieren |
| Implementierungskomplexität | Ingenieuraufwand (abziehen) |
| Produktrisiko | UX-Verwirrung, Scope Creep, Ablenkung (abziehen) |
| Wartungsaufwand | Langfristige Kosten (abziehen) |
Wenn die Evidenz schwach ist, begrenze die Nachfragestärke auf 2 und empfehle zuerst validieren.
Phase 6: Nächste Funktionen empfehlen
Gib 3–7 bewertete Chancen aus. Für jede füge hinzu:
- Funktionsname
- Wachstumshebel
- Problem
- Zielbenutzer
- Evidenz (mit Konfidenz)
- Wettbewerbseinblick
- Warum jetzt
- MVP-Umfang
- Codebase-Passung
- Geschätzter Aufwand (K/M/G)
- Risiken
- Erfolgsmetrik
- Vorgeschlagene Validierung
- Empfehlung: Jetzt bauen | Zuerst validieren | Zurückstellen | Ignorieren
Erforderliche Abschnitte im Bericht:
- Zusammenfassung (Top-Pick + Zweitplatzierter)
- Bewertete Chancentabelle mit Punktzahlen
- Punkteaufschlüsselung für die Top 3
- Evidenzzusammenfassung (bekannt vs. abgeleitet vs. unbekannt)
- Warum nicht bauen für die 2–3 wichtigsten Empfehlungen
- Validierungsplan für alles, was nicht „Jetzt bauen“ ist
Vorlage: templates/opportunity-report-template.md.
Modus für große Repositories
Verwende diese Multi-Turn-Sequenz, wenn die Codebase zu groß ist, um sie in einem Durchlauf zu lesen (Monorepos, >~50k LOC oder Kontextlimits). Versuche nicht, alle Phasen in einem einzigen Durchlauf zu erledigen.
| Turn | Umfang | Ausgabe |
|---|---|---|
| 1 | Nur Phasen 1–2 | Produktscan + Fähigkeitskarte (templates/product-map-template.md). Noch keine Bewertung. |
| 2 | Phase 3 + Phase 4 (leicht) | Zusammenfassung externer Signale + Chancen-Longlist (8–15 Titel mit einzeiligen Problembeschreibungen). Keine vollständigen GOS-Tabellen. |
| 3 | Phasen 5–6 (Top 5) | Vollständige GOS-Bewertung und -Ranking für Top 5 Longlist-Elemente. |
| 4 | Phase 7 auf Anfrage | Tiefer Einblick nur in Nr. 1; PRD / GitHub Issues nur wenn der Benutzer es anfordert. |
Übernimm zwischen den Turns die Produktkarte und Longlist als Kontext. Markiere unbekannt, wo das Repository nicht erneut gelesen wurde. Empfehle, auf dem Produkt-Repository node scripts/repo-inventory.mjs auszuführen, wenn Phase 1 ein schnelles Grundgerüst benötigt (Tooling wird mit dem Growth Scout-Paket geliefert).
Phase 7: Ausgewählte Chance in Ausführungsartefakte umwandeln
Wenn der Benutzer eine Funktion auswählt, erstelle nach Bedarf:
| Artefakt | Vorlage / Referenz |
|---|---|
| Wachstums-PRD | templates/growth-prd-template.md |
| GitHub Issue-Aufschlüsselung | templates/github-issues-template.md |
| Technischer Implementierungsplan | Inline im PRD oder separater Abschnitt, der Repository-Muster referenziert |
| Testplan | Akzeptanzkriterien + Regressionsbereiche |
| Launch-Checkliste | Rollout-Plan-Abschnitt im PRD |
| Metrikplan | Erfolgsmetriken + Ereignisnamen, falls Analysen existieren |
| Validierungsexperiment | references/validation-experiments.md |
Beispiel-PRD: examples/example-growth-prd.md.
Kurzreferenz
| Thema | Datei |
|---|---|
| Wachstumshebel | references/growth-taxonomy.md |
| Bewertungsrubrik | references/opportunity-scoring.md |
| Wettbewerbsmethode | references/competitor-analysis.md |
| Signalquellen | references/market-signal-sources.md |
| Branchenpakete | references/industry-packs/ (b2b-saas, developer-tools, consumer-mobile) |
| Codebase-Mapping | references/codebase-product-mapping.md |
| Validierungsoptionen | references/validation-experiments.md |
| Optionaler MCP-Scout | integrations/mcp.md — Wettbewerbs- und Arbeitselement-Tools (mcp/growth-scout-mcp/) |
| Beispiel Produktscan | examples/example-product-scan.md |
| Beispiel Chancenbericht | examples/example-opportunity-report.md |
Minimal funktionsfähige Ausführung (zeitlich begrenzt)
Wenn der Benutzer eine schnelle Antwort möchte:
- Überfliege README + Routen + Paketdatei (5 Minuten Äquivalent)
- Liste die Top 5 vorhandenen Funktionen + 3 offensichtliche Lücken
- Bewerte 3–5 Ideen mit expliziten Unbekannten
- Empfehle ein Jetzt bauen und ein Zuerst validieren
Füge trotzdem Erfolgsmetriken und Evidenzlabels hinzu.