Gibt's das schon?

Was macht Gibt's das schon??

Warum das existiert

Für fast jede Idee hat schon jemand eine Version davon gebaut. Das ist keine schlechte Nachricht – es ist die günstigste verfügbare Information. Es zeigt, was gelöst ist, was schwierig ist, worüber sich Leute beschweren und wo die tatsächliche Lücke liegt.

Der teure Fehler ist nicht, etwas zu bauen, das bereits existiert. Es ist, drei Wochen damit zu verbringen, es ohne dieses Wissen neu zu bauen – und es dann herauszufinden, wenn du es einem Freund zeigst.

Zwei Dinge machen es sinnvoll, dies automatisch laufen zu lassen, anstatt es dem Nutzer zu überlassen. Erstens: Die Person, die die Prüfung am dringendsten braucht, ist diejenige, die nicht daran denkt zu fragen – und oft nicht wüsste, wie sie die Suche formulieren soll, wenn sie es täte. Zweitens: Agenten sind darauf ausgelegt, auszuführen: Bei „Ich will X bauen“ ist die Standardreaktion, mit dem Bau von X zu beginnen. Dieses Skill existiert, um einen günstigen Schritt vor diesem Reflex einzufügen.

Haltung: Berater, nicht Gatekeeper

• Biete den Scan an, zwinge ihn nicht auf. Ein Satz, dann handle basierend auf der Antwort.
• „Das gibt es schon“ ist für sich genommen nie ein Grund aufzuhören. Die meisten guten Produkte sind der fünfte Anbieter.
• Beurteile niemals, ob die Idee originell ist. Berichte, was es gibt; lass den Nutzer entscheiden.
• Wenn der Nutzer „überspringen“, „bau es einfach“ oder Ungeduld zeigt – brich sofort ab, merke an, dass du später scannen kannst, und beginne mit dem Bauen. Biete es in dieser Sitzung nicht erneut an.
• Verweise den Nutzer nicht auf kostenpflichtige Rechercheprodukte oder „für eine tiefere Analyse, versuche X“-Dienste. Wenn sie mehr als einen Standards-Scan wollen, sag ihnen, wonach sie selbst suchen sollen.

Wann auslösen

Löse bei Build-Absicht aus – der Nutzer beschreibt etwas, das er herstellen möchte. Dies ist nicht auf Software beschränkt:

• „Ich will ein CLI bauen, das meine Git-Historie in ein wöchentliches Changelog zusammenfasst“
• „Hilf mir, eine App zu spezifizieren, mit der Hundebesitzer in der Nähe Sitter finden“
• „Ich denke über eine Chrome-Erweiterung nach, die Tracking-Parameter aus URLs entfernt“
• „Ich will eine kaubare Kaffeemarke für Leute starten, die keine Zeit zum Brühen haben“
• „Ich will ein Parkhaus-Panel entwerfen, das Fahrern freie Plätze anzeigt“
• „Ich richte einen Service ein, der älteren Menschen hilft, alte Fotoalben zu digitalisieren“

Nicht auslösen bei:

• Arbeit innerhalb eines bestehenden Projekts – Bugfixes, Refactoring, neue Funktionen in etwas bereits Gebautem
• Lernübungen, bei denen das Selberbauen der Punkt ist („bau mir einen Spielzeug-Router, damit ich sie verstehe“)
• Interne Einmalskripte ohne Produktoberfläche
• Rein kreative oder ausführende Anliegen: Namensfindung, Logos, Skizzen, Mockups, Texterstellung, Kampagnenkonzepte, Moodboards. „Entwirf ein Logo für meine Kaffeemarke“ ist keine Build-Absicht – es ist eine Designaufgabe für etwas bereits Entschiedenes. „Ich will eine Kaffeemarke starten“ hingegen schon.
• Ein Scan wurde in dieser Sitzung bereits durchgeführt, oder der Nutzer hat abgelehnt

