Chasseur de Pépites GitHub
Objectif
Identifier des dépôts GitHub à forte valeur et faible visibilité pour un domaine donné en effectuant des recherches larges dans le graphe de sujets et approfondies dans les fourchettes d'étoiles et de dates.
Quand l'utiliser
- L'utilisateur demande des « pépites cachées », « sous-estimées », « opportunités manquées » ou « qu'est-ce que je rate » dans un domaine technologique.
- L'utilisateur souhaite une découverte, pas un dépôt unique le plus connu.
- L'utilisateur fournit un sujet, un langage ou un énoncé de problème.
Quand NE PAS l'utiliser
- L'utilisateur veut le dépôt le plus populaire (faire une recherche directe par étoiles).
- L'utilisateur veut une recherche de code (utiliser la recherche de code, pas celle de dépôts).
- L'utilisateur n'a pas de token GitHub et attend des résultats approfondis (avertir des limites).
Pipeline d'exécution
Phase 0 — Vérification d'authentification
- Privilégier l'interface
ghsi elle est authentifiée ; sinon exigerGITHUB_TOKEN. - Si non authentifié, avertir : la recherche est limitée à environ 10 requêtes/min et les résultats seront superficiels.
Phase 1 — Expansion de sujets (large)
- Interroger
/search/topics?q=<sujet-utilisateur>pour trouver des noms de sujets connexes. - Construire un cluster de 3 à 8 sujets connexes.
- Construire des requêtes de dépôts avec les qualificatifs
topic:pour chaque sujet du cluster.
Phase 2 — Découpage par fourchettes d'étoiles (profond)
Pour chaque sujet du cluster, exécuter ces fourchettes disjointes :
stars:1..10, stars:11..50, stars:51..200, stars:201..1000, stars:1001..5000.
Pagination dans chaque fourchette jusqu'à la limite de 1 000 résultats.
Phase 3 — Filtre de récence
Pour les fourchettes qui renvoient plus de 1 000 résultats, diviser la plage de dates pushed: de manière récursive jusqu'à ce que chaque fenêtre soit sous la limite.
Phase 4 — Collecte des pépites à faible nombre d'étoiles
Exécuter une requête dédiée stars:1..20 par sujet avec pushed:>AAAA-MM-JJ (6 mois auparavant). Collecter ces résultats séparément.
Phase 5 — Déduplication et enrichissement
- Dédupliquer par
full_name. - Récupérer les métadonnées : étoiles, forks, problèmes ouverts, pushed_at, created_at, sujets, licence, longueur du README (via l'API contents).
- Exclure les forks sauf si l'utilisateur les demande (
fork:true).
Phase 6 — Notation et classement
Appliquer le score de pépite :
- vélocité des étoiles (étoiles / mois depuis la création)
- jours depuis le dernier push (plus bas est meilleur)
- longueur et structure du README
- densité de pertinence du sujet
- réactivité aux problèmes (si disponible)
Grouper les résultats en :
- Pépites actives (commits récents, vélocité croissante)
- Pépites pré-traction (peu d'étoiles, activité récente)
- Combler les lacunes (dépôts qui relient deux clusters de sujets)
Phase 7 — Résultat
Retourner un tableau markdown classé avec les colonnes :
dépôt | étoiles | âge | dernier push | pourquoi c'est une pépite
Inclure une courte note méthodologique et un avertissement concernant les limites de taux de l'API.
Gestion des erreurs
- Sur HTTP 403 (limite de taux secondaire) : attendre et réessayer avec backoff exponentiel.
- Sur HTTP 422 (requête trop complexe) : simplifier la requête en supprimant le qualificatif le moins important et réessayer.
- En cas de résultats vides pour une fourchette d'étoiles : sauter la fourchette et continuer.
Limitations
- La recherche GitHub limite chaque requête à 1 000 résultats ; le découpage atténue mais n'élimine pas cette limitation.
- La vélocité des étoiles est bruyante pour les dépôts très récents (moins de 30 jours).
- La longueur du README n'est qu'un indicateur proxy, pas une garantie de qualité.