Nischenkarte: Lücken in einem konzeptuellen Raum

Was macht Nischenkarte: Lücken in einem konzeptuellen Raum?

Dieser Skill findet fundierte Lücken in einer Domäne. Er verwandelt eine vage Landschaft in eine Tabelle von echten Elementen × expliziten Dimensionen, sucht nach Kombinationen und Zonen, die niemand besetzt, übersetzt diese Lücken in konkrete Ideen und prüft, ob es sich nicht um Trugbilder (Mirage) handelt.

Leitprinzip. Zahlen ordnen das Urteil; sie ersetzen es nicht. Codes sind Analystenentscheidungen, also spiegelt der Raum die Rubrik ebenso wider wie den Markt. Deshalb muss jede vorgeschlagene Lücke eine Zuverlässigkeitsprüfung der Codes (Schritt 2b) und eine externe Validierung (Schritt 6) bestehen.

Werkzeuge in diesem Repo

Datei	Rolle
niche_core.py	Schritte 3-4: Kodierung, Cluster, PCA, UMAP, Triple-Lücken, Dichtelücken, Kandidaten-Nachbarn, Angebot vs. Nachfrage, Abbildungen
recode_check.py	Schritt 2b: Blindes Rekodierungs-Stichprobensheet und Übereinstimmung pro Dimension (Cohens Kappa)
md_to_pdf.py	Schritt 7: Markdown-Bericht in PDF
templates/report_template.md	Schritt 7: Berichtsgerüst
examples/	Synthetischer, fiktiver Datensatz zum Testen der Pipeline Ende-zu-Ende

---

0. Eingaben und Abgrenzungsfragen

Hole diese Antworten ein, bevor du beginnst. Fehlt eine, frage einmal in einem einzigen Block.

Eingabe	Frage	Warum es wichtig ist
Thema und Abgrenzung	Was zählt als Element? (z.B. "Tools, deren Kernwert X ist")	Verhindert gemischte Kategorien und Lückenartefakte.
N	Wie viele Elemente? (Standard 80-100; sinnvolles Minimum ≈ 50)	Bei N < 50 sind Dreifachzählungen Rauschen.
Einschlusskriterien	Mindestrezeption, Verfügbarkeit, Plattform, Sprache, Datum	Angewendet in Schritt 1 und dokumentiert.
Zielnutzer	Wer wird das Ergebnis bauen oder kaufen?	Grundlage des Fit-Scores und von target_filter.
Einschränkungen	Budget, Stunden, Fähigkeiten, Vertriebskanal, ausgeschlossene Themen	Werden zu target_filter und dem Fit-Kriterium.
Liefergegenstand	Sprache, Währung (und Wechselkursquelle), Format	Standard: PDF mit Ranking, Nischenkarten, Karten und der vollständigen Korpus-Tabelle mit Links.

1. Korpus: N echte, verifizierte Elemente

