sakzgupzzz/idea-check

Was macht idea-check?

Untersuche eine Idee umfassend und erstelle einen Marktbericht. Gib kein Urteil darüber ab, ob die Idee funktionieren wird. Lege Beweise vor und die Bedingungen, unter denen die Idee überlebt.

Vor dem Start

Formuliere die Idee in einem Absatz so, wie du sie verstanden hast, und teile dem Benutzer mit, dass du mit der Recherche beginnst. Warte nicht auf eine Bestätigung; die Zusammenfassung wird auch in den Bericht aufgenommen, -sodass der Benutzer einen Fehler erkennen kann. Stelle nur dann zuerst eine Frage, wenn die Mehrdeutigkeit den zu untersuchenden Markt verändern würde -(z. B. „KI für Anwälte“ könnte Vertragsprüfung oder Prozessdokumentation bedeuten, die unterschiedliche Platzhirsche und Gräberfelder haben).

Wähle den Entitätstyp: Softwareprodukt, Hardwareprodukt, Dienstleistung, Forschungsrichtung oder Inhalt. Dies ändert, welche Quellen relevant sind. Bei Software sind Paketregister und GitHub wichtig; bei Hardware Patente; bei Dienstleistungen lokale Markt- und Arbeitsdaten; bei Forschung Paper und Preprints.

Prüfe dann frühere Durchläufe. Liste checks/ im Skill-Verzeichnis auf und lies die Frontmatter jeder Datei, deren Betreff verwandt aussieht. Falls eine frühere Prüfung überschneidende Gebiete abdeckt, nenne dies vorab und die Datei, und entscheide dann mit dem Benutzer, ob eine frische Recherche durchgeführt oder der frühere Bericht erweitert werden soll. Eine bereits durchgeführte Prüfung zu wiederholen, ist die häufigste Verschwendung in diesem Workflow.

Erstelle ein Notizenverzeichnis im Scratchpad für diesen Durchlauf. Jeder Thread schreibt seine Ergebnisse dort hinein, sodass die Synthese aus Dateien und nicht aus der Erinnerung an vier lange Subagenten-Antworten arbeitet.

Die vier Threads

Starte alle vier als parallele Subagenten in einer einzigen Nachricht, indem du das Agent-Tool mit dem allgemeinen Typ verwendest. Jeder Thread benötigt Websuche und Fetch. Die Aufteilung ist festgelegt. Ersetze sie nicht durch eine eigene, führe Threads nicht zusammen oder füge einen fünften hinzu. Der vollständige Prompt für jeden Thread befindet sich in references/thread-prompts.md; lies diese Datei und verwende die Vorlagen wie geschrieben, wobei du die Idee, den Entitätstyp und den Notizenpfad einsetzt.

1. Stand der Technik

Wer dies bereits ausliefert. Kommerzielle Produkte mit Preisangaben, falls veröffentlicht, GitHub-Repos mit Sternen, Lizenz und letztem Commit-Datum, wissenschaftliche Arbeiten, Patente. Gib für jeden Akteur an, wie nah er an der Idee ist und was er nicht abdeckt. Die Lücken sind nützlicher als die Liste.

2. Benachbarte Platzhirsche

Welche etablierten Kategorien dies bereits als Funktion lösen und wer es absorbieren würde, falls es funktioniert. Dies ist wichtiger als direkte Wettbewerber. Produkte in diesem Bereich sterben häufiger daran, dass ein Platzhirsch die Funktion von oben einbaut, als an einem direkten Kopf-an-Kopf-Wettbewerb mit einem Startup. Nenne den wahrscheinlichsten Absorber.

3. Gräberfeld und Wirtschaftlichkeit

Was bereits hier versucht wurde und gescheitert ist: Schließungen, Übernahmen zu niedrigen Preisen, Pivots, Entlassungen, Niedergang benachbarter börsennotierter Unternehmen. Dann, wer der Käufer ist, was er tatsächlich bezahlt und ob dieses Segment überhaupt zahlen kann. Sei gegenüber dem Business Case adversariell. Ein Thread, der angewiesen ist, -Wettbewerber zu finden, wird niemals das Gräberfeld finden – deshalb ist dieser Thread getrennt.

4. Commodity-Ebene

Wie viel davon ist bereits kostenlos oder gebündelt: Fähigkeiten von Frontier-Modellen, Open Source, Funktionen innerhalb von Abonnements, die der Benutzer bereits hat. Wenn ein kompetentes Modell mit Websuche 80 Prozent davon kostenlos erledigt, sage dies und nenne das verbleibende Delta, denn das Delta ist das Einzige, was verkaufbar ist.

