Comment trouver un bon premier problème et livrer une correction en une heure
Quand l'utiliser : Vous souhaitez contribuer à un projet mais n'avez aucune idée par où commencer. Le CONTRIBUTING.md du responsable est trop générique pour être utile.
Prérequis
- PAT GitHub avec
repo:readetissues:read— github.com/settings/tokens — à granularité fine, limité au dépôt auquel vous souhaitez contribuer - MCP filesystem également installé — permet à Claude de cloner et lire le dépôt localement pour vraiment écrire le correctif
Déroulement
-
Demandez à Claude de trouver les problèmes marqués
good first issuesans commentaires, triés par simplicitéTrouvez les problèmes ouverts dans modelcontextprotocol/servers étiqueté 'good first issue' sans assignataire et zéro commentaire. Choisissez celui qui semble le plus facile à corriger et expliquez pourquoi.✓ Copié→ Claude retourne 3-5 candidats avec une évaluation de difficulté d'une ligne pour chacun -
Demandez à Claude de récupérer le corps du problème et tout code liéTirez le corps complet du problème #<num> et lisez le fichier qu'il mentionne. Dites-moi le changement réel qui doit se produire.✓ Copié→ Intent diff concrète, pas seulement une reformulation du problème
-
Utilisez le MCP filesystem pour faire l'édition, puis GitHub MCP pour rédiger la PRAppliquez le changement, rédigez une description PR qui remercie le responsable et explique la correction en 3 phrases.✓ Copié→ La PR s'ouvre avec lien retourné
Résultat : Une PR ouverte qui respecte le style du projet, référence le problème, et est suffisamment petite pour être fusionnée le même jour.
Pièges
- Claude choisit un 'good first issue' qui pourrissait en réalité depuis 2 ans parce que personne ne pouvait s'accorder sur le correctif — Ajoutez
pas de nouveaux commentaires des responsables au cours des 90 derniers jourscomme filtre - Le corps de la PR est du charabia générique généré par l'IA — Dites à Claude de d'abord imiter le ton des 3 dernières PR fusionnées du projet