Tutorial conector Claude Code: Triere repo-uri GitHub în 20 de minute

În acest tutorial, îți arăt cum să conectezi Claude Code la GitHub folosind un conector Claude (construit pe Model Context Protocol) și cum să-l folosești pentru a tria un repository open-source cap-coadă. 

Fluxul de lucru nu clonează nimic, nu are nevoie de un vector store și nu atinge niciun rând din repo-ul țintă. În schimb, Claude Code citește issue-urile prin conector și scrie artefacte în filesystemul tău local, pe care le verifici înainte de a decide ce (dacă e ceva) să postezi.

La finalul acestui tutorial, vei avea:

• O configurare funcțională Claude Code și GitHub MCP cu un token doar în citire,
• Câteva prompturi reutilizabile pe care le poți îndrepta către orice repo public,
• Un artefact de triere complet pentru langchain-ai/langchain cu care te poți compara.

Ce este conectorul Claude Code GitHub (MCP)?

Claude Code este agentul de programare în terminal al Anthropic. 

Din start, are deja acces la filesystem, shell și git. Conectorii Claude Code îl extind pentru a ajunge la context extern, precum issue-uri GitHub, tichete Linear, mesaje Slack, interogări Postgres și așa mai departe, la care terminalul singur nu poate ajunge.

Protocolul conectorului se numește MCP (Model Context Protocol), un standard deschis pentru expunerea de unelte și date către agenți LLM. 

Anthropic întreține un director de conectori gata de folosit și poți, de asemenea, să-ți scrii propriii conectori sau să te conectezi la servere MCP terțe.

Pentru acest tutorial, vom folosi serverul MCP GitHub oficial, care rulează local prin Docker. Câteva idei de bază din spatele configurării:

• Rulează ca un container Docker local, fără intermediar cloud, deci acreditările rămân pe mașina ta.
• Autentificat cu un Personal Access Token (PAT) GitHub standard, deci nu e nevoie de înregistrarea unei aplicații OAuth.
• Suportă permisiuni cu domeniu restrâns, precum un PAT fără scope, care oferă acces doar în citire la repo-urile publice, deci scrierile sunt imposibile la nivelul GitHub API.
• Este expus către Claude Code prin comanda claude mcp add, apoi uneltele sunt disponibile în fiecare sesiune.

Trierea open-source implică multă citire, multă judecată și e ieftin să greșești. 

Să citești 50 de issue-uri și să le grupezi e plictisitor pentru un om, dar se potrivește bine unui model care poate ține totul în context simultan. 

În plus, scriem mai întâi rezultatele ca fișiere locale; un grupaj prost sau un draft stângaci nu costă nimic și îl poți prinde la revizuire.

Tutorial conector Claude Code GitHub: construiește o triere pentru langchain-ai/langchain

În această secțiune, vom configura conectorul GitHub în Claude Code și vom rula patru prompturi de triere pe langchain-ai/langchain. Este un repo ML mare, cu un tracker de issue-uri într-adevăr dezordonat. La nivel înalt, iată ce vom construi:

• Conectează Claude Code la GitHub prin serverul MCP oficial care rulează în Docker,
• Folosește un PAT cu zero scope astfel încât conectorul să fie doar în citire din construcție,
• Rulează prompturi de triere care salvează rezultatele în fișiere locale,
• Revizuiește rezultatele, inclusiv câteva cazuri în care Claude a refuzat să grupeze issue-uri drept duplicate.

Hai să-l construim pas cu pas.

Pasul 1: Instalează prerechizitele pentru Claude Code și Docker

Înainte să configurăm conectorul, ai nevoie de trei lucruri:

• Claude Code: Îl poți instala din ghidul oficial de instalare al Anthropic,
• Docker Desktop: serverul MCP GitHub oficial rulează într-un container, deci Docker trebuie instalat și pornit,
• Un cont GitHub: este necesar pentru a genera PAT-ul în pasul următor.

După ce ai toate prerechizitele, verifică dacă Docker rulează:

docker info | head -5

Dacă Docker nu e instalat sau daemonul nu e pornit, vei vedea eroarea "Cannot connect to the Docker daemon". Pe macOS, pornește Docker Desktop cu:

open -a Docker

Docker Desktop are nevoie de 15-60 de secunde pentru a fi complet gata, iar docker info va continua să dea erori în acel interval. În loc să verifici manual, folosește un one-liner mic de așteptare care face poll până când daemonul pornește:

până când 

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

Când apare Docker ready, poți merge mai departe.

Pasul 2: Creează un token GitHub doar în citire

După ce Docker e configurat, mergi la github.com/settings/tokens și generează un token clasic nou.

Notă: Lasă toate scope-urile debifate. Un token fără scope poate totuși citi repository-uri publice prin GitHub API, ceea ce e tot ce are nevoie agentul nostru. Fără niciun scope selectat, tokenul nu poate scrie, modifica sau șterge nimic pe GitHub, indiferent ce îi cerem lui Claude. Aceasta este o garanție strictă aplicată de GitHub, nu o promisiune despre comportamentul agentului.

Copiază și salvează tokenul imediat după generare, apoi exportă-l în shell:

export GITHUB_PERSONAL_ACCESS_TOKEN="ghp_your_token_here"

Dacă ești deja într-o sesiune Claude Code, ai putea fi tentat să folosești prefixul ! pentru a rula comanda de export direct în shell (de ex., ! export GITHUB_PERSONAL_ACCESS_TOKEN="..."). 

Totuși, pentru că ! pornește un subshell temporar, variabila va dispărea imediat ce comanda se încheie și Claude nu o va vedea.

Pentru a seta tokenul în siguranță fără să-l lipești în promptul modelului, ai două opțiuni:

1. Tastează /exit ca să ieși din Claude, rulează comanda de export în terminalul tău normal și repornește claude.
2. Sau salvează tokenul într-un fișier local .env din directorul de lucru, pe care Claude Code îl citește automat la pornire.

Verifică faptul că ambele prerechizite sunt gata fără să afișezi tokenul în clar:

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

A doua comandă afișează Token set: yes dacă variabila există și Token set: (nimic după două puncte) dacă e goală. 

Este mai sigur decât să afișezi direct tokenul pentru că nu are cum să ajungă în istoricul shell-ului în clar.

Pasul 3: Înregistrează conectorul GitHub în Claude Code

Serverul MCP GitHub oficial este livrat ca o imagine Docker. 

Îl înregistrăm în Claude Code folosind 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

Cele două flaguri -e nu sunt o greșeală tipografică aici::

• Primul -e (înainte de --) setează o variabilă de mediu pentru procesul MCP pe care îl pornește Claude Code,
• Al doilea -e (în argumentele docker run) îi spune lui Docker să transmită acea variabilă în container.

Dacă omiți oricare dintre ele și containerul pornește cu un token gol, autentificarea la GitHub API va eșua.

Pentru a verifica dacă conectorul este înregistrat cu succes:

claude mcp list

Ar trebui să vezi:

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

Dacă vezi Failed to connect, cele mai frecvente două cauze sunt că Docker nu rulează sau că GITHUB_PERSONAL_ACCESS_TOKEN nu este exportat în același shell în care ai rulat claude mcp add.

Pasul 4: Verifică rapid conexiunea

Acum, tokenul nostru GitHub e setat. În continuare, creăm un director de lucru și deschidem CLI-ul Claude Code:

mkdir demo && cd demo
claude

Comanda claude pornește o sesiune interactivă în directorul curent. 

Orice fișiere pe care Claude le scrie în timpul trierii vor ajunge aici. 

Apoi pune o întrebare simplă, doar în citire, ca să confirmi că se folosește conectorul:

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

Prima dată când Claude Code folosește un tool GitHub, va cere aprobare. 

Aprobă uneltele doar în citire precum list_issues, get_issue, search_issues etc. 

Dacă Claude revine la curl către GitHub API public în loc să folosească uneltele MCP, conectorul nu e încărcat. Atunci ieși din sesiune și repornește-o.

O rulare reușită întoarce ceva de genul:

După ce vezi numere reale de issue-uri venind prin MCP, suntem gata să rulăm trierea propriu-zisă.

Pasul 5: Generează un rezumat de backlog

Taskul de încălzire e pur doar în citire. Acum vrem o hartă a conținutului din issue tracker înainte de orice altceva.

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 preia issue-urile prin conector, le citește și scrie un fișier markdown care le grupează pe arii cu numere de issue reprezentative. Doar acest fișier este util: un maintainer îl poate parcurge în 60 de secunde și știe la ce fel de săptămână se înhamă.

Pasul 6: Marchează candidații de duplicate

Detectarea duplicatelor este locul în care un agent își merită banii. 

Să citești 50 de issue-uri cap-coadă și să le grupezi după problema de bază e anevoios pentru un om, dar un model le poate ține pe toate în context și poate observa suprapuneri pe care o căutare după cuvinte-cheie le-ar rata.

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.

Iată ce a produs efectiv Claude în rularea mea:

Partea cea mai interesantă din acest output sunt clusterele 2 până la 4. 

Un detector naiv de duplicate bazat pe cuvinte-cheie ar fi închis toate cele patru clustere drept duplicate. 

Claude a refuzat explicit să le numească duplicate. 

Le-a marcat drept clustere de componente cu același subsistem, cauze-rădăcină distincte și mi-a spus pe care să le închid efectiv (doar clusterul 1) versus pe care să le triez împreună, dar să le las deschise.

Asta e fix comportamentul pe care l-ai vrea de la un triator uman atent, și exact motivul pentru care modelul „fișiere locale apoi revizuire” merită pasul în plus. 

Dacă am fi legat asta direct în API-ul GitHub și am fi închis automat tot ce a semnalat Claude, am fi închis trei buguri reale.

Pasul 7: Revizuiește, apoi decide ce să postezi

Acesta este întregul rost al modelului cu fișiere locale. 

Înainte ca ceva să atingă GitHub, verifică fiecare fișier .md salvat de Claude și vezi dacă gruparea îți confirmă intuiția. 

Arată clusterele cu încredere mare ca duplicate reale? Citește 2-3 răspunsuri draft și vezi dacă „sună ca tine”.

Dacă vrei să postezi efectiv comentariile sau să aplici etichetele, ai două opțiuni:

• Manual: Poți lipi drafturile în GitHub chiar tu. Pentru o sesiune unică de triere pe repo-ul altcuiva, e ok și adesea cea mai bună alegere.
• Autorizează scrieri pe un repo pe care îl deții:  Generează un PAT separat cu scope repo, adaugă-l ca intrare de conector distinctă (de ex., github-write) și rulează din nou prompturile cerându-i lui Claude să aplice etichete și să posteze comentarii. Claude Code va cere aprobare pentru fiecare unealtă de scriere la prima utilizare.

Mișcarea-cheie de siguranță pentru calea de scriere este să ții separate tokenurile de citire și de scriere. 

Concluzie

În acest tutorial, am demonstrat cum să conectezi Claude Code la GitHub prin MCP și să-l folosești pentru a tria cap-coadă un repository open-source real. 

În loc să construiești un bot GitHub personalizat sau să legi webhooks, fluxul de lucru citește issue-urile prin serverul MCP GitHub oficial, scrie patru artefacte de triere ca fișiere locale și îți permite să le revizuiești pe toate înainte de a decide ce să postezi.

Ideea mai largă este că conectorii transformă Claude Code dintr-un agent de programare într-o unealtă care îți poate citi uneltele și îți poate pregăti lucru pentru revizuire. 

Implicitul corect este să ții acel lucru local până îl vezi, iar odată ce ai încredere în model, poți lăsa selectiv agentul să acționeze acolo unde costul unei greșeli e mic.

De aici, ai putea extinde proiectul în mai multe moduri:

• Adaugă conectori cu permisiuni de scriere pe repo-urile tale, astfel încât etichetele și comentariile să fie aplicate automat după revizuire,
• Leagă conectori Linear sau Slack pentru a sincroniza deciziile de triere cu fluxul de lucru al echipei,
• Transformă prompturile într-un job CI programat care produce un PR săptămânal de triere,
• Sau generalizează prompturile de mai sus într-o comandă slash Claude Code reutilizabilă care funcționează pe orice URL de repo.