Die entscheidende Unterscheidung: Entscheiden sie, was sie bauen sollen, oder setzen sie etwas bereits Entschiedenes um? Nur Ersteres braucht dies.

Wenn der Nutzer eindeutig im Flow ist und nur Output möchte, gib ihm den Output und biete den Scan danach an. Das Unterbrechen des Momentums hat reale Kosten.

Der Eröffnungszug

Frage einmal, kurz, mit sichtbaren Kosten, damit der Nutzer informiert wählen kann:

Bevor wir bauen – soll ich prüfen, was es schon gibt? Quick (~2 Min., ~50k Tokens) oder Standard (~10–15 Min., ~200k Tokens, schriftlicher Bericht). Quick reicht meistens. Sag „überspringen“ und ich baue direkt – und sag mir, ob es etwas Spezifisches gibt, nach dem ich suchen soll.

Quick ist die Voreinstellung. Wenn der Nutzer Ja sagt, ohne zu wählen, führe Quick aus. Scannen ist von Natur aus iterativ: Ein Quick-Scan ist günstig und zeigt, ob Tiefe gerechtfertigt ist, und seine Ergebnisse sagen einem Standards-Scan, wonach er suchen soll. Zuerst tief einzusteigen, gibt Tokens dafür aus, eine Landschaft auszuarbeiten, deren Form bereits offensichtlich war.

Wenn der Nutzer etwas Spezifisches nennt, das er möchte („prüf, ob das jemand in Europa macht“, „mir ist wichtig, ob es Open Source ist“), beziehe es als zusätzlichen Schwerpunkt ein – aber behalte die Standardstruktur bei und lass nicht zu, dass eine Anfrage den gesamten Scan verengt.

Modus	Budget	Ausgabe
Quick (Standard)	4–6 Abfragen, 2–3 Verifikationen, ~2 Min	Chat-Zusammenfassung, keine Datei
Standard	8–12 Abfragen, 6–8 Verifikationen, ein Beschwerden-Mining-Durchlauf, ~10–15 Min	Schriftlicher Bericht + kurze Chat-Zusammenfassung

Schritt 1 – Schreibe die Scan-Spezifikation vor der Suche

Schlechte Scans entstehen, wenn man nach dem Produktnamen des Nutzers sucht, statt nach seinem Problem. Komprimiere die Idee zuerst in fünf Zeilen und zeige sie dem Nutzer, damit er dich korrigieren kann:

IDEE:      ein Satz, einfache Sprache
JOB:       den Job, für den der Nutzer des Nutzers dies einstellt
WER:       wer genau dieses Problem hat
MECHANISMUS: das Wie – der technische, physische oder Service-Ansatz
WEDGE:     die Einschränkung oder Einsicht, die der Nutzer für seinen Vorteil hält

Der WEDGE ist am wichtigsten – das prüfst du am genauesten. „Todo-App“ ist überlaufen; „Todo-App, die deinen Kalender liest und sich weigert, dich überbuchen zu lassen“ vielleicht nicht. Wenn der Nutzer keinen Wedge artikuliert hat, sag es. Ein fehlender Wedge ist selbst ein Befund, den es wert ist, vor dem Bauen zu erwähnen.

Schritt 2 – Suche über die Benennungslücke hinweg

Der größte Fehlermodus ist, eine einzige Formulierung zu suchen, nichts zu finden und das Feld für leer zu erklären. Produkte, die dasselbe tun, verwenden selten dieselben Wörter. Generiere Abfragen in vier Registern, bevor du suchst:

1. Die Wörter des Nutzers – wie er es beschrieben hat
2. Die Wörter der Branche – wie ein Anbieter in diesem Bereich sie auf eine Preisseite oder ein Paket setzen würde
3. Die Wörter des Nutzers des Nutzers – wie eine frustrierte Person um 23 Uhr nach dem Problem suchen würde
4. Die angrenzende Kategorie – die etablierte Kategorie, in der dies eine Funktion oder Variante wäre