1. Breiter Samen. Sammle etwa 1,3 × N Kandidaten aus verschiedenen Quellen: Domain-Stores oder -Verzeichnisse, "Best-of"-Listen, "X-Alternative"-Suchen und aktuelle Long-Tail-Starts (Launch-Seiten, Nischenverzeichnisse, Open-Source-Registries). Wenn nur berühmte Produkte aufgenommen werden, erscheinen später falsche Lücken.
2. Existenzprüfung pro Element. Jedes Element benötigt eine URL, die auflöst: Store-Seite, Preisseite oder Repository. Notiere den HTTP-Status, die endgültige URL und das Datum. Wenn eine Seite Bots blockiert (403), überprüfe die Domain-Wurzel oder verwende einen Browser; eine Blockade bedeutet nicht, dass das Element nicht existiert.
3. Rezeptionssignal. Notiere ein oder mehrere öffentliche Signale (Store-Bewertung und Anzahl Rezensionen, Launch-Seiten-Stimmen, Repository-Sterne, Installationen, Auszeichnungen) und deklariere die Quelle und Abdeckung jedes Signals. Verwerfe ein Element nicht nur, weil es kein Signal hat. Wenn Rezeption ein Einschlusskriterium ist, wende es mit einer expliziten Schwelle an.
4. Dedupliziere Varianten, Rebrandings, Editionen und regionale SKUs. Behalte den kanonischen Namen und die Links.
5. Schließe nach Abgrenzung aus: Elemente, die die Einschlusskriterien nicht erfüllen, und liste sie im Bericht mit dem Grund auf.
6. Korpus-Verzerrungsprüfungen (schreibe die Antworten in den Bericht):
   • Anteil der Elemente aus dem Long Tail (z.B. in den letzten 24 Monaten gestartet oder unter dem medianen Rezeptionssignal). Wenn er unter ~20 % liegt, sammle mehr Long-Tail-Elemente.
   • Quellenkonzentration: Keine einzelne Quelle sollte mehr als ~40 % der Elemente beitragen.
   • Plattform- oder Sprachverzerrung relativ zur angegebenen Abgrenzung.
   • Signalabdeckung pro Quelle (manche Quellen überrepräsentieren bestimmte Nutzertypen, z.B. Entwicklertools auf Code-Hosting-Seiten).

Ausgabe: items.csv, eine Zeile pro Element mit Identifikations- und Link-Spalten, plus ein rohes JSON der Verifizierung.

2. Dimensionen, Skalen und Kodierungsrubrik

1. Leite 8-15 Dimensionen ab, indem du eine Stichprobe von etwa 20 Elementen liest. Teile sie in zwei Typen:
   • Konzeptdimensionen sagen, was das Element ist: Verb oder Aktion, Eingabe, Ausgabe, Auslöser, Domäne oder Thema, Benutzer, Ästhetik. Lücken werden mit diesen durchsucht (gap_dims).
   • Attributdimensionen sagen, wie es gebaut oder verkauft wird: Komplexität, Breite, Selbstbedienung, Preismodell, Preissegment. Sie filtern und bewerten. Wenn sie in der Lückensuche verwendet werden, erzeugen sie "Meta"-Lücken wie "ereignisgesteuert + kein KI + hohe Komplexität".
2. Skalen. Nominelle Kategorien mit 3-14 sich gegenseitig ausschließenden Werten, jeder mit einem lesbaren Label, oder kurze Ordinalwerte (0-1, 0-2, 1-3) mit beschriebenen Ankern.
3. Schriftliche Rubrik: eine Zeile pro Wert mit einer Definition und einem Beispielelement, plus die folgenden Entscheidungsregeln. Sie kommt in den Berichtsanhang und ist das einzige Material, das der zweite Kodierer in Schritt 2b erhält.
   • Kodiere die logische Struktur, nicht die Darstellung. Bei räumlichen oder strukturellen Dimensionen kodiere, wie der Benutzer tatsächlich mit dem Ding interagiert oder darüber denkt, nicht wie es aussieht (z.B. ein 3D-rendertes Produkt, das auf einer flachen Ebene verwendet wird, ist nicht "3D").
   • Vorrangordnung für überlappende Werte. Wenn eine nominelle Skala etwas Wahrnehmungs- oder Stilistisches beschreibt (Aussehen, Ton, Stil), überlappen sich die Werte. Gib eine explizite Entscheidungsordnung an ("wenn A zutrifft, kodiere A; sonst wenn B...") oder führe Werte zusammen, die Kodierer nicht unterscheiden können.
   • Messbare Anker für Ordinalwerte. Anker wie Dauer, Größe oder Aufwand müssen angeben, wie sie gemessen werden und aus welcher Quelle (z.B. "typische Sitzung, wie in der Store-Beschreibung angegeben oder in einem Demovideo beobachtet; für levelbasierte Elemente ein Level"). Wenn es nicht beobachtet werden kann, kodiere den modalen Fall und markiere es.
   • Kodiere den primären Modus. Wenn ein Element mehrdeutig ist, kodiere seinen Hauptmodus und notiere den Zweifel in einer notes-Spalte.
