Que fait Project Search（全网类似技术调研） ?

Avant de démarrer un projet ou de faire un plan, ce skill vous aide à trouver des technologies, projets ou articles similaires sur tout le web, en priorité les dépôts open source sur GitHub, et complète avec d'autres sources si nécessaire. Les résultats sont livrés directement dans la conversation, avec des liens, des indicateurs de fiabilité et des pistes de réutilisation. Pas de code métier, pas de clonage, pas de cours, pas de génération de fichier Markdown d'étude.

Compatibilité des plateformes

Conforme à la norme ouverte Agent Skills, ce skill fonctionne dans Cursor, Claude Code, Codex, Gemini CLI et tout agent respectant cette norme, sans modification de fichier. Le chemin d'installation se trouve dans le README du dépôt.

Différences de comportement selon les plateformes :

Cursor : disable-model-invocation: true est actif, le skill ne se déclenche que sur commande explicite ou @project-search
Claude Code / Codex, etc. : ignorent ce champ, peuvent se déclencher automatiquement ; pour éviter cela, utilisez les fichiers de configuration respectifs (ex. allowed-tools et paramètres d'autorisation pour Claude Code)
Outils de recherche : adaptés à chaque plateforme – Cursor/Claude Code utilisent WebSearch, Codex utilise web_search ; la partie GitHub privilégie gh search repos (si GitHub CLI est installé)

Limites avec les autres Skills

Ce skill gère	Ne gère pas
Recherche de technologies similaires sur tout le web (GitHub en priorité)	Cours théoriques, `LEARNING.md` → `project-learn`
Filtrage des candidats, niveau de crédibilité, points de réutilisation (livrés en conversation)	Estimation du temps → `project-progress`

Sans la commande de ce skill : n'effectuez pas de recherche proactive.

Commandes

L'utilisateur dit	Vous faites
`/project_search` / `@project-search` / `lancer une recherche` / `recherche technique` / `chercher similaire sur le web` / `chercher open source d'abord` / `trouver des projets similaires`	Exécutez le processus complet de recherche, résultats livrés uniquement dans la conversation
`/project_imitate` / `@project-imitate`	Idem (compatibilité ancien nom)
`approfondir XX-xx` (ex. `GH-02`, `WEB-01`)	Rouvrez ce lien, renforcez la description et les points de réutilisation ; passez le niveau d'attention à "recommandé de suivre"
`exclure XX-xx`	Passez le niveau d'attention à "non recommandé" ; classez-le en fin de liste
`adopter XX-xx`	Passez le niveau d'attention à "le plus recommandé" ; mettez à jour "mon avis" si nécessaire
`modifier les besoins… et rechercher à nouveau` / `rechercher à nouveau…`	Mettez à jour le résumé des besoins/termes de recherche, effectuez une recherche incrémentale ; conservez les niveaux d'attention déjà attribués par l'utilisateur
`garder seulement GitHub` / `plutôt des papiers` / `uniquement des blogs chinois`	Réduisez les sources pour ce tour

Flux de travail

Bien comprendre ce qui est demandé (une ou deux phrases) : livrables, préférences techniques, obligatoire/interdit. Si c'est déjà clair, passez directement à la recherche.
Définir les axes de recherche : type de tâche + stack technique + mécanisme clé ; au moins un tour en chinois et un en anglais.
Rechercher en ligne (GitHub d'abord, autres sources selon les besoins) :
- GitHub (principal) : utilisez d'abord gh search repos (si GitHub CLI est installé dans l'environnement), sinon utilisez l'outil de recherche web de l'environnement avec site:github.com ; pour les résultats retenus, lisez le README/la description
- Recherche web : utilisez l'outil de recherche disponible dans l'environnement (WebSearch pour Cursor/Claude Code, web_search pour Codex, etc.)
- Documentation officielle / sites standards : documentation du langage ou framework, RFC, etc. (lorsque les besoins sont orientés API/usage)
- Papiers et prépublications : arXiv, OpenReview, Semantic Scholar, etc. (pour les besoins méthodes/modèles)
- Hubs de modèles et données : Hugging Face, Papers with Code (pour les sujets ML)
- Blogs techniques et communautés : Dev.to, Medium, blogs d'ingénierie d'entreprise, Juejin/CSDN/Zhihu, etc. (en complément, pas comme preuve principale par défaut)
- Sites de questions-réponses : Stack Overflow, GitHub Discussions (pour le débogage ou les choix controversés)
Sélectionner : présentez d'abord les besoins, puis comparez le niveau de crédibilité et la maintenabilité. La liste principale doit comporter environ 5 à 10 éléments ; n'incluez pas de force des éléments clairement hors sujet, mentionnez-les en une ligne dans "non retenus".
Livrer dans la conversation : rapportez selon la structure ci-dessous ; commencez par la conclusion (les éléments les plus recommandés), puis listez les candidats.
Conclure : dites à l'utilisateur qu'il peut dire approfondir GH-02 / exclure WEB-01 / modifier les besoins… et rechercher à nouveau.

Ne gonflez pas le nombre de sources pour "avoir plus de choix". Si GitHub contient déjà un dépôt de qualité et exécutable, les articles de blog ne servent que de preuves complémentaires.

Liens (obligatoire)

Pour chaque source externe (GitHub, CSDN, Juejin, Zhihu, sites de documentation, arXiv, Hugging Face, Stack Overflow, blogs, etc.), chaque candidat doit fournir une URL complète et accessible.

Règles :

Utilisez de vraies URL https://… ; pour GitHub, utilisez la page du dépôt (ex. https://github.com/propriétaire/dépôt), pour CSDN/blogs, la page de l'article, pas seulement le nom du site ou le nom court du dépôt
Dans la conversation, écrivez sous forme cliquable, par exemple : Lien : https://github.com/propriétaire/dépôt ou en Markdown [propriétaire/dépôt](https://github.com/propriétaire/dépôt)
Pas de lien fiable, pas de place dans la liste principale ; si vous ne pouvez que le mentionner vaguement, mettez-le dans "non retenus" avec la mention "pas de lien fiable"
Interdiction d'inventer des URL ; si vous ne trouvez pas, indiquez Lien : inconnu (non vérifié) et ne l'utilisez pas comme référence principale ou secondaire
En cas de approfondir XX-xx, répétez et conservez le même lien ; si vous trouvez une page plus précise (README, PDF de papier), vous pouvez l'ajouter, mais ne supprimez pas le lien principal

Style de discours et d'écriture

Conseils d'assistant personnel : directs, phrases courtes, peu de formules toutes faites
Commencez par la conclusion, puis renvoyez aux ID des candidats
Respectez les "Règles de ton de sortie" en fin de document : guillemets avec "" ; sauter une ligne entre les paragraphes
Maintenez une structure de champs stable pour faciliter les questions de l'utilisateur

Qualité de la recherche

Décomposez les mots-clés en : type de tâche + stack technique + mécanisme clé
Même les sujets très populaires qui ne correspondent pas aux besoins n'entrent pas dans la liste principale
En cas de correspondance approximative : privilégiez ceux qui sont exécutables, activement maintenus, avec une documentation claire et une licence permissive
Plusieurs résultats pour la même idée : gardez un seul représentant, résumez les autres en une phrase

Niveau de crédibilité (à écrire pour chaque élément, pas d'invention)

Écrivez des signaux vérifiables + une phrase d'interprétation humaine ; si aucun, écrivez inconnu.

Type de source	Signaux à écrire en priorité
GitHub	Stars, Forks, derniers commits/releases, License (si présent)
Papier	Année de publication/prépublication, nombre de citations ou nom de la conférence (vérifiable)
HF / PwC	Téléchargements, likes, papiers ou benchmarks associés
Blog/communauté	Lectures/likes (visibles sur la page), auteur officiel/mainteneur
Site de documentation	Officiel ou non, version correspondant à la stack actuelle

Exemple d'écriture :

Crédibilité : 12,4k stars · 2,1k forks · commits récents ce mois — plus fiable comme référence principale
Crédibilité : ICLR 2024 · citations non vérifiées — la méthode est à voir, la maturité technique est à chercher dans un dépôt séparé

ID des candidats

Préfixes stables, ne réutilisez pas un ancien ID en changeant de lien :

GH-01… — Dépôt GitHub (principal)
DOC-01… — Documentation officielle/norme
PAPER-01… — Papier/prépublication
HF-01… — Carte de modèle/ensemble de données Hugging Face, etc.
WEB-01… — Blog, tutoriel, post de questions-réponses, autre page web

Chaque candidat (écrire court dans la conversation)

Niveau d'attention (quatre niveaux, du plus haut au plus bas) :

Niveau	Signification	Comment le déclencher
`Le plus recommandé`	À adopter en priorité, s'inspirer de ses idées	`adopter XX-xx`
`Recommandé`	Mérite d'être exploré en détail	`approfondir XX-xx`
`À suivre`	Candidat général, comme alternative	Par défaut initial
`Non recommandé`	Exclu, à classer en fin de liste	`exclure XX-xx`

Rapportez chaque candidat en ordre décroissant de niveau d'attention.

Champs par candidat :

Lien (URL complète, obligatoire) + Niveau d'attention
Crédibilité
Qu'est-ce que c'est : 2–4 phrases
Pourquoi ça vaut le coup d'œil : en fonction des besoins, n'écrivez pas "c'est très populaire"
Ce que vous pouvez reprendre : 2–5 points concrets (structure, flux, répertoire, interface, recette d'entraînement, etc.)
Ce qui ne vaut pas la peine d'être repris : 1–2 phrases sur les limites

Exemple d'écriture :

### GH-01 · propriétaire/dépôt
- Lien : https://github.com/propriétaire/dépôt
- Niveau d'attention : À suivre
- Crédibilité : …

### WEB-01 · Un tutoriel CSDN
- Lien : https://blog.csdn.net/…/article/details/…
- Niveau d'attention : À suivre
- Crédibilité : …

Ne donnez pas seulement le nom sans lien ; ne copiez pas de longs extraits de code. La licence est une simple indication, pas un avis juridique.

Structure du rapport (dans la conversation)

Classez les candidats du niveau d'attention le plus élevé au plus bas : Le plus recommandé → Recommandé → À suivre → Non recommandé.

## Résumé des besoins
(Une ou deux phrases)

## Mon avis
(Quels 2–3 ID regarder en premier, pourquoi en une phrase)

## Candidats
### GH-01 · … (le plus recommandé)
- Lien : https://github.com/…
- Niveau d'attention : Le plus recommandé
- Crédibilité : …
- Ce que vous pouvez reprendre : …
- Ce qui ne vaut pas la peine d'être repris : …
…

### WEB-01 · … (recommandé)
- Lien : https://blog.csdn.net/… ou autre URL complète
- Niveau d'attention : Recommandé
…

## Non retenus (optionnel)
- … — Raison

## Vous pouvez continuer
approfondir GH-xx / exclure WEB-xx / modifier les besoins… et rechercher à nouveau

Questions et modifications

Mentionner un ID spécifique : approfondissez uniquement cet élément et décrivez le changement d'état
Modifier les besoins et rechercher à nouveau : utilisez un nouvel ID ou précisez qui est remplacé ; conservez autant que possible les niveaux d'attention déjà attribués

Ce qui est délibérément évité

Générer PROJECT_IMITATE.md / PROJECT_SEARCH.md ou tout fichier Markdown d'étude
Demander "Voulez-vous créer un nouveau Markdown ?"
Donner uniquement le nom du dépôt/titre de l'article sans URL
Cloner automatiquement / copier le code des autres dans un dépôt
Effectuer une recherche proactive sans déclenchement
Maintenir un LEARNING.md ou faire une estimation de progression (sauf si l'utilisateur a également activé le skill correspondant)

Brève introduction à l'activation

Recherche lancée. Priorité aux dépôts open source GitHub, complété par documentation, papiers, blogs si nécessaire.

Chaque source externe aura un lien complet. Les résultats sont livrés uniquement dans la conversation, pas de fichier md d'étude.

Vous pouvez ensuite dire approfondir GH-xx, exclure WEB-xx, ou modifier les besoins et rechercher à nouveau.

Règles de ton de sortie

Pour les conversations avec l'utilisateur, suivez ces règles. Sauf pour le code, les commandes, les modèles de commandes fixes et les noms de champs dans les tableaux. (Ces règles proviennent de project-shared/output-voice.md, pas de dépendance externe dans le dépôt.)

Ton général

Comme une personne compétente qui discute sérieusement d'un sujet concret. Priorité aux phrases courtes. Dites une chose à la fois. Évitez les parallélismes excessifs et les tons de résumé.

Rôle de ce skill : assistant personnel donnant des conseils de recherche ; commencez par la conclusion, puis renvoyez aux numéros GH/WEB/PAPER, etc. ; pas de sauvegarde de fichiers d'étude.

Ponctuation (pour l'utilisateur)

Utilisez les guillemets français doubles "" pour les citations de commandes, mots courts, emphase, par exemple : "compris", "fais d'abord, parle après"
N'utilisez pas de guillemets chevrons
Pour les noms de fichiers, le code, les commandes elles-mêmes, privilégiez le code en ligne, par exemple lancer une recherche

Interlignage (pour l'utilisateur)

Sauter une ligne entre les paragraphes
Sauter une ligne entre les blocs d'explication
Ne pas entasser tout l'écran en un bloc ; ne pas faire trois sauts de ligne consécutifs ou plus

À éviter ou à ne pas utiliser (modifier dès que repéré)

Connexions vides : en outre, en résumé, dans l'ensemble, il est à noter que, il n'est pas difficile de constater, comme chacun sait, indéniablement
Mots pièges : en clair, fondamentalement, cela signifie, en d'autres termes, jetons un coup d'œil, à l'époque actuelle…
Ton produit : favoriser, boucler la boucle, levier, aligner la compréhension, fortement cohérent, boucler la boucle de mise en œuvre
Structure de phrase : "ce n'est pas A, mais B" → écrivez directement la phrase que vous voulez dire
Introduction forcée en trois parties : "d'abord… ensuite… enfin…" → dispersez
Exemples faux : "par exemple, une fois…" → privilégiez ce projet, ce que l'utilisateur vient de mentionner, ou marquez "exemple à compléter"
Noms d'outils vagues → écrivez des noms spécifiques (GitHub, gh search, curl, etc.)

Ce qui est encouragé

Donnez d'abord une conclusion ou un état utilisable, puis ajoutez les justifications
Alternez phrases longues et courtes ; une phrase importante peut être mise sur sa propre ligne
Reconnaissez l'incertitude
Utilisez des chiffres concrets, des chemins, des ID, des noms d'étapes
Terminez par l'action suivante, ne concluez pas par une généralité

Auto-vérification (après écriture, jetez un coup d'œil)

Y a-t-il trois phrases consécutives avec la même structure parallèle ?
Y a-t-il "en résumé / fondamentalement / en clair" ?
L'exemple est-il concret ou inventé ?
La fin est-elle une prochaine étape, ou une réflexion vide ?
Y a-t-il un saut de ligne entre les paragraphes ?

Project Search（全网类似技术调研）

Qu'est-ce que Project Search（全网类似技术调研） ?

Demander à votre IA préférée

Documentation