search

Rechercher dans la base de données awesome-ChatGPT-repositories : "$ARGUMENTS"

Instructions

Étape 1 — Interpréter la requête

La requête de l'utilisateur est : "$ARGUMENTS"

Modificateurs de requête supportés :

• category:<name> — filtrer par une catégorie
• language:<lang> — filtrer par langage de programmation
• list categories ou categories — aller à l'étape 5b
• Texte brut — recherche par mot-clé dans toutes les catégories

Les descriptions sont en anglais, donc convertissez les requêtes non-anglaises en mots-clés anglais avant de chercher.

Exemples : | Requête utilisateur | Mots-clés anglais à chercher | |------------|---------------------------| | RAGを使ったチャットボット | RAG, retrieval, chatbot, vector | | 코드 생성 도구 (Korean) | code generation, copilot, autocomplete | | 中文问答系统 | chinese, QA, question answering | | outil de résumé (French) | summarization, summary, text | | LLMを使ったエージェント | agent, autonomous, LLM, tool use |

Conseils sur les mots-clés :

• Utilisez des radicaux, pas des mots complets. La correspondance de sous-chaîne capture les variantes : embed → embedding/embeddings, retriev → retrieval/retrieve, classif → classification/classifier, generat → generation/generative, fine-tun → fine-tune/fine-tuning, summari → summarize/summarization, orchestrat → orchestrate/orchestration.
• Ajoutez des noms spécifiques au domaine. Pour les domaines courants LLM/IA, incluez les noms d'outils ou frameworks bien connus présents dans la base de données :

• Visez 3–6 mots-clés. Trop peu en manquent, trop beaucoup gonflent les correspondances partielles de faible qualité.

Étape 2 — Chercher les fichiers de données avec grep

Les données sont divisées en fichiers par catégorie. Chaque fichier est un array JSON avec un enregistrement de repo par ligne, vous pouvez utiliser grep pour trouver des correspondances au lieu de lire les fichiers entiers — cela garde l'usage de tokens bas (une requête type tire quelques dizaines de lignes correspondantes au lieu de centaines de KB). Champs par enregistrement :

• u: URL GitHub · n: nom du repository · d: description anglaise
• c: catégorie · l: langage (optionnel) · t: topics séparés par des virgules (optionnel)
• sc: score de qualité 0–8 · st: nombre d'étoiles (optionnel) · ns: score d'étoiles normalisé 0–10 (optionnel)

Liste des fichiers (tous sous data/ relatif à ce plugin ; six catégories sur ~200 entrées sont divisées a/b) :

Quels fichiers chercher — choisissez l'ensemble minimum qui couvre la requête, puis appliquez grep (ci-dessous) :

Règle A — category: spécifiée : cherchez uniquement le(s) fichier(s) de cette catégorie, ignorez le routage ci-dessous. Faites correspondre le nom de catégorie sans sensibilité à la casse et acceptez les variantes courantes : cli/clis/command-line → CLIs · chatbot/bot/chatbots → Chatbots · browser/extension/browser-extension → Browser-extensions · prompt/prompts → Prompts · tutorial/tutorials → Tutorials · reimpl/reimplementation → Reimplementations · awesome/lists → Awesome-lists · open ai/openai → Openai. Si la valeur ne correspond à aucune catégorie, utilisez le routage par mots-clés (Règle C).

Règle B — list categories : ignorez toutes les lectures de fichiers, allez à l'étape 5b.

Règle C — routage par mots-clés pour les requêtes générales :

Utilisez les mots-clés anglais de l'étape 1 (pas le texte de la requête originale) pour le routage. Pour chaque ligne ci-dessous, vérifiez si un mot-clé anglais contient ou correspond aux termes listés (correspondance de sous-chaîne, sans sensibilité à la casse). Utilisez les fichier(s) de cette ligne uniquement s'il y a une correspondance. Si plusieurs lignes correspondent, collectez tous leurs fichiers (dédupliqués). Si aucune ligne ne correspond, utilisez le défaut : repos-chatbots-a.json, repos-nlp-a.json, repos-openai-a.json, repos-others-a.json.

Puis appliquez grep à ces fichiers pour les mots-clés — n'ouvrez PAS les fichiers entiers avec l'outil Read. Localisez le répertoire data une fois :

DATA="$(find "${HOME}/.claude/plugins" "${PWD}" -type d -name data -path "*awesome-chatgpt-search*" 2>/dev/null | head -1)"

Ensuite, appliquez grep aux fichiers sélectionnés pour vos mots-clés de l'étape 1 et limitez la sortie. Utilisez -F (correspondance de sous-chaîne littérale — même sémantique que l'étape de scoring, et sûr pour les mots-clés comme c++ ou .net) avec un -e par mot-clé :

grep -ihF -e keyword1 -e keyword2 -e keyword3 "$DATA"/repos-nlp-a.json "$DATA"/repos-nlp-b.json | head -120

Chaque ligne de sortie est un enregistrement de repo (un objet JSON) qui a correspondance à au moins un mot-clé — notez ces lignes directement à l'étape 4. Cela lit uniquement les repos correspondants, pas les fichiers entiers. Notes :

• Si grep retourne moins de ~8 lignes, élargissez les mots-clés (ajoutez des radicaux/noms d'outils de l'étape 1) et relancez.
• S'il retourne la limite head complète, vos mots-clés sont bons ; continuez.
• N'utilisez l'outil Read que sur des fichiers individuels si grep n'est pas disponible.