4. Gewichte. Standard 1,0. Erhöhe Kernkonzeptdimensionen (z.B. Verb auf 1,2), senke periphere (z.B. Preismodell auf 0,4). Begründe jedes Gewicht.
5. Strukturprüfungen:
   • Keine Kategorie mit weniger als 2 Elementen; führe sie zusammen oder verwerfe sie (niche_core.py warnt).
   • Kreuztabellen zur Erkennung redundanter Dimensionen (Korrelation ≈ 1): verwerfe oder führe eine von ihnen zusammen.
6. Erkenne die Grenzen an: Codes sind Urteile.

Ausgabe: das CSV der Elemente × Dimensionen und config.json mit Skalen, Gewichten und Regeln.

2b. Blindes Rekodierungs-Check (obligatorisch)

Zweck: Messen, ob die Rubrik, nicht das Gedächtnis des Kodierers, die Codes bestimmt. Lücken, die auf unzuverlässigen Dimensionen basieren, sind Rubrikartefakte.

1. Stichprobe. Ziehe zufällig 10 % des Korpus, mindestens 10 Elemente, mit einem festen Seed: python recode_check.py sample --items items.csv --config config.json --out recode_sheet.csv --keep link Das Blatt enthält nur die Element-ID und den Link, mit leeren Dimensionsspalten.
2. Zweiter Kodierer, blind. Eine andere Person oder eine separate Agentensitzung, die nie die ersten Codes gesehen hat (kein Zugriff auf items.csv, die Cluster oder den Bericht), kodiert das Blatt unter ausschließlicher Verwendung der schriftlichen Rubrik und der öffentlichen Seiten des Elements. Wenn derselbe Agent es tun muss, starte einen frischen Kontext und gib ihm nur das Blatt und die Rubrik. Sperre das Ergebnis vor dem Vergleich (z.B. speichere eine Prüfsumme).
3. Übereinstimmung pro Dimension: python recode_check.py agree --items items.csv --config config.json --recode recode_sheet.csv --out agreement.csv
   • Kategoriale Dimensionen: Cohens Kappa (κ).
   • Ordinale Dimensionen: linear gewichtetes Cohens Kappa (κw), das Teilpunkte für knappe Fehlschläge gewährt.
   • Die rohe prozentuale Übereinstimmung wird daneben gemeldet, plus eine Liste der Nichtübereinstimmungen pro Element.
4. Schwelle. Eine Dimension besteht mit κ (oder κw) ≥ 0,60 und roher Übereinstimmung ≥ 80 %. Bei n ≈ 10 ist Kappa verrauscht: Verwende es zur Triage und lies jede Nichtübereinstimmung.
5. Unterhalb der Schwelle in dieser Reihenfolge:
   1. Lies die Nichtübereinstimmungen und klassifiziere sie: Rubrik-Mehrdeutigkeit (überlappende Werte, nicht messbarer Anker), Verwechslung von Darstellung vs. Struktur oder Kodiererfehler.
   2. Korrigiere die Rubrik mit einer der Entscheidungsregeln aus Schritt 2.3 (Vorrangordnung, messbarer Anker, Zusammenführen nicht unterscheidbarer Werte).
   3. Kodiere diese Dimension für den gesamten Korpus mit der überarbeiteten Rubrik neu, dann führe die Prüfung mit einer frischen 10 %-Stichprobe (neuer Seed) für diese Dimension erneut durch.
   4. Wenn sie immer noch nicht besteht: senke ihr Gewicht (≤ 0,6), entferne sie aus gap_dims oder verwerfe sie. Melde niemals eine Lücke, deren erklärendes Triple auf einer Dimension beruht, die zweimal durchgefallen ist.
6. Bericht die Tabelle (Dimension, n, % Übereinstimmung, κ/κw, Status), die Rubrikänderungen und die Identität des zweiten Kodierers (Mensch, separater Agent).

