Recherche GitHub

Trouver tous les dépôts pertinents et composants extractibles pour le sujet ou la question de l'utilisateur : $ARGUMENTS (Claude Code le remplit ; dans d'autres agents, c'est la requête de l'utilisateur)

La recherche par mots-clés littéraux échoue sur des sujets de niche : les développeurs nomment leurs dépôts d'après la chose qu'ils touchent (un site web, une API, une organisation, une bibliothèque), pas d'après le concept. Recherchez les artefacts que toute implémentation doit contenir, depuis plusieurs directions (code, dépôts, commits, issues, autres hébergeurs, le web), vérifiez chaque résultat et décomposez les candidats en pièces réutilisables à intégrer dans notre solution cible.

La famille rotless

Fait partie de rotless, et pleinement utilisable seule. Quand la recherche est une antériorité pour une compétence, l'appelant nomme un fichier et sa forme (prior-art.md, définie par rotless-skill-modernizer) : écrivez le rapport dans ce fichier selon cette forme. Appelants : rotless-skill-creator (étape 0, avant la construction), rotless-skill-modernizer (fix pour un outil remplacé, refresh pour l'ensemble du paysage) et rotless-skill-refiner (une leçon de "meilleure façon" est vérifiée par rapport à ce qui existe avant d'être adoptée).

Boîte à outils

Les assistants se trouvent dans le dossier scripts/ de cette compétence. Définissez S sur le chemin absolu de ce dossier une fois, à partir du répertoire de base de cette compétence (le dossier qui contient ce SKILL.md ; Claude Code l'affiche comme "Répertoire de base de cette compétence : …" lors du chargement), et appelez toujours les assistants via $S (le répertoire de travail est le projet de l'utilisateur) ; -h liste les drapeaux ; python3, ou python sur Windows. Les points d'accès hors GitHub se trouvent dans references/sources.md (même dossier). Préférez un shell POSIX (bash ; Git Bash sur Windows) plutôt que PowerShell (problèmes de citation de -, !, jq). Les exemples sarkari/UPSC sont purement illustratifs.

Outil	Ce qu'il recherche	Meilleur pour
`grepapp.py` (= outil `searchGitHub` si le MCP grep est installé)	contenu des fichiers, ~1M de dépôts populaires, regex, pas d'authentification	domaines codés en dur, lignes d'import, clés de configuration
`gh api -X GET search/code -f q='…'`	contenu des fichiers, index hérité de GitHub (plus de dépôts, pas de regex)	deuxième source de code ; signatures `path:`/`filename:`
`ghsweep.py`	nom/description/readme/sujets du dépôt, plusieurs requêtes, dédoublonné	largeur ; totaux, sujets communs, balises `[bruit ?]`
`gh search commits …`	messages de commit	dépôts dont le nom/README ne disent rien
`gh search issues … --include-prs`	texte des issues/PR	dépôts + points de douleur réels (nécessite des phrases spécifiques ; les mots génériques se noient dans les issues de robots)
`ghverify.py`	lot GraphQL, 25 dépôts/appel	existence, renommages, activité réelle, santé, preuves, drapeaux d'avertissement
`gh repo read-dir` / `read-file`, `gh api …/contents`	fichiers d'un dépôt, sans clonage	confirmation de code réel
`srcsweep.py`	21 sources non GitHub en parallèle : npm, crates, Packagist, Hex, NuGet, Maven, RubyGems, Hackage, Docker Hub, ArtifactHub, AUR, Open VSX, GitLab, Codeberg, MCP Registry, skills.sh, Hugging Face (modèles/datasets/espaces/papiers, avec le dépôt de code lié à un papier), Hacker News	antériorité en dehors de GitHub ; se termine par un registre des sources consultées / non atteintes ; `--repos` envoie les dépôts GitHub vers `ghverify.py -`
`references/sources.md`	notes sur les points d'accès + sources sans API de recherche (PyPI, Homebrew, pkg.go.dev, Product Hunt, Reddit)	suivis manuels

Règles importantes pour la recherche `gh` (testées ; les ignorer renvoie silencieusement `[]` ou des résultats erronés)

Citation : gh search <kind> "deux mots" = phrase exacte. Pour ET, passez les mots sans guillemets ; OR fonctionne sans guillemets.
Pour tout ce qui n'est pas trivial, utilisez l'API brute (syntaxe complète + total_count) : gh api -X GET search/{repositories|code|commits|issues} -f q='<requête>' -f per_page=100 --cache 1h
Tous les mots doivent correspondre dans la recherche de dépôts, donc limitez chaque requête à 2–3 mots et variez la formulation plutôt que d'empiler les termes dans une seule requête. Si un balayage retourne < 5 dépôts, raccourcissez les requêtes.
Exclusion : mots avec NOT mot ; qualificateurs avec -qualificateur:valeur. -mot retourne 0. Dans gh search, placez les exclusions après --.
Recherche de code via API = moteur hérité : pas de regex ; OR/NOT, path:, filename:, extension:, language: fonctionnent. Branche par défaut uniquement ; ignore les fichiers volumineux. Utilisez grep.app pour les regex.
Limite de résultats : 1000 par requête. Découpez les grands ensembles de résultats : created:A..B, pushed:>DATE, bandes d'étoiles stars:0..24, stars:25..99, stars:100..499 (fait également surface des pépites peu visibles), language:.
Limites de débit : recherche 30/min ; recherche de code 10/min (gh skill search la partage) ; GraphQL 5000 pts/h. Vérifiez : gh api rate_limit --jq '.resources | {search: .search.remaining, code: .code_search.remaining, graphql: .graphql.remaining}'. Utilisez --cache 1h sur les appels répétés ; quand la recherche de code est épuisée, changez de vecteur au lieu d'attendre.
Confidentialité : la recherche authentifiée retourne les dépôts privés que le compte peut voir. Ne les signalez jamais : ajoutez select(.repository.private == false) (code) / select(.private == false) (dépôts) à jq ; ghsweep.py les filtre. Ne mettez jamais les noms privés/internes de l'utilisateur dans les requêtes de recherche.
gh repo read-file / read-dir / gh discussion / gh skill nécessitent une version récente de gh (testé 2.103). Si plus ancienne, utilisez les solutions de repli gh api de l'Étape 3 ou suggérez winget upgrade GitHub.cli / brew upgrade gh.

Étape 0 — Brief (un bloc court, pas d'aller-retour sauf en cas d'ambiguïté réelle)

Écrivez : Objectif · Décomposition de la solution cible (sous-problèmes modulaires : par ex. authentification/session, scraper/analyseur, normalisation/schéma, stockage, API/interface — pour identifier ce qui peut être réutilisé et d'où) · Indispensables · Souhaitables · Anti-patrons (par ex. wrapper mince, abandonné, nécessite API payante, GPU uniquement) · Contraintes (langage, hors ligne… : ce sont des vérifications succès/échec, pas des termes de recherche) · Date limite comme date absolue ("récent" → pushed:>2025-10-24) · Effort : passage rapide (choix économique et réversible : ~10 requêtes, top 5) ou méthode complète (par défaut pour antériorité / construire-ou-acheter / intégrer). Si la demande est "alternative à X / comme X / clone de X", résolvez X vers son dépôt d'abord et partez de lui (ses sujets, README, dépendants). Vérifiez d'abord localement (gratuit, 10 secondes) : ce qui est déjà installé peut répondre : les dossiers de compétences que votre agent charge (niveaux projet et utilisateur : .agents/skills/, .claude/skills/, ~/.codex/skills/…), sa liste de serveurs MCP (par ex. claude mcp list), gh extension list. Signalez un résultat avant de chercher le monde entier.

Étape 1 — Empreinte du sujet

Écrivez 15–30 termes de recherche concrets :

Points de contact — domaines, URLs, points d'accès API, noms d'hôte, chemins RSS, ID d'application que toute implémentation doit atteindre.
Signatures de code — lignes d'import, noms de classes/fonctions SDK, variables d'environnement, clés de configuration, sélecteurs CSS, constantes distinctives.
Vocabulaire de plusieurs points de vue — constructeur, utilisateur final, académique, infrastructure, et la discipline voisine qui l'a probablement résolu en premier ; termes régionaux/non anglais, abréviations, fautes d'orthographe. Les mots ambigus ont besoin d'un terme compagnon (agent + llm, pas agent seul).
Formes — bot, scraper, API, CLI, bibliothèque, extension, serveur MCP, compétence d'agent, jeu de données, modèle, Action GitHub ; et leurs signatures de fichier (.github/workflows cron, manifest.json, SKILL.md, .claude-plugin/marketplace.json). Les compétences et plugins d'agent vivent souvent dans des dépôts plus gros (un skills/x/SKILL.md dans un monorepo de 80k★), invisibles pour la recherche de dépôts : trouvez-les avec la recherche de code filename:SKILL.md "<phrase de sa description>" (bruyant : des centaines à des milliers de résultats, donc utilisez 2 phrases distinctives et parcourez 2–3 pages) et skills.sh (srcsweep.py --sources skills ; sémantique, fonctionne mieux sur le nom de la compétence que sur son but). Le rappel des compétences est le vecteur le plus faible : si une compétence de référence ne remonte jamais, cherchez son nom directement et dites-le dans la note de couverture.
Ancres — les 3–10 projets/produits bien connus que vous vous attendez à voir dans toute bonne réponse. Utilisé à l'Étape 2 comme vérification de rappel.
Paragraphe README idéal — deux phrases décrivant le dépôt parfait, écrites comme le ferait son auteur ; exploitez-les pour trouver des termes de recherche.

Étape 2 — Recherche sur tous les vecteurs

Exécutez les vecteurs en parallèle. Enregistrez quelles requêtes ont trouvé chaque dépôt (found_by : plus de requêtes = pertinence plus forte).

A. Recherche de code (signal le plus fort). Plusieurs requêtes étroites, une par point de contact/signature :

S="<répertoire de base de cette compétence>/scripts"     # par ex. S="$HOME/.agents/skills/rotless-github-research/scripts" (ou ~/.claude/skills/… dans Claude Code)
python "$S/grepapp.py" "sarkariresult.com" --repos-only
python "$S/grepapp.py" "(sarkariresult|freejobalert)\.com" --regex --lang Python --lang JavaScript --repos-only
python "$S/grepapp.py" "upsc.gov.in" --path .github/workflows/ --repos-only          # robots planifiés
gh api -X GET search/code -f q='sarkariresult OR freejobalert language:python' -f per_page=100 \
  --jq '"total \(.total_count)", (.items[] | select(.repository.private == false) | "\(.repository.full_name)\t\(.path)")'

grep.app retourne ~10 fichiers/requête et 504 sur les regex larges : ancrez-vous sur un littéral rare, ajoutez --lang/--path. Supprimez le bruit : datasets d'URLs crawlées, listes de bloqueurs de pubs, monorepos où le terme apparaît une seule fois.

B. Recherche de dépôts (largeur + taille du paysage).

python "$S/ghsweep.py" --pushed ">2024-01-01" --order hits "sarkari OR naukri NOT resume" "freejobalert" "topic:government-jobs"
python "$S/ghsweep.py" --sort stars "topic:sarkari-result"      # produits phares dont les descriptions ignorent les mots génériques
python "$S/ghsweep.py" --sort updated "sarkari scraper"         # travail récent enterré par best-match
python "$S/ghsweep.py" --must "scrap|crawl|alert|job" --exclude "resume|linkedin" "sarkari OR naukri"   # filtre de pertinence ; les homonymes ("prior art" = brevets) inondent autrement les résultats
gh api -X GET search/topics -f q=sarkari --jq '.items[].name'   # découvre les slugs de sujets

ghsweep.py affiche les totaux (à quel point l'espace est encombré), les sujets les plus courants (→ prochaines requêtes ; essayez aussi des paires de sujets partagées par ≥2 meilleurs résultats : topic:a topic:b), et les balises [bruit ?] (tutoriel/modèle/démo/dotfiles/awesome : rétrogradez, ne supprimez pas automatiquement). Supprimez --pushed pour l'antériorité, indépendamment de l'âge.

C. Recherche de commits : gh search commits sarkariresult --limit 50 --json repository,commit --jq '.[] | "\(.repository.fullName)\t\(.commit.message | split("\n")[0])"'

D. Recherche d'issues/PR : gh search issues "freejobalert" --include-prs --limit 50 --json repository,title,url (phrases spécifiques uniquement).

E. Effet boule de neige à partir des meilleurs résultats (top 3–5) :

Suivez la dépendance enveloppée : si un résultat "enveloppe", "est construit sur" ou "utilise" X, recherchez X aussi : c'est souvent le véritable acteur en place. L'endroit le plus courant où l'on s'arrête trop tôt.
Listes "Awesome" : python "$S/ghsweep.py" --sort stars "awesome <mot-clé> in:name" ; prenez les listes awesome-* avec ≥200★, extrayez leurs liens de dépôt (gh repo read-file README.md --repo o/awesome-x | grep -oE 'github\.com/[A-Za-z0-9_.-]+/[A-Za-z0-9_.-]+' | sort -u) et canalisez-les vers ghverify.py -. Être listé est un signal de qualité léger.
Dépôts similaires : sujets + langage d'un meilleur résultat → topic:a topic:b language:x, préférez le même niveau d'étoiles.
Sections README "Alternatives / Similaire / Inspiré par / Crédits" ; chaînes de code distinctives → grep.app (trouve les copies et les ports) ; autres dépôts de l'auteur (gh repo list <propriétaire> --limit 100) ; forks avec travail propre (gh api "repos/o/r/forks?per_page=100" --jq '.[] | select(.pushed_at > .created_at) | .full_name') ; page des dépendants de la bibliothèque via votre outil de récupération web ou curl (github.com/o/r/network/dependents).

F. Hors GitHub : une commande, plusieurs formulations (1–3 mots chacune ; registres ET les termes) :

python "$S/srcsweep.py" "repository discovery" --limit 4        # 21 sources, ~10s, se termine par un registre des sources consultées / NON ATTEINTES
python "$S/srcsweep.py" "sarkari" --repos | python "$S/ghverify.py" -   # dépôts GitHub liés à partir des résultats, vérifiés

Ensuite, utilisez la recherche web pour ce qui n'a pas d'API de recherche (PyPI site:pypi.org, Homebrew, pkg.go.dev, Product Hunt, Reddit, blogs, awesome <sujet>). Pour la recherche d'antériorité/concurrentielle, listez également les produits commerciaux notables. Les résultats hors GitHub (GitLab, Codeberg, registre uniquement) ne peuvent pas passer par ghverify.py : vérifiez-les manuellement et marquez la preuve comme Documentée/Métadonnées.

Arrêt et rappel. Arrêtez-vous quand les nouvelles requêtes retournent principalement des dépôts connus, mais trois requêtes retournant le même dépôt est un minimum local, pas une couverture. Vérifiez les ancres de l'Étape 1 : toute ancre non remontée par vos recherches signifie un écart de vocabulaire : trouvez quels mots elle utilise et cherchez-les. Zéro résultat signifie "cette route ne peut pas le voir", pas "ça n'existe pas" : reformulez ou changez de route une fois avant de conclure.

Étape 3 — Vérification et évaluation

Chaque candidat passe par ghverify.py (les noms inventés apparaissent comme NON TROUVÉ ; les renommés montrent le nom actuel) :

python "$S/ghverify.py" propriétaire/dépôt https://github.com/o2/r2 ...      # ou : ... | python "$S/ghverify.py" -

Lisez ses colonnes : dernier commit substantiel (ignore bump/chore/deps/merge/typo/docs) pas pushedAt ; % de résolution d'issues ; PR fusionnées ; personnes ; org/utilisateur ; versions/an ; preuves (tests, ci, manifest, security.md ; NONE = README uniquement, vérifiez dur) ; drapeaux !velocity (>100★/jour : viral ou acheté, nécessite contexte), !lowfork (≥1000★, forks/étoiles < 0.005), new (<14 jours), stale Ny (aucun commit substantiel depuis 2+ ans : signalé, jamais rétrogradé : un outil abandonné prouve toujours que l'idée a été construite), bruit ?.

Confirmez ensuite le code réel pour chaque dépôt que vous allez signaler (les README mentent dans les deux sens). Ancrez la preuve à un commit :

sha=$(gh api repos/o/r/commits/HEAD --jq .sha)
gh repo read-dir src --repo o/r --ref $sha                    # JSON : --json name,type --jq '.entries[]'
gh repo read-file path/to/main.py --repo o/r --ref $sha       # repli : gh api "repos/o/r/contents/CHEMIN?ref=$sha" -H "Accept: application/vnd.github.raw"
gh api "repos/o/r/git/trees/$sha?recursive=1" --jq '"\(.tree|length) fichiers", (.tree[:80][] | .path)'

Citez des permaliens https://github.com/o/r/blob/<sha>/<chemin>#L10-L40, pas des liens de branche.

Adéquation et Extractabilité : fort / partiel / faible / hors_cible, listant

…

[La suite a été tronquée pour la traduction]

Recherche GitHub Approfondie

Qu'est-ce que Recherche GitHub Approfondie ?

Demander à votre IA préférée

Documentation