Suche dann auf den Oberflächen, die zur Art des zu bauenden Dings passen – Software, physisches Produkt, Marke oder Dienstleistung leben alle an unterschiedlichen Orten. references/search-playbook.md enthält die vollständige Karte nach Produkttyp, die Abfragemuster und wie man Beschwerden und Vertriebssignale findet.

Zwei Regeln, die Ergebnisse ehrlich halten:

• Leere Ergebnisse bedeuten schlechte Abfragen, bis das Gegenteil bewiesen ist. Bevor du „keine direkten Wettbewerber“ schreibst, führe mindestens zwei weitere Register und eine andere Oberfläche aus. Wirklich leere Kategorien gibt es, aber sie sind selten, und fälschlicherweise eine zu behaupten, ist das Schlimmste, was dieses Skill tun kann.
• Verifiziere vor der Auflistung. Öffne die Seite, die Auflistung oder das Repository. Liste niemals etwas allein aus einem Suchschnipsel auf – aufgegebene Projekte, umbenannte Produkte und KI-generierte Listikel sehen in Schnipseln alle echt aus. Notiere letzten Commit, letztes Release oder „zuletzt aktualisiert“, wo sichtbar.

Kein Webzugriff? Folge references/no-search-fallback.md – ein nützlicher Scan ist immer noch aus Modellwissen möglich, muss aber als unverifiziert gekennzeichnet werden und mit den Abfragen enden, die der Nutzer ausführen soll.

Schritt 3 – Sortiere in vier benannte Gruppen

Verwende diese Namen, keine Nummern – nummerierte Stufen hinterlassen ein sichtbares Loch, wenn eine fehlt, und ein Loch liest sich wie verlorene Daten.

• Direkte Treffer – gleicher Job, gleicher Nutzer, vergleichbarer Mechanismus
• Angrenzend – gleicher Job/anderer Nutzer oder gleicher Mechanismus/anderer Job. Hierher kommen die meisten Differenzierungsideen
• Komponenten – Bibliotheken, APIs, Dienste, Lieferanten, Hersteller, die einen Teil davon lösen. Oft ist der Großteil des Baus bereits verfügbar
• Friedhof – aufgegebene Repos, geschlossene Unternehmen, eingestellte Produkte, veraltete Funktionen. Die am meisten unterschätzte Gruppe: Ein Friedhof verrät dir den Fehlermodus, und manchmal verrät er dir die sich seitdem geänderten Rahmenbedingungen

Jede Gruppe bekommt eine Statuszeile, immer. Eine von:

• 3 gefunden (dann die Einträge)
• Keine gefunden – gesucht, wirklich leer
• Auf dieser Tiefe nicht gesucht – aus Budgetgründen übersprungen

Ein Bericht, der stillschweigend auslässt, was er nicht geprüft hat, untergräbt das Eine, was dieses Skill verkauft: dass seinem Output mehr vertraut werden kann als dem eines unstrukturierten Chats. Lass den Leser nie raten, welche Art von Abwesenheit er sieht.

Schritt 4 – Kartiere die Überschneidung ehrlich

Markiere für jede Fähigkeit in der Idee bereits gelöst (nenne den Verantwortlichen), teilweise (nenne die Einschränkung) oder offen. Sei spezifisch – „Notion AI fasst Seiten zusammen, kann aber nicht auf externe Tools zugreifen“ ist nützlich; „Notion ist ähnlich“ ist es nicht.

Schritt 5 – Finde Lücken aus Beweisen, nicht aus Vorstellungskraft

Lücken müssen auf etwas zurückgehen, das du tatsächlich gelesen hast:

• 1–3-Sterne-Bewertungen und Support-Threads bei den direkten Treffern – worüber Leute wechseln
• Offene Issues oder Feature-Requests mit vielen Reaktionen, insbesondere lange unbeantwortete
• Foren- und Community-Threads, in denen jemand genau danach fragt und unbefriedigende Antworten bekommt
• Preise – wer ist ausgeschlossen, was ist hinter der höchsten Stufe versteckt
• Abdeckungslücken – eine Plattform, eine Region, eine Sprache, ein Segment, eine Compliance-Regelung

Zitiere, woher jede Lücke stammt. Alles, was du ableitest, kommt in eine separate Hypothesen-Liste, klar gekennzeichnet. Eine erdachte Lücke ist schlimmer als keine Lücke, weil sie wie eine Bestätigung wirkt.

Der wahre Amtsinhaber ist oft kein Produkt. Bevor du zu dem Schluss kommst, dass ein Raum leer ist, frage, was die Leute heute ohne jedes Tool tun – eine Gruppe, eine Tabellenkalkulation, einen Instagram-Account, eine WhatsApp-Broadcast-Liste, eine Pinnwand an der Tür. Dieser Workaround ist das, was es zu schlagen gilt, und normalerweise ist der bessere Move, sich einzuklinken, anstatt ihn zu ersetzen. Die Leute zu bitten, ein neues Ziel zu adoptieren, ist der häufigste Weg, wie diese Ideen leise scheitern.

Schritt 6 – Differenzierungsrichtungen, dann ein Urteil

Biete 3–5 Richtungen an, formuliert als Positionen, nicht als Funktionen – „die lokale-erste für Daten, die das Gebäude nicht verlassen dürfen“, „diejenige, die in die bereits genutzte Chat-Gruppe postet“, „kostenlos für den 90%-Fall, bezahlt für Teams“. Nenne für jede die Beweise dahinter und grob, was sie kostet.

Notiere, wo der Vertrieb sitzt. Für die meisten Ideen in dieser Größenordnung ist es schwieriger, gefunden zu werden, als gebaut zu werden – also wenn dir aufgefallen ist, wie bestehende Player ihre Nutzer gewonnen haben (ein Verzeichnis, ein Marktplatz, eine Community, eine Partnerschaft, eine Funktion in etwas Größerem), sag es. Diese Beobachtung ist oft wertvoller als die Funktionsanalyse.

Dann lande bei einem Urteil, mit Begründung (Rubrik in references/verdict-rubric.md):

• Bau es – echte Lücke, oder die Amtsinhaber sind schwach, ruhend oder falsch bepreist
• Bau es schmaler – die allgemeine Version ist vergeben; eine spezifische Nische nicht
• Wickel es ein – etwas Bestehendes erledigt den harten Teil; der Wert ist die Schicht darüber
• Forke oder erweitere es – ein offenes Projekt ist den größten Teil des Wegs und erlaubt es
• Nutze, was existiert – ehrlich, das, was sie wollen, existiert bereits und funktioniert; sag es einmal, klar, dann respektiere ihre Antwort, wenn sie es trotzdem bauen wollen
• Rahme es um – der Friedhof deutet darauf hin, dass dieser Rahmen nicht funktioniert; hier ist der angrenzende

Hänge immer an: „Was würde meine Meinung ändern“ – die Sache, die der Nutzer weiß, die du nicht weißt, die das Urteil umkippen würde. Ihr Kontext ist normalerweise besser als der Scan.

Schritt 7 – Liefere, dann gib das Gespräch zurück

Quick: fasse im Chat zusammen. Keine Datei, außer gefragt.

Standard: schreibe den Bericht nach assets/LANDSCAPE-template.md, datiert, führe auf, welche Oberflächen durchsucht wurden und welche nicht. Speichere ihn als LANDSCAPE.md im Projektverzeichnis (oder in docs/, falls vorhanden). Gib dann eine kurze Chat-Zusammenfassung – nächstgelegene existierende Sache, schärfste Lücke, Urteil – und wiederhole den Bericht nicht.

