Tutorial sul connettore Claude Code: fai triage dei repo GitHub in 20 minuti

In questo tutorial ti mostrerò come collegare Claude Code a GitHub usando un connettore Claude (basato sul Model Context Protocol) e usarlo per fare il triage end-to-end di un repository open source. 

Il flusso di lavoro non clona nulla, non richiede un vector store e non tocca neanche una riga nel repo di destinazione. Invece, Claude Code legge le issue tramite il connettore e scrive artefatti sul tuo filesystem locale che rivedi prima di decidere cosa (se qualcosa) pubblicare.

Alla fine di questo tutorial avrai:

• Una configurazione funzionante di Claude Code e GitHub MCP con un token in sola lettura,
• Alcuni prompt riutilizzabili che puoi puntare a qualsiasi repo pubblico,
• Un artefatto di triage completo per langchain-ai/langchain con cui confrontarti.

Cos'è il connettore Claude Code GitHub (MCP)?

Claude Code è l'agente di coding da terminale di Anthropic. 

Out of the box ha già accesso al tuo filesystem, alla shell e a git. I connettori di Claude Code lo estendono per raggiungere contesti esterni, come le issue di GitHub, i ticket di Linear, i messaggi di Slack, le query Postgres e così via, che il terminale da solo non può toccare.

Il protocollo del connettore si chiama MCP (Model Context Protocol), uno standard aperto per esporre strumenti e dati agli agenti LLM. 

Anthropic mantiene una directory di connettori pronti all'uso, e puoi anche scriverne di tuoi o collegarti a server MCP di terze parti.

Per questo tutorial useremo l'official GitHub MCP server, che gira in locale tramite Docker. Alcune idee alla base della configurazione:

• Gira come container Docker locale senza intermediari cloud, quindi le credenziali restano sulla tua macchina.
• Autenticato con un normale GitHub Personal Access Token (PAT), quindi non serve registrare un'app OAuth.
• Supporta permessi con scope, ad esempio un PAT senza scope, che dà accesso in sola lettura ai repo pubblici, rendendo impossibile scrivere a livello di API GitHub.
• Viene esposto a Claude Code tramite il comando claude mcp add, dopodiché gli strumenti sono disponibili in ogni sessione.

Il triage open source è intenso in lettura, richiede giudizio e costa poco sbagliare. 

Leggere 50 issue e raggrupparle è noioso per un umano, ma adatto a un modello che può tenere tutto in contesto contemporaneamente. 

Inoltre, prima scriviamo gli output come file locali; un cluster sbagliato o una bozza goffa non costano nulla, e puoi intercettarli in revisione.

Tutorial sul connettore Claude Code GitHub: crea un triage per langchain-ai/langchain

In questa sezione configureremo il connettore GitHub in Claude Code ed eseguiremo quattro prompt di triage su langchain-ai/langchain. È un grande repo di ML con un issue tracker davvero disordinato. In sintesi, ecco cosa costruiremo:

• Collega Claude Code a GitHub tramite l'MCP server ufficiale in esecuzione su Docker,
• Usa un PAT con zero scope così il connettore è in sola lettura per costruzione,
• Esegui prompt di triage che salvano i risultati su file locali,
• Rivedi gli output, inclusi alcuni casi in cui Claude ha rifiutato di raggruppare le issue come duplicati.

Costruiamolo passo dopo passo.

Passo 1: Installa i prerequisiti per Claude Code e Docker

Prima di configurare il connettore, ti servono tre cose:

• Claude Code: puoi installarlo dalla guida ufficiale di Anthropic,
• Docker Desktop: l'MCP server ufficiale di GitHub gira in un container, quindi Docker deve essere installato e avviato,
• Un account GitHub: serve per generare il PAT nel prossimo passo.

Una volta pronti tutti i prerequisiti, verifica che Docker sia in esecuzione:

docker info | head -5

Se Docker non è installato o il demone non è attivo, vedrai l'errore "Cannot connect to the Docker daemon". Su macOS, avvia Docker Desktop con:

open -a Docker

Docker Desktop impiega 15-60 secondi per essere completamente pronto, e docker info continuerà a dare errore in quella finestra. Invece di controllare a mano, usa un piccolo one-liner di attesa che fa polling finché il demone non è su:

until 

docker info >/dev/null 2>&1; do sleep 2; echo "waiting..."; done && echo "Docker ready"

Una volta che stampa Docker ready, puoi procedere.

Passo 2: Crea un token GitHub in sola lettura

Una volta configurato Docker, vai su github.com/settings/tokens e genera un nuovo token classic.

Nota: lascia tutti gli scope deselezionati. Un token senza scope può comunque leggere i repository pubblici tramite le API di GitHub, che è tutto ciò di cui ha bisogno il nostro agente. Senza alcuno scope selezionato, il token non può scrivere, modificare o eliminare nulla su GitHub, indipendentemente da cosa chiediamo a Claude. Questa è una garanzia rigida applicata dal lato GitHub, non una promessa sul comportamento dell'agente.

Copia e salva subito il token dopo la generazione, poi esportalo nella tua shell:

export GITHUB_PERSONAL_ACCESS_TOKEN="ghp_your_token_here"

Se sei già dentro una sessione di Claude Code, potresti essere tentato di usare il prefisso ! per eseguire direttamente il comando di export nella tua shell (ad esempio, ! export GITHUB_PERSONAL_ACCESS_TOKEN="..."). 

Tuttavia, poiché ! genera una subshell temporanea, la variabile sparirà appena il comando finisce e Claude non la vedrà.

Per impostare il token in modo sicuro senza incollarlo nel prompt del modello, hai due opzioni:

1. Digita /exit per uscire da Claude, esegui il comando di export nel tuo terminale normale e riavvia claude.
2. Oppure salva il token in un file .env locale nella tua directory di lavoro, che Claude Code legge automaticamente all'avvio.

Verifica che entrambi i prerequisiti siano pronti senza fare echo del token stesso:

docker info | head -3
echo "Token set: ${GITHUB_PERSONAL_ACCESS_TOKEN:+yes}"

Il secondo comando stampa Token set: yes se la variabile esiste e Token set: (niente dopo i due punti) se è vuota. 

È più sicuro che fare echo diretto del token perché non rischia di finire in chiaro nella cronologia della tua shell.

Passo 3: Registra il connettore GitHub con Claude Code

L'MCP server ufficiale di GitHub viene distribuito come immagine Docker. 

Lo registriamo con Claude Code usando claude mcp add:

claude mcp add github \
  -e GITHUB_PERSONAL_ACCESS_TOKEN=$GITHUB_PERSONAL_ACCESS_TOKEN \
  -- docker run -i --rm \
  -e GITHUB_PERSONAL_ACCESS_TOKEN \
  ghcr.io/github/github-mcp-server

Le due flag -e non sono un refuso::

• La prima -e (prima di --) imposta una variabile d'ambiente per il processo MCP che lancia Claude Code,
• La seconda -e (dentro gli argomenti di docker run) dice a Docker di inoltrare quella variabile nel container.

Se ne perdi una e il container parte con un token vuoto, fallirà l'autenticazione contro le API di GitHub.

Per verificare se il connettore è stato registrato con successo:

claude mcp list

Dovresti vedere:

github — docker run -i --rm -e GITHUB_PERSONAL_ACCESS_TOKEN ghcr.io/github/github-mcp-server —  Connected

Se vedi Failed to connect, le due cause più comuni sono Docker non in esecuzione o GITHUB_PERSONAL_ACCESS_TOKEN non esportato nella stessa shell in cui hai eseguito claude mcp add.

Passo 4: Verifica di base della connessione

Ora il nostro token GitHub è impostato. Creiamo quindi una directory di lavoro e apriamo la CLI di Claude Code:

mkdir demo && cd demo
claude

Il comando claude avvia una sessione interattiva nella directory corrente. 

Qualsiasi file che Claude scriverà durante il triage finirà qui. 

Poi fai una semplice domanda in sola lettura per confermare che il connettore viene usato:

Using the GitHub MCP connector, fetch the 5 most recently updated open issues in langchain-ai/langchain. Just list titles and numbers.

La prima volta che Claude Code usa uno strumento GitHub, chiederà l'approvazione. 

Approva gli strumenti in sola lettura come list_issues, get_issue, search_issues, ecc. 

Se Claude ripiega su curl contro le API pubbliche di GitHub invece di usare gli strumenti MCP, il connettore non è caricato. In tal caso esci dalla sessione e riavviala.

Un'esecuzione riuscita restituisce qualcosa del genere:

Quando vedi tornare veri numeri di issue tramite MCP, siamo pronti per eseguire il triage vero e proprio.

Passo 5: Genera un riepilogo del backlog

Il compito di riscaldamento è puro read-only. Ora vogliamo una mappa di cosa c'è nel tracker delle issue prima di fare altro.

Prompt:
Using the GitHub MCP connector, pull the 50 most recently updated open issues from langchain-ai/langchain. 
Read their titles, bodies, and labels. Group them by likely area — bugs, feature requests, documentation, questions, and "needs more info." 
For each group, give me a count and 3-5 representative issue numbers with a one-line reason. Save as backlog-summary.md in the current directory.

Claude Code recupera le issue tramite il connettore, le legge e scrive un file markdown che le raggruppa per area con numeri di issue rappresentativi. Questo file da solo è utile: un maintainer può sfogliarlo in 60 secondi e sapere che tipo di settimana lo aspetta.

Passo 6: Contrassegna i possibili duplicati

Il rilevamento dei duplicati è dove un agente si ripaga. 

Leggere 50 issue da cima a fondo e raggrupparle per problema sottostante è noioso per un umano, ma un modello può tenerle tutte in contesto e cogliere sovrapposizioni che una ricerca per keyword perderebbe.

Prompt:
From the same 50 issues you already pulled, identify clusters of likely duplicates: issues describing the same underlying problem, even if titles differ. For each cluster, output issue numbers, a one-sentence shared-problem description, and confidence (high/medium/low). Save as duplicate-candidates.md.

Ecco cosa ha prodotto effettivamente Claude nella mia esecuzione:

La parte più interessante di questo output sono i cluster dal 2 al 4. 

Un rilevatore ingenuo basato su keyword avrebbe chiuso tutti e quattro i cluster come duplicati. 

Claude si è rifiutato esplicitamente di chiamarli duplicati. 

Li ha contrassegnati come cluster di componenti con lo stesso sottosistema, cause radice distinte, e mi ha detto quali chiudere davvero (solo il Cluster 1) rispetto a quali triagiare congiuntamente ma lasciare aperti.

È il comportamento che vorresti da un triager umano scrupoloso, ed è esattamente il motivo per cui il pattern file-locali-poi-revisione vale lo sforzo extra. 

Se avessimo collegato tutto direttamente alle API di GitHub e chiuso automaticamente tutto ciò che Claude segnalava, avremmo chiuso tre bug reali.

Passo 7: Rivedi, poi decidi cosa pubblicare

Questo è il punto dell'approccio con file locali. 

Prima che qualcosa tocchi GitHub, controlla ogni file .md salvato da Claude e verifica se il raggruppamento corrisponde alla tua intuizione. 

I cluster ad alta confidenza sembrano davvero duplicati? Leggi 2-3 risposte di bozza e verifica se suonano come scritte da te.

Se vuoi davvero pubblicare i commenti o applicare le label, hai due opzioni:

• Manuale: puoi incollare tu stesso le bozze su GitHub. Per una sessione di triage una tantum sul repo di qualcun altro, va benissimo ed è spesso la scelta giusta.
• Autorizza le scritture su un repo che possiedi:  genera un PAT separato con scope repo, aggiungilo come voce di connettore distinta (es., github-write) e riesegui i prompt chiedendo a Claude di applicare label e pubblicare commenti. Claude Code chiederà l'approvazione per ogni strumento di scrittura la prima volta che viene usato.

La mossa di sicurezza chiave per il percorso di scrittura è tenere separati i token di lettura e scrittura. 

Conclusione

In questo tutorial ho mostrato come collegare Claude Code a GitHub via MCP e usarlo per fare il triage end-to-end di un vero repository open source. 

Invece di costruire un bot GitHub personalizzato o collegare webhook, il flusso di lavoro legge le issue tramite l'MCP server ufficiale di GitHub, scrive quattro artefatti di triage come file locali e ti permette di rivedere tutto prima di decidere cosa pubblicare.

La lezione più ampia è che i connettori trasformano Claude Code da agente di coding a strumento che può leggere i tuoi strumenti e preparare lavoro da rivedere. 

L'impostazione giusta di default è tenere quel lavoro in locale finché non l'hai visto, e una volta che ti fidi del pattern, puoi lasciare selettivamente che l'agente agisca dove il costo di un errore è basso.

Da qui, potresti estendere il progetto in vari modi:

• Aggiungi connettori con capacità di scrittura sui repo che possiedi così le label e i commenti vengono applicati automaticamente dopo la revisione,
• Inserisci in catena i connettori Linear o Slack per sincronizzare le decisioni di triage con il workflow del tuo team,
• Trasforma i prompt in un job CI schedulato che produce una PR di triage settimanale,
• Oppure generalizza i prompt sopra in un comando slash riutilizzabile di Claude Code che funziona su qualsiasi URL di repo.