Typisches Ergebnis: Dimensionen zur Funktion (Aktion, Ziel, Eingabe/Ausgabe, Auslöser) stimmen gut überein; wahrnehmungsbasierte oder geschätzte Dimensionen (Stil, räumliche Struktur, Dauer) sind die üblichen Fehlschläge, weshalb die Entscheidungsregeln in Schritt 2.3 existieren.

3. Raum: Kodierung, Cluster, Gradienten und Visualisierung

Wird von niche_core.py erledigt. Goldene Regel: Cluster und Lücken werden im ursprünglich kodierten Raum berechnet; UMAP dient nur der Zeichnung.

• Kodierung. One-Hot × Gewicht/√2 für kategoriale Dimensionen und (x − min)/(max − min) für Ordinalwerte, sodass das Wechseln einer Kategorie genauso viel kostet wie eine End-to-End-Ordinabewegung.
• Cluster. Agglomeratives Ward mit k, ausgewählt durch Silhouette innerhalb von k_range. Ein größeres k wird nur akzeptiert, wenn es die Silhouette um mehr als 0,005 verbessert.
  • k-Bereichsprüfung: Wenn das gewählte k auf beiden Enden des Bereichs liegt, erweitere den Bereich und führe erneut aus; das Skript warnt. Wenn es auf dem Rand bleibt, wähle k nach Interpretierbarkeit und gib dies an.
  • Silhouette zwischen 0,15 und 0,30 ist bei kategorialen Daten normal; verkaufe es nicht als "scharfe Cluster".
  • Cluster mit < 3 Elementen und Elemente mit identischen Vektoren werden markiert; letzteres deutet auf eine zu grobe Rubrik hin, um Elemente zu unterscheiden.
  • Benenne jeden Cluster von Hand aus cluster_profiles.md und speichere die Namen in cluster_names.
• Gradienten. PCA-Ladungen (PC1-PC3, pca_loadings.csv) werden als Achsen "von A nach B" gelesen.
• Visualisierung. UMAP (n_neighbors 10-15, min_dist 0,25, fester Seed) mit einem KDE-Dichtehintergrund. Grenzen:
  • globale Abstände und Inselsgrößen bedeuten nichts;
  • transform zieht neue Punkte tendenziell auf die nächste Insel, daher wird die Neuheit eines Kandidaten aus dist_min im ursprünglichen Raum abgelesen, niemals aus dem Plot.
• Paarweise Heatmaps der Dimensionen zeigen leere Zellen auf einen Blick.

4. Lücken

4a. Kombinatorische Lücken (Triple). Für jedes Triple von Werten der Lücken(Konzept)-Dimensionen vergleiche beobachtete mit erwarteten unter Unabhängigkeit: e = N · p(a) · p(b) · p(c), z = (e − o)/√e. Ein Triple wird behalten, wenn:

• o ≤ max_observed (Standard 1);
• e ≥ min_expected (Standard 1,2);
• jedes Paar im Triple kommt in mindestens min_pair_support Elementen vor (Standard 2): die Teilstücke existieren separat;
• es berührt mindestens eine Ankerdimension (anchor_dims, z.B. Domäne oder Verb).

Meta-Lücken-Filter: Halte Attributdimensionen aus gap_dims heraus und setze anchor_dims auf die Dimensionen, die den Inhalt des Produkts beschreiben. Triple, die nur aus Attributen bestehen, sind keine Nischen.

4b. Dichtelücken. 50.000-400.000 zufällige synthetische Vektoren werden generiert und nur behalten, wenn:

1. jedes Paar von Werten in mindestens einem echten Element existiert (Rekombination bekannter Teile);
2. keine Kohärenzregel sie verbietet (rules: Kombinationen, die in der Domäne absurd sind);
3. sie dem Zielnutzerprofil entsprechen (target_filter, z.B. Komplexität ≤ 1 und Selbstbedienung = 1). Dies ist der Benutzer-Fit-Filter: Ohne ihn driften Dichtelücken zu Produkten, die der Benutzer nicht bauen oder verkaufen kann.