Étape 3 — Filtrer par langage (si language:<lang> a été donné)

Ajoutez un filtre de langage au pipeline grep (le champ l contient le langage, correspondance insensible à la casse) :

grep -ihF -e keyword1 -e keyword2 "$DATA"/repos-clis-a.json "$DATA"/repos-clis-b.json | grep -iF '"l":"<lang>"' | head -120

Étape 4 — Noter les candidats

En utilisant les mots-clés anglais de l'étape 1, calculez un score de pertinence pour chaque enregistrement de repo retourné par grep :

Score de correspondance textuelle (insensible à la casse, par mot-clé) :

• Correspondance exacte du nom (n) : +20 pts
• Le nom (n) contient le mot-clé : +10 pts
• La description (d) contient le mot-clé : +5 pts
• Les topics (t) contiennent le mot-clé : +3 pts
• La catégorie (c) contient le mot-clé : +2 pts

Bonus de popularité (ajouté une fois par élément) :

• Si ns (score d'étoiles normalisé) est présent : min(4, ns * 0,4)
• Sinon : min(4, sc * 0,5)

Bonus de qualité (toujours ajouté) : min(2, sc * 0,25)

Score combiné = text_match + popularity_bonus + quality_bonus

Excluez les éléments avec text_match < 5 (capture uniquement les correspondances partielles accidentelles). Collectez les 20 meilleurs candidats par score combiné.

Étape 5a — Re-classer avec votre jugement

Appliquez le jugement sémantique pour produire la liste ordonnée finale de jusqu'à 10 résultats.

Re-classez en évaluant chaque candidat sur :

1. Centralité sémantique — dans quelle mesure ce repo aborde-t-il directement l'intention centrale de la requête ?
2. Signal de qualité — un sc plus élevé signifie un projet plus riche et mieux documenté.
3. Adéquation à la catégorie — faites correspondre le type de repo au besoin implicite :
   • "construire un chatbot / ボット" → préférez Chatbots, CLIs
   • "apprendre / tutorial / 勉強" → préférez Tutorials
   • "prompt engineering" → préférez Prompts
   • "utiliser depuis le navigateur" → préférez Browser-extensions
   • "tâche NLP" → préférez NLP, Langchain
   • "OpenAI API" → préférez Openai
4. Spécificité — un repo spécialisé pour le cas d'usage exact bat un général.
5. Adéquation du langage — si l'utilisateur a implicitement indiqué un langage, préférez les repos avec un l correspondant.

Étape 5b — Lister les catégories (seulement si la requête était list categories / categories)

Ignorez la notation. Présentez :

## Catégories disponibles

| Catégorie | Nombre |
|----------|-------|
| Awesome-lists | 96 |
| Prompts | 184 |
| Chatbots | 379 |
| Browser-extensions | 252 |
| CLIs | 240 |
| Reimplementations | 42 |
| Tutorials | 21 |
| NLP | 412 |
| Langchain | 178 |
| Unity | 17 |
| Openai | 325 |
| Others | 461 |
| **Total** | **2 607** |

Étape 6 — Formater la sortie

## Résultats de recherche pour "$ARGUMENTS"

*(Recherché : keyword1, keyword2, ...)*

Trouvé N résultat(s).

### 1. [repository-name](url)
**Catégorie :** category  ·  **Langage :** language  ·  ⭐ {st} stars
Description text here.
*Topics: tag1, tag2, tag3*

### 2. ...

Omettez la ligne Language si l est absent. Omettez ⭐ stars si st est absent. Omettez la ligne Topics si t est absent.

Si aucun résultat trouvé, suggérez des mots-clés alternatifs et créez un lien vers : https://github.com/taishi-i/awesome-ChatGPT-repositories

Étape 7 — Guide de sélection de cas d'usage en sortie

Après la liste des résultats de recherche, ajoutez une table de guide pour aider les utilisateurs à choisir le bon repo pour leur situation spécifique.

Faites correspondre l'en-tête de section et la langue du tableau à la langue de la requête — si la requête était en japonais, utilisez le japonais pour l'en-tête et les en-têtes de colonne ; sinon utilisez l'anglais.

## Guide de sélection de cas d'usage

| Cas d'usage | Recommandé | Score | Pourquoi |
|---|---|---|---|
| ... | [name](url) | sc=N | courte raison |

Règles :

• Listez 3–6 cas d'usage distincts dérivés des 10 meilleurs résultats. Chaque ligne doit représenter un scénario significativement différent (p. ex. « déployer un chatbot auto-hébergé » vs. « construire un pipeline RAG »), pas juste une reformulation de la requête.
• Pour chaque ligne, sélectionnez le single meilleur repo des 10 meilleurs résultats.
• Colonne Score : affichez sc=N en utilisant le score de qualité de l'élément.
• Pourquoi : écrivez une raison de 10–15 mots dans la langue de la requête expliquant le bénéfice pratique. Ne copiez pas la description verbatim.
• Si deux cas d'usage correspondent au même repo, fusionnez-les en une ligne ou supprimez le plus faible.
• S'il y a moins de 3 cas d'usage significativement distincts dans les résultats, affichez autant de lignes que cela a du sens (minimum 1).