L’étape d’après
GitHub

GitHub

MCP · Projet

Le MCP GitHub expose issues, PRs, reviews, actions. Sert surtout à gérer le backlog depuis Claude : triage, labels, milestones, et résumés de PR avant revue.

Documentation officielle

Cas d'usage

  1. 01Triager un backlog de 200 issues
  2. 02Résumer une PR avant review
  3. 03Créer une issue depuis un bug report

Installation

1.Crée un Personal Access Token sur GitHub : Settings → Developer settings → Personal access tokens → Fine-grained tokens. Scopes : Contents (read), Issues (read/write), Pull requests (read/write).

2.Une ligne, un terminal
$ claude mcp add github -- npx -y @modelcontextprotocol/server-github --token=YOUR_PAT

Besoin d'installer Claude Code d'abord ? Voir la fiche Claude CodeDocumentation officielle

Exemples concrets

Toi
« Triage les 80 issues ouvertes du repo 'my-app' : lesquelles sont encore pertinentes, lesquelles dupliquent, lesquelles peuvent être fermées ? »

Lit chaque issue + ses commentaires, compare les titres/bodies pour détecter les doublons, propose une action par issue.

Résultat type
→ Reading 80 open issues in my-app... Proposition de triage Encore pertinentes (34) - #122 Bug login mobile — reproduit cette semaine, à prioriser - #98 Ajout tri par date dans le tableau — demandé 3 fois, pas implémenté - [32 autres listées] Doublons (12 → 4 à garder) - #87, #93, #117 parlent tous du même bug scroll iOS → fermer #93 et #117, garder #87 - #56 et #89 demandent la même feature → fermer #89 - [3 autres clusters] À fermer (18) - #12, #34 : plus de commentaires depuis 14 mois, feature request abandonnée - #71 : bug fixé dans la PR #445 (non linké) - [15 autres] À clarifier (16) - Issues avec 0 détails actionnables. Claude peut drafter un commentaire demandant repro/context. Tu veux que j'applique ? (Je ne ferme rien sans ton ok.)
Toi
« Résume la PR #445 avant que je la review : changements, risques, questions à poser. »

Lecture diff + commentaires + description. Sort un résumé structuré pour pré-review.

Résultat type
→ Reading PR #445 "Refactor auth middleware" → 24 files changed, +842 / -317 lines, 3 review comments Changements - Remplacement de jsonwebtoken par jose (ESM, plus léger) - Extraction de la logique de refresh token dans un hook custom - Migration des tests de Jest vers Vitest Risques 1. Haute : changement de lib JWT. Les tokens existants restent valides, mais toute config de signing doit être revue (voir commit f4a2b1). 2. Moyenne : le hook useRefreshToken ne gère pas le cas où le user a plusieurs onglets ouverts (peut déclencher race condition). 3. Basse : migration Vitest, tests passent tous mais 2 sont skippés (commentaire "flaky, fix later" dans le code). Questions à poser - Pourquoi jose plutôt que next-auth ? Justification pas dans la PR. - Le cas multi-onglets est-il volontairement hors scope ou à suivre ? - Les 2 tests skippés seront-ils réactivés avant merge ?

Pour aller plus loin