Überlebende werden nach Entfernung zum nächsten echten Element sortiert und auf den Hauptkonzeptdimensionen dedupliziert (density_dedupe). Vergleiche mit dem medianen Nächsten-Nachbar-Abstand zwischen verschiedenen echten Elementen (median_nn_distance).

4c. Angebot vs. Nachfrage (optional). Pro Cluster: Anzahl der Elemente (Angebot) vs. der Median eines Nachfragesignals (Rezensionen, Installationen, Suchvolumen, Sterne), immer mit seiner Abdeckung (supply_demand_clusters.csv). Ein kleiner Cluster mit hoher Nachfrage ist ein Lückenhinweis (Inferenz).

4d. Vorläufiger Score. Neuheit (1-5, aus relativem Abstand und dem Triple, das die Lücke erklärt), Machbarkeit (1-5, MVP-Aufwand mit den Ressourcen des Benutzers) und Fit (1-5, Präferenzen und Einschränkungen aus Schritt 0). Für jeden Kandidaten überprüfe seine 3 nächsten Nachbarn, indem du ihn zu candidates hinzufügst und erneut ausführst.

5. Semantische Übersetzung: vom Vektor zur Idee

Wähle 8-12 Kandidaten aus den Triple mit dem höchsten z und den am weitesten entfernten Dichtelücken; führe Signale zusammen und entferne Duplikate. Jeder Kandidat erhält:

• Arbeitsname und ein 2-3 Sätze konkretes Pitch: was der Benutzer tut, was das Produkt liefert.
• Vektor auf allen Dimensionen; muss die Regeln erfüllen.
• Nächste Elemente mit Abstand (× Median).
• Warum es im Korpus leer aussieht: welches Triple oder welche Zone es erklärt, und ob eine seiner Dimensionen in Schritt 2b durchgefallen ist.
• Risiken: technische, marktseitige und Fit-Risiken.

6. Externe Validierung und Mirage-Test

1. Gezielte Suche pro Kandidat, außerhalb des Korpus:

   • "[Konzept] + App/Tool + Preise";
   • "[Konzept] Alternative";
   • Domain-Stores mit 2-3 Synonymen;
   • Open-Source-Repositories.

   Notiere 3-5 Wettbewerber mit Link und Preis. Gehe davon aus, dass fast immer welche auftauchen: ein Korpus von N ≈ 100 deckt den Long Tail nicht ab. Passe die Neuheit entsprechend an.

2. Mirage-Test (angepasst von White-Space-Analysis, siehe Referenzen). Der Kandidat steht vor vier Fragen:

   • Größe: Gibt es genug Leute mit diesem Job-to-be-Done?
   • Zahlungs- oder Wechselbereitschaft: vom stärksten zum schwächsten Beleg: Sie zahlen bereits für eine Teillösung, halten eine teure Problemumgehung aufrecht oder haben versucht, sie selbst zu bauen.
   • Inkumbentenfrage: Warum hat sie niemand gefüllt? Akzeptable Antworten: Geschäftsmodell- oder Kanalkonflikt, eine aktuelle externe Veränderung, ein wachsendes Segment. Alarmierende Antwort: "Ich kann keinen Grund finden".
   • Gewinnbarkeit: Kann der Zielbenutzer die Barriere überwinden, die die Lücke leer hält?

   Urteil: bestanden (Faktor 1,0), zweifelhaft (0,7) oder nicht bestanden (0,4).

3. Endgültiger Score = Neuheit × Machbarkeit × Fit × Mirage-Faktor (Bereich 0,4-125).

4. Kandidaten, die in der Validierung durchfallen, bleiben im Bericht als "falsche Lücken". Sie legen Korpusverzerrungen offen und

…[für die Übersetzung abgeschnitten]