Que fait idée-check ?
Recherche une idée de bout en bout et retourne un rapport de paysage. Ne retourne pas un verdict sur la viabilité de l'idée. Retourne des preuves, et les conditions dans lesquelles l'idée survit.
Avant le lancement
Réformule l'idée en un paragraphe tel que tu l'as compris, et informe l'utilisateur que tu commences la recherche. Ne pas attendre de confirmation ; la reformulation va aussi dans le rapport, pour que l'utilisateur puisse détecter une erreur de lecture d'un côté comme de l'autre. Pose une question d'abord seulement si l'ambiguïté change le marché que tu devrais rechercher (par exemple "IA pour les avocats" pourrait désigner la revue de contrats ou la découverte de litiges, et ces marchés ont des concurrents et des cimetières différents).
Choisis le type d'entité : produit logiciel, produit matériel, service, direction de recherche, ou contenu. Cela change les sources pertinentes. Le logiciel s'appuie sur les registres de paquets et GitHub ; le matériel s'appuie sur les brevets ; les services s'appuient sur le marché local et les données de travail ; la recherche s'appuie sur les articles et les prépublications.
Ensuite, vérifie les exécutions précédentes. Liste checks/ dans le répertoire de la compétence et lis le front matter de tout fichier dont le sujet semble lié. Si une vérification précédente couvre un terrain similaire, mentionne-le d'abord et nomme le fichier, puis décide avec l'utilisateur s'il faut lancer une nouvelle recherche ou étendre le rapport précédent. Répéter une vérification déjà effectuée est le gaspillage le plus courant dans ce flux de travail.
Crée un répertoire de notes dans le bloc-notes pour cette exécution. Chaque fil écrit ses conclusions là-bas, de sorte que la synthèse fonctionne à partir de fichiers, pas de la mémoire de quatre longues réponses de sous-agents.
Les quatre fils
Lance les quatre en tant que sous-agents parallèles dans un seul message, en utilisant l'outil
Agent avec le type à usage général. Chaque fil a besoin de recherche web et de récupération.
La décomposition est fixe. Ne la remplace pas par la tienne, ne fusionne pas les fils, ou n'en ajoute pas un cinquième. L'invitation complète pour chaque fil se trouve dans
references/thread-prompts.md ; lis ce fichier et utilise les modèles tels
qu'écrits, en substituant l'idée, le type d'entité et le chemin des notes.
1. Antériorité
Qui livre déjà ce produit. Produits commerciaux avec prix si publiés, dépôts GitHub avec étoiles, licence et date du dernier commit, travaux académiques, brevets. Pour chaque occupant, indique à quel point il est proche de l'idée et ce qu'il ne couvre pas. Les lacunes sont plus utiles que la liste.
2. Concurrents adjacents
Quelles catégories établies résolvent déjà cela comme une fonctionnalité, et qui l'absorberait si cela fonctionnait. C'est plus important que les concurrents directs. Les produits dans cet espace meurent plus souvent à cause d'un acteur établi qui intègre la fonctionnalité d'en haut que d'une startup en compétition directe. Nomme l'absorbeur le plus probable.
3. Cimetière et économie
Ce qui a déjà été essayé ici et a échoué : fermetures, acquisitions à faible valeur, pivots, licenciements, déclin des entreprises publiques adjacentes. Ensuite, qui est l'acheteur, ce qu'il paie réellement, et si ce segment peut payer. Sois adversaire du business case. Un fil briefé pour trouver des concurrents ne trouvera jamais le cimetière, c'est pourquoi celui-ci est séparé.
4. Socle marchandise
Quelle partie de cela est déjà gratuite ou intégrée : capacités des modèles frontières, open source, fonctionnalités dans les abonnements que l'utilisateur a déjà. Si un modèle compétent avec recherche web fait 80 % du travail gratuitement, dis-le et nomme le delta restant, car le delta est la seule chose vendable.
Instructions obligatoires pour les sous-agents
Chaque invitation de fil doit inclure ce bloc textuellement. Il est déjà dans les modèles ; ne le coupe pas lors de la substitution.
- "Suppose que l'antériorité existe et cherche-la activement. Ton travail est de trouver qui occupe cet espace, pas de confirmer qu'il est vide. Signale qui occupe cet espace, franchement."
- "Là où tu ne trouves rien, écris 'rien trouvé, ce qui n'est pas la même chose qu'absent' et liste ce que tu n'as pas vérifié."
- "Chaque affirmation factuelle nécessite une URL source."
- "Exclus les listicles générés par IA, les pages de classement 'meilleurs outils 2026', les sites de tarification programmatique et les vendeurs d'études de marché syndiquées de toutes les affirmations factuelles. Nomme les sources que tu as écartées. Environ un tiers des résultats de recherche dans ce domaine sont des vendeurs qui écrivent du SEO les uns sur les autres ; signale ce volume comme une conclusion, mais ne le cite pas."
- "Distingue les affirmations des vendeurs des preuves indépendantes dans chaque conclusion."
La première ligne est la ligne la plus précieuse de cette compétence. Cadrer une tâche de recherche vers la confirmation plutôt que la falsification déplace les conclusions de 34 à 66 points de pourcentage dans les mesures publiées. Cela fait du cadrage une exigence de justesse, pas une préférence de ton. Un fil chargé de vérifier si un espace est vide le signalera vide.
La phrase "rien trouvé" existe parce que l'absence de preuve est faible ici. Les petits concurrents et les entreprises disparues sont tous deux mal indexés. Lister ce qui n'a pas été vérifié permet au lecteur de juger combien le silence signifie.
Synthèse
Lorsque les quatre fils reviennent, lis leurs fichiers de notes. Ensuite, fais deux choses.
Trois lectures indépendantes du paysage
Étiquète le paysage comme Ouvert, Encombré ou Saturé. Produis cette étiquette trois fois de manière indépendante, et garde les lectures vraiment indépendantes : lance trois sous-agents parallèles, chacun recevant uniquement les quatre fichiers de notes et les définitions d'étiquettes ci-dessous, chacun demandant une étiquette et au maximum trois phrases de raisonnement. Ne leur donne pas les sorties des autres ni ton propre brouillon. Ne produis pas l'étiquette toi-même dans ton propre contexte pour ensuite la "re-dériver", car une seconde lecture dans le même contexte est ancrée sur la première.
Définitions à passer à chaque lecteur :
- Ouvert : aucun occupant ne couvre le cœur de l'idée ; le socle marchandise laisse un delta réel ; le cimetière est vide ou a échoué pour des raisons qui ne tiennent plus.
- Encombré : plusieurs occupants couvrent la majeure partie ; il existe une niche mais les acteurs établis sont proches ; l'économie est plausible pour un segment réduit.
- Saturé : occupants directs avec prix publiés, un acteur établi regroupant déjà la fonctionnalité, ou un cimetière montrant que le segment ne peut pas payer.
Signalez les trois étiquettes et montrez tout désaccord. Ne fais pas de moyenne, et ne choisis pas un gagnant à la majorité dans le texte ; laisse le lecteur voir la division. Les verdicts de nouveauté benchmarkés oscillent de 93,5 à 40,9 % de précision pour une simple reformulation de l'invite, et un vote à trois appels surpasse les outils spécialisés à passage unique coûtant douze fois plus. Le désaccord entre les lectures est la ligne la plus informative du rapport.
Pas de couche critique
N'ajoute pas d'agent critique, de "red-team" ou de débat sur la synthèse. Les résultats publiés montrent que le débat multi-agent est moins performant qu'un seul passage solide et dégrade la précision dans la plupart des configurations testées. Une synthèse soigneuse à partir des fichiers de notes bat un comité.
Sortie
Trois destinations, dans cet ordre. Le fichier est le livrable ; la conversation reçoit un résumé seulement.
1. Le fichier de rapport, toujours
Écris le rapport complet dans checks/YYYY-MM-DD-<slug>.md dans le répertoire
de la compétence, où <slug> est un nom court en kebab-case pour l'idée. Crée
checks/ s'il n'existe pas. Commence le fichier par un front matter YAML pour que
les exécutions ultérieures puissent le comparer sans lire tout le rapport :
---
idée: déclaration en une ligne de l'idée
slug: nom-en-kebab-case
date: YYYY-MM-DD
étiquette: Ouvert | Encombré | Saturé
lectures_étiquette: [lecture1, lecture2, lecture3]
principaux_occupants: [nom1, nom2, nom3]
---
Lorsque les trois lectures sont en désaccord, définis étiquette sur celle qui apparaît le plus
souvent, ou sur Partagé si les trois diffèrent. Le front matter est une clé de recherche ;
le corps est l'endroit où le désaccord est montré.
Corps : markdown, moins de 1 200 mots. Prose par défaut, tableaux seulement lorsque la comparaison est vraiment nécessaire (par exemple plusieurs occupants avec tarification). Pas de tirets cadratins. Sections dans cet ordre, avec ces en-têtes :
- L'idée, telle que comprise. Un paragraphe. L'utilisateur vérifie cela en premier.
- Qui est déjà là. Nommé, avec URLs, prix si publiés, et à quel point chacun est proche de l'idée. Marque les affirmations des vendeurs comme telles.
- Le cimetière. Ce qui a échoué et pourquoi.
- L'économie. Qui paie, combien, et si le segment peut payer.
- Le socle marchandise. Ce qui est déjà gratuit ou intégré.
- Étiquette du paysage. Les trois lectures, avec tout désaccord montré.
- Ce qui devrait être vrai. Les conditions spécifiques dans lesquelles l'idée survit, et pour chacune, quelle preuve la réglerait. Marque toute condition que la recherche a déjà falsifiée.
- Sources, et sources écartées. Chaque URL citée, puis les sources écartées des quatre fils avec une raison d'une phrase chacune.
2. Le résumé de conversation, toujours
Imprime au maximum 150 mots : l'étiquette du paysage et si les trois lectures étaient d'accord, les deux ou trois occupants les plus proches, la conclusion la plus décisive, et le chemin vers le fichier de rapport. Personne ne lit 1 200 mots dans un terminal.
3. Une page partageable, seulement si disponible
Si un outil de publication d'artefact ou de page existe dans la session, publie also le rapport sous forme de page et donne le lien à l'utilisateur. Traite cela comme optionnel. Ne fais jamais échouer l'exécution, et ne retiens jamais le fichier ou le résumé, car cet outil est absent. Il est absent dans de nombreuses sessions Claude Code, qui est l'endroit où cette compétence est généralement installée.
Limites connues
Indique-les dans le rapport lorsqu'elles s'appliquent.
- L'absence de preuve est une preuve faible ici. Les petits concurrents et les entreprises disparues sont tous deux mal indexés.
- Les prix pour les outils d'entreprise sont généralement verrouillés par la vente et indisponibles.
- Le volume des résultats de recherche n'est pas une preuve de la taille du marché ; une grande partie est constituée de vendeurs qui écrivent les uns sur les autres.
- Le rapport indique si un espace est occupé. Il ne dit pas si cet utilisateur peut gagner, ce qui dépend d'informations que la recherche ne peut pas voir.