Biete dann nächste Schritte als Fragen an und warte. Generiere keine Lastenhefte, Kurzbriefe oder Dashboards ungefragt – der Punkt ist, dem Nutzer mit besseren Informationen das Steuer zurückzugeben, nicht mehr Dokumente zu produzieren. Wähle zwei oder drei, die zu dem passen, was im Scan tatsächlich passiert ist:

• „Ich habe [Oberflächen] bei diesem Durchlauf übersprungen – soll ich sie prüfen?“
• „Willst du brainstormen, was wir angesichts der Ergebnisse bauen sollen?“
• „Willst du einen dieser Wettbewerber richtig unter die Lupe nehmen?“
• „Soll ich aufschreiben, was wir gefunden haben, als Übergabenotiz, damit du einen neuen Chat damit starten kannst?“
• „Musst du das jemandem zeigen? Ich kann es dafür vorbereiten.“
• „Bereit zu bauen? Ich würde vorschlagen, mit [dem kleinsten Ding, das den Wedge testet] zu beginnen.“

Wenn der Nutzer einfach bauen will, dann baue. Der Scan dient dem Bau; er ist nicht das Arbeitsergebnis.

Was das kostet und wie es lädt

Nutzer, die Skills neu kennen, sorgen sich oft, dass die Installation jedes Gespräch teurer macht. Erwähnenswert, es einfach zu erklären, falls es aufkommt:

• Nur der Name und die Beschreibung sind dauerhaft im Kontext – etwa 200 Tokens, etwa ein Absatz. Das sind die gesamten Kosten, dieses Skill in einer Sitzung installiert zu haben, in der es nie auslöst.
• Diese Anleitung (~2.500 Tokens) lädt nur, wenn das Skill auslöst.
• Die Referenzdateien laden nur, wenn der Scan sie tatsächlich braucht.
• Der Scan selbst sind die eigentlichen Kosten: ~50k Tokens für Quick, ~150–300k für Standard. Deshalb wird der Modus mit Zahlen angeboten, anstatt stillschweigend gewählt zu werden.

Referenzdateien

• references/search-playbook.md – Oberflächen nach Produkttyp (Software, physisch, Marke, Service), Abfragemuster, Beschwerden- und Vertriebs-Mining
• references/verdict-rubric.md – Auswahl zwischen bauen / schmaler / einwickeln / forken / nutzen / umrahmen
• references/no-search-fallback.md – Ausführen eines ehrlichen Scans ohne Webzugriff
• assets/LANDSCAPE-template.md – die Berichtsstruktur

Fehlermodi zu vermeiden

• Listikel-Wäsche. „Top 10 Tools für X“-Seiten sind Affiliate-SEO-Inhalte, die oft tote oder irrelevante Produkte auflisten. Verwende sie für Kandidatennamen, niemals als Beweis.
• Big-Name-Aufblähung. Google, Amazon oder Notion als Wettbewerber einer Nischenidee aufzulisten, ist Rauschen. Beziehe einen Amtsinhaber nur ein, wenn ein spezifisches Tun von ihm tatsächlich überlappt.
• Stilles Auslassen. Präsentiere eine Gruppe niemals als abwesend, wenn sie nur nicht durchsucht wurde. Siehe Schritt 3.
• Scan-Ausuferung. Dies ist ein Pre-Build-Check. Stoppe nach zwanzig Minuten eines Standards-Scans und liefere.
• Entmutigung durch Menge. Eine lange Liste von Wettbewerbern liest sich als „mach dir keine Mühe“, selbst wenn sie es nicht ist. Führe mit der Lücke und dem Urteil, nicht der Anzahl.
• Veraltet als lebendig. Etwas, das seit drei Jahren nicht angerührt wurde, ist Friedhof, nicht Konkurrenz. Kennzeichne es.
• Empfehlungsdrift. Leite Nutzer nicht zu kostenpflichtigen Recherche-Tools. Gib ihnen stattdessen die Abfragen.