Verbindliche Subagenten-Anweisungen

Jeder Thread-Prompt muss diesen Block wörtlich enthalten. Er befindet sich bereits in den Vorlagen; kürze ihn nicht beim Einsetzen.

• „Gehe davon aus, dass Stand der Technik existiert, und suche danach. Deine Aufgabe ist es, herauszufinden, wer diesen Bereich besetzt, nicht zu bestätigen, dass er leer ist. Berichte, wer diesen Bereich besetzt, unverblümt.“
• „Wenn du nichts findest, schreibe ‚nichts gefunden, was nicht gleich abwesend ist‘ und liste auf, was du nicht überprüft hast.“
• „Jede Tatsachenbehauptung benötigt eine Quellen-URL.“
• „Schließe KI-generierte Listen, ‚Beste Tools 2026‘-Übersichtsseiten, programmatische Preisseiten und syndizierte Marktgrößenverkäufer von allen Tatsachenbehauptungen aus. Nenne die Quellen, die du verworfen hast. Ungefähr ein Drittel der Suchergebnisse in diesem Bereich sind Anbieter, die SEO übereinander schreiben; berichte dieses Volumen als Befund, aber zitiere es nicht.“
• „Unterscheide in jedem Befund zwischen Anbieterbehauptungen und unabhängigen Beweisen.“

Die erste Zeile ist die wertvollste Zeile dieser Fähigkeit. Die Ausrichtung einer Forschungsaufgabe auf Bestätigung statt Falsifikation verschiebt Schlussfolgerungen in veröffentlichten Messungen um 34 bis 66 Prozentpunkte. Das macht die Ausrichtung zu einer Korrektheitsanforderung, nicht zu einer Tonpräferenz. Ein Thread, der angewiesen ist zu prüfen, ob ein Bereich leer ist, wird ihn als leer melden.

Die „nichts gefunden“-Formulierung existiert, weil das Fehlen von Beweisen hier schwach ist. Kleine Wettbewerber und tote Unternehmen sind beide schlecht indexiert. Aufzulisten, was nicht überprüft wurde, ermöglicht es dem Leser, zu beurteilen, wie viel die Stille bedeutet.

Synthese

Wenn alle vier Threads zurückgekehrt sind, lies ihre Notizendateien. Führe dann zwei Dinge aus.

Drei unabhängige Landschaftslesungen

Kennzeichne die Landschaft als Offen, Überfüllt oder Gesättigt. Erzeuge diese Kennzeichnung dreimal unabhängig voneinander und halte die Lesungen tatsächlich unabhängig: starte drei parallele Subagenten, die jeweils nur die vier Notizendateien und die folgenden Kennzeichnungsdefinitionen erhalten, und bitte jeden um eine Kennzeichnung und höchstens drei Sätze Begründung. Gib ihnen nicht die Ausgaben der anderen oder deinen eigenen Entwurf. Erzeuge die Kennzeichnung nicht selbst in deinem eigenen Kontext und leite sie dann „erneut“ ab, denn eine zweite Lesung im selben Kontext ist an der ersten verankert.

Definitionen, die an jeden Leser weitergegeben werden:

• Offen: Kein Akteur deckt den Kern der Idee ab; die Commodity-Ebene lässt ein echtes Delta; das Gräberfeld ist leer oder aus Gründen gescheitert, die nicht mehr gelten.
• Überfüllt: Mehrere Akteure decken den größten Teil ab; es gibt eine Nische, aber die Platzhirsche sind nah; die Wirtschaftlichkeit ist für ein verengtes Segment plausibel.
• Gesättigt: Direkte Akteure mit veröffentlichten Preisen, ein Platzhirsch, der es bereits bündelt, oder ein Gräberfeld, das zeigt, dass das Segment nicht zahlen kann.

Berichte alle drei Kennzeichnungen und zeige jede Uneinigkeit. Mittle nicht, und wähle in der Prosa keinen Gewinner nach Mehrheit; lass den Leser die Aufteilung sehen. Die Genauigkeit von Neuigkeitsurteilen schwankt allein durch Umformulierung des Prompts zwischen 93,5 und 40,9 Prozent, und eine Drei-Aufruf-Abstimmung übertraf speziell entwickelte Ein-Pass-Werkzeuge, die zwölfmal mehr kosteten. Uneinigkeit zwischen den Lesungen ist die aussagekräftigste Zeile im Bericht.

Keine Kritikschicht

Füge über der Synthese keinen Kritiker, kein Red-Team und keinen Debattieragenten hinzu. Veröffentlichte Ergebnisse zeigen, dass Multi-Agenten-Debatte schlechter abschneidet als ein einzelner sorgfältiger Durchlauf und die Genauigkeit in den meisten getesteten Konfigurationen verschlechtert. Eine sorgfältige Synthese aus den Notizendateien schlägt ein Komitee.

Ausgabe

Drei Ziele, in dieser Reihenfolge. Die Datei ist das Ergebnis; die Konversation erhält nur eine Zusammenfassung.

1. Die Berichtsdatei, immer

Schreibe den vollständigen Bericht in checks/YYYY-MM-DD-<slug>.md im Skill-Verzeichnis, wobei <slug> ein kurzer Kebab-Case-Name für die Idee ist. Erstelle checks/, falls es nicht existiert. Beginne die Datei mit YAML-Frontmatter, damit spätere Durchläufe sie abgleichen können, ohne den gesamten Bericht lesen zu müssen:

---
idea: Einzeiler der Idee
slug: kebab-case-name
date: YYYY-MM-DD
label: Offen | Überfüllt | Gesättigt
label_reads: [Lesung1, Lesung2, Lesung3]
top_occupants: [Name1, Name2, Name3]
---

Wenn die drei Lesungen unterschiedlich sind, setze label auf die am häufigsten vorkommende oder auf Geteilt, wenn alle drei verschieden sind. Die Frontmatter ist ein Nachschlageschlüssel; der Textkörper zeigt die Uneinigkeit.

Textkörper: Markdown, unter 1.200 Wörtern. Standardmäßig Prosa, Tabellen nur, wo ein Vergleich wirklich nötig ist (z. B. mehrere Akteure mit Preisen). Keine Gedankenstriche. Abschnitte in dieser Reihenfolge mit diesen Überschriften:

1. Die Idee, wie verstanden. Ein Absatz. Der Benutzer prüft dies zuerst.
2. Wer bereits da ist. Benannt, mit URLs, Preisen, sofern veröffentlicht, und wie nah jeder an der Idee ist. Kennzeichne Anbieterbehauptungen als solche.
3. Das Gräberfeld. Was gescheitert ist und warum.
4. Die Wirtschaftlichkeit. Wer zahlt, wie viel, und ob das Segment zahlen kann.
5. Die Commodity-Ebene. Was bereits kostenlos oder gebündelt ist.
6. Landschaftskennzeichnung. Alle drei Lesungen, mit etwaiger Uneinigkeit.
7. Was wahr sein müsste. Die spezifischen Bedingungen, unter denen die Idee überlebt, und für jede, welcher Beweis sie klären würde. Kennzeichne jede Bedingung, die die Recherche bereits widerlegt hat.
8. Quellen und verworfene Quellen. Jede zitierte URL, dann die verworfenen Quellen aller vier Threads mit jeweils einphrasigem Grund.

2. Die Konversationszusammenfassung, immer

Drucke höchstens 150 Wörter: die Landschaftskennzeichnung und ob die drei Lesungen übereinstimmten, die zwei oder drei nächsten Akteure, die entscheidendste Erkenntnis und den Pfad zur Berichtsdatei. Niemand liest 1.200 Wörter in einem Terminal.

3. Eine teilbare Seite, nur falls verfügbar

Falls ein Tool zur Veröffentlichung eines Artefakts oder einer Seite in der Sitzung existiert, veröffentliche den Bericht auch als Seite und gib dem Benutzer den Link. Behandle dies als optional. Lasse den Durchlauf niemals fehlschlagen, und halte niemals die Datei oder die Zusammenfassung zurück, da dieses Tool fehlt. Es fehlt in vielen Claude-Code-Sitzungen, wo diese Fähigkeit normalerweise installiert ist.

Bekannte Grenzen

Gib diese im Bericht an, wenn sie zutreffen.

• Das Fehlen von Beweisen ist hier ein schwacher Beweis. Kleine Wettbewerber und tote Unternehmen sind beide schlecht indexiert.
• Preise für Unternehmenswerkzeuge sind oft vertriebsgeschützt und nicht verfügbar.
• Die Anzahl der Suchergebnisse ist kein Beleg für die Marktgröße; viel davon sind Anbieter, die übereinander schreiben.
• Der Bericht sagt, ob ein Bereich besetzt ist. Er sagt nicht, ob dieser Benutzer gewinnen kann, was von Informationen abhängt, die die Recherche nicht sehen kann.