100x-recherche-visuelle

Que fait 100x-recherche-visuelle ?

Positionnement en une phrase

Saisissez une fiche produit/persona, générez 15 phrases de recherche en anglais par plateforme (Pinterest / TikTok / Reddit) pour trouver des visuels de référence, des sources d'inspiration et du contenu comparable. Appartient à la couche de génération créative L2 du système 100x, correspondant à l'étape « mots-clés de recherche ».

Quand déclencher

L'utilisateur dit :

• « Aide-moi à trouver des visuels de référence » / « Cherche des images d'inspiration » / « Où trouver des visuels de référence ? » / « Donne-moi des mots-clés de recherche »
• « what should I search on Pinterest » / « find reference images »
• « need TikTok/Reddit search terms for this product »
• ou donne directement une fiche produit / persona en demandant un ensemble de termes de recherche

Entrée

Entrée minimale (catégorie A, obligatoire) : category (catégorie, texte libre, ex. « compléments alimentaires » « ameublement » « beauté & soins » ; se référer aux futures taxonomies/, interdiction d'utiliser un dictionnaire de catégories spécifique à un client). product_name n'est pas une entrée obligatoire de l'utilisateur — si aucun nom de marque/produit précis n'est disponible, utiliser « [ancre-catégorie] <category> » comme placeholder et continuer (le schema.json exige que product_name dans la sortie soit une chaîne non vide, c'est une « obligation du contrat de sortie », pas une « obligation de l'entrée utilisateur » ; ce sont deux choses distinctes). Voir workflow.md Phase 1, validation de catégorie A.

Compléments facultatifs (catégorie B, si absents, dégradation en trois niveaux, voir workflow.md Phase 1) : core_benefit, target_audience, brand_tone, topic_angle (valeurs possibles : default / aesthetic / pain-driven / sales-push).

Résultats optionnels en amont (catégorie C, si absents, ignorés silencieusement — ne bloquent jamais et n'obligent jamais l'utilisateur à exécuter d'abord un autre skill) : fiche persona, résultats d'insights, résultats de points chauds. S'ils sont fournis, ils doivent réellement influencer la génération — en phase 2C, au moins 6 requêtes doivent refléter les termes spécifiques d'audience/identité issus de la fiche persona ; il ne suffit pas d'accepter la fiche sans que cela se voie dans les résultats. Voir workflow.md Phase 1, étape 4 / Phase 2, paragraphe correspondant.

Sortie

Structure selon schema.json : queries.pinterest/tiktok/reddit avec 15 entrées {q, intent_cn, stage} chacune, meta.based_on_5a déclare la couverture 5A de cette exécution. Si une entrée de catégorie C (persona/insight) est fournie, meta.persona_informed doit être true et meta.persona_descriptor_terms doit lister les termes d'audience/identité extraits de la fiche, sinon la sortie n'est pas conforme (axiome 5) ; si aucune entrée de catégorie C n'est fournie, ces deux champs peuvent être omis. Optionnel : rendu de 3 tableaux Markdown (un par plateforme, colonnes : # / query / search_intent_cn / 5a_stage).

Contraintes fondamentales (5 axiomes, voir axioms.md)

1. Exactement 15 requêtes par plateforme, en anglais ASCII uniquement ; une de moins ou un mélange avec du chinois = invalide
2. Différenciation impérative entre plateformes : Pinterest = mots esthétiques / TikTok = hashtags + termes viraux / Reddit = questions douloureuses ; mélange entre plateformes = invalide
3. Génération basée sur une répartition intentionnelle selon le framework 5A ; meta.based_on_5a obligatoire et non vide ; les 45 requêtes couvrent ≥3 étapes
4. Chaque requête doit être accompagnée d'une annotation d'intention de recherche en chinois (≤20 caractères), format obligatoire : « étiquette de catégorie fermée + explication purement en chinois » (limite connue : il s'agit d'une validation de format, qui empêche « recopier intégralement une traduction anglaise », mais ne peut pas empêcher des cas plus subtils comme « coller une étiquette valide tout en traduisant littéralement chaque mot » — par exemple, préfixer une traduction littérale par « Doute : » passerait la validation. C'est une lacune sémantique connue, pas une « garantie zéro traduction littérale », voir axioms.md axiome 4 TODO)
5. Si une entrée persona/insight est fournie, elle doit vraiment se refléter dans les résultats : quand persona_informed=true, au moins 6 des 45 requêtes doivent contenir les termes d'audience/identité déclarés dans persona_descriptor_terms, sinon la sortie est invalide (limite connue : le critère basé sur une liste de mots ne peut pas empêcher de « piocher paresseusement quelques termes trop larges pour faire du remplissage », seulement les cas « aucun usage », voir axioms.md axiome 5)

Limite (sans exception) : Quelle que soit la langue source du texte produit (prise en charge de l'anglais, de l'espagnol et d'autres langues en entrée), les termes de recherche générés sont toujours en anglais — c'est une conséquence directe de l'axiome 1, pas une restriction supplémentaire. Il n'existe pas d'option de version non anglaise : les phrases de sortie sont strictement validées par le schema.json pour l'ASCII, aucune branche de production non anglaise.

Processus en trois phases

Voir workflow.md : Phase 1 réception + validation (catégories A/B/C) → Phase 2 (répartition 5A → génération par plateforme → auto-vérification par requête → auto-vérification par lot) → Phase 3 reprises déclenchées par l'utilisateur (L1 une requête / L2 un lot / L3 tout le lot ; pas de L4 — axiome 1 sans exception pour les sorties non anglaises, voir « Limite » ci-dessus).

Garantie d'appel autonome

Catégorie A manquante (c'est-à-dire category manquant — ne pas avoir de nom de marque précis pour product_name n'est pas un échec de catégorie A, voir section « Entrée » ci-dessus) → message de refus fixe demandant la catégorie, pas de supposition, pas d'invention. Jamais d'obligation pour l'utilisateur « d'exécuter d'abord un autre skill ». Catégorie B manquante → dégradation en trois niveaux (complet → une question → inférence interne + avertissement dans meta.warnings). Catégorie C manquante → ignorée silencieusement.

Mots interdits

« fais-moi », « j'espère », « peut-être », « probablement », « possible », « peut-être », « laissez-nous » ; ton de service client IA (as an AI / I'd be happy to / feel free to) ; mots esthétiques inefficaces : attractive/beautiful/stunning/serene/pristine/elegant/cinematic/professional/studio/flawless ; ne pas inventer de subreddit (ce skill n'ajoute pas de préfixe r/xxx par défaut, voir axioms.md TODO) ; ne pas inventer d'effets, de certifications ou de témoignages utilisateurs.

Détection de signaux de catégories sensibles (barrière de conformité de contenu, limitée connue, pas un axiome)

Ce skill scanne category/product_name ainsi que toutes les q/intent_cn générées. Si simultanément les « signaux de catégorie sensible » (mots liés à la santé intime/soins privés et leurs synonymes/périphrases) et les « signaux de déclaration d'autorité » (mots inventés comme certification FDA, médecin, expert et leurs synonymes) sont détectés, la génération n'est pas refusée, mais un avertissement fixe est ajouté dans meta.warnings. Critères de détection dans workflow.md Phase 1, étape 6 ; liste des mots-signaux dans scripts/validate.js.

Limite connue (explicitement déclarée, pas « déjà résolue ») : Il s'agit d'un critère basé sur une liste fixe de mots-clés, pas d'un critère sémantique. Il a deux limitations structurelles : ① la liste ne couvre que les synonymes/périphrases courants ; tout nouveau terme inventé ou reformulation non répertoriée peut le contourner ; ② il ne peut scanner que les champs présents dans le JSON final (category/product_name/tous les q/tous les intent_cn), et ne voit pas le texte d'entrée complet qui n'a pas percolé dans ces champs. Note de conception : La portée du scan des deux signaux est unifiée sur tous les champs textuels (category/product_name et les query / intent_cn générés), et la liste de mots a été enrichie de synonymes courants (cela réduit simplement la brèche, sans la colmater). On ne peut pas prétendre qu'« élargir la liste bouche tout » — si une garantie plus forte est nécessaire, il faut une détection sémantique, qui est le même type de problème que le « verrou de format vs. verrou sémantique » de l'axiome 4 TODO.

Routage (recommandé, non obligatoire)

• Produit existant mais manque de catégorie/profil de points forts → skill de fiche persona/profil (si déjà construit)
• Transformer les visuels trouvés en prompts de génération → skill d'assemblage de prompts (si déjà construit)
• Faire de la dissémination médiatique plutôt que chercher des visuels de référence → skill de dissémination visuelle (si déjà construit)
• Revenir à l'entrée pour un nouveau tri → entrée générale du système 100x (si déjà construit)

Tous ces éléments sont des « recommandations après sortie selon les besoins », pas des dépendances préalables ; les skills correspondants n'étant pas encore construits n'empêchent pas ce skill de fonctionner de manière autonome.

Auto-validation en usine

Exécutez node scripts/validate.js --selftest pour vérifier. Les axiomes 2 et 3 sont des règles d'agrégation inter-éléments, que le schema.json (vanilla JSON Schema) ne peut pas exprimer ; le véritable jugement est effectué par scripts/validate.js :

node scripts/validate.js <bundle.json> [bundle2.json ...]   # valider la sortie
node scripts/validate.js --selftest                          # exécuter les cas de test intégrés

Source

Ce skill est basé sur le système méthodologique de recherche d'inspiration visuelle. Il adopte une conception autonome (incluant axioms.md, workflow.md, sources.md, schema.json et un script de validation), ne dépend d'aucun chemin privé externe et ne contient pas de données privées. L'évolution itérative est détaillée dans sources.md.