Tutorial del conector de Claude Code: prioriza repos de GitHub en 20 minutos

En este tutorial, te muestro cómo conectar Claude Code a GitHub usando un conector de Claude (basado en Model Context Protocol) y utilizarlo para priorizar un repositorio open source de principio a fin. 

El flujo de trabajo no clona nada, no necesita un almacén vectorial y no toca ni una línea del repo objetivo. En su lugar, Claude Code lee los issues a través del conector y escribe artefactos en tu sistema de archivos local para que los revises antes de decidir qué (si es que algo) publicar.

Al final de este tutorial tendrás:

• Una configuración funcional de Claude Code y GitHub MCP con un token de solo lectura,
• Algunos prompts reutilizables que puedes apuntar a cualquier repo público,
• Un artefacto de priorización completo para langchain-ai/langchain con el que comparar.

¿Qué es el conector de GitHub de Claude Code (MCP)?

Claude Code es el agente de programación en terminal de Anthropic. 

De serie, ya tiene acceso a tu sistema de archivos, shell y git. Los conectores de Claude Code lo amplían para llegar a contexto externo —como issues de GitHub, tickets de Linear, mensajes de Slack, consultas a Postgres, etc.— que la terminal por sí sola no puede alcanzar.

El protocolo del conector se llama MCP (Model Context Protocol), un estándar abierto para exponer herramientas y datos a agentes LLM. 

Anthropic mantiene un directorio de conectores listos para usar; también puedes crear los tuyos o conectarte a servidores MCP de terceros.

Para este tutorial, usaremos el servidor GitHub MCP oficial, que se ejecuta localmente con Docker. Algunas ideas clave de la configuración:

• Se ejecuta como un contenedor Docker local sin intermediarios en la nube, así que las credenciales se quedan en tu máquina.
• Se autentica con un GitHub Personal Access Token (PAT) estándar, sin necesidad de registrar una app OAuth.
• Admite permisos acotados, como un PAT sin ámbitos, que da acceso de solo lectura a repos públicos, haciendo imposible escribir a nivel de la API de GitHub.
• Se expone a Claude Code con el comando claude mcp add, y luego las herramientas están disponibles en cada sesión.

La priorización de open source requiere mucha lectura y criterio, y es barato equivocarse. 

Leer 50 issues y agruparlos es tedioso para una persona, pero es perfecto para un modelo que puede mantener todo el contexto a la vez. 

Además, primero escribimos los resultados como archivos locales; un agrupamiento malo o un borrador torpe no cuestan nada, y podrás detectarlo al revisar.

Tutorial del conector de GitHub en Claude Code: crea una priorización para langchain-ai/langchain

En esta sección, configuraremos el conector de GitHub en Claude Code y ejecutaremos cuatro prompts de priorización sobre langchain-ai/langchain. Es un repo de ML grande con un sistema de issues realmente caótico. A alto nivel, esto es lo que haremos:

• Conectar Claude Code a GitHub mediante el servidor MCP oficial ejecutándose en Docker,
• Usar un PAT sin ámbitos para que el conector sea de solo lectura por diseño,
• Ejecutar prompts de priorización que guarden resultados en archivos locales,
• Revisar las salidas, incluyendo casos en los que Claude se negó a agrupar issues como duplicados.

Vamos paso a paso.

Paso 1: Instala los requisitos previos para Claude Code y Docker

Antes de configurar el conector, necesitas tres cosas:

• Claude Code: puedes instalarlo desde la guía oficial de Anthropic,
• Docker Desktop: el servidor oficial de GitHub MCP se ejecuta en un contenedor, así que Docker debe estar instalado y en ejecución,
• Una cuenta de GitHub: la necesitarás para generar el PAT en el siguiente paso.

Cuando tengas todo listo, comprueba que Docker está funcionando:

docker info | head -5

Si Docker no está instalado o el daemon no está levantado, verás el error "Cannot connect to the Docker daemon". En macOS, inicia Docker Desktop con:

open -a Docker

Docker Desktop tarda entre 15 y 60 segundos en estar listo del todo, y docker info seguirá fallando durante ese intervalo. En lugar de comprobarlo a mano, usa este one-liner que hace polling hasta que el daemon esté arriba:

until 

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

Cuando imprima Docker ready, puedes continuar.

Paso 2: Crea un token de GitHub de solo lectura

Con Docker listo, ve a github.com/settings/tokens y genera un token clásico nuevo.

Nota: deja todos los ámbitos sin marcar. Un token sin ámbitos puede leer repos públicos vía la API de GitHub, que es todo lo que nuestro agente necesita. Sin ámbitos seleccionados, el token no puede escribir, modificar ni borrar nada en GitHub, hagas lo que le pidas a Claude. Es una garantía firme aplicada por GitHub, no una promesa sobre el comportamiento del agente.

Copia y guarda el token justo después de generarlo, y luego expórtalo en tu shell:

export GITHUB_PERSONAL_ACCESS_TOKEN="ghp_your_token_here"

Si ya estás dentro de una sesión de Claude Code, quizá te tiente usar el prefijo ! para ejecutar el comando de export directamente en tu shell (por ejemplo, ! export GITHUB_PERSONAL_ACCESS_TOKEN="..."). 

Sin embargo, como ! lanza un subshell temporal, la variable desaparecerá en cuanto termine el comando y Claude no la verá.

Para establecer el token de forma segura sin pegarlo en el prompt del modelo, tienes dos opciones:

1. Escribe /exit para salir de Claude, ejecuta el comando de export en tu terminal normal y reinicia claude.
2. O guarda el token en un archivo .env local en tu directorio de trabajo; Claude Code lo leerá automáticamente al iniciar.

Comprueba que ambos requisitos están listos sin hacer echo del token en sí:

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

El segundo comando imprime Token set: yes si la variable existe y Token set: (nada tras los dos puntos) si está vacía. 

Esto es más seguro que hacer echo del token directamente porque evitas que termine en el historial de tu shell en texto plano.

Paso 3: Registra el conector de GitHub en Claude Code

El servidor oficial de GitHub MCP se distribuye como una imagen de Docker. 

Lo registramos en Claude Code con 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

Los dos flags -e no son un error tipográfico:

• El primer -e (antes de --) establece una variable de entorno para el proceso MCP que lanza Claude Code,
• El segundo -e (dentro de los argumentos de docker run) indica a Docker que reenvíe esa variable al contenedor.

Si omites cualquiera y el contenedor arranca con un token vacío, fallará la autenticación contra la API de GitHub.

Para verificar que el conector se registró correctamente:

claude mcp list

Deberías ver:

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

Si ves Failed to connect, las dos causas más comunes son que Docker no esté en ejecución o que GITHUB_PERSONAL_ACCESS_TOKEN no esté exportado en el mismo shell donde ejecutaste claude mcp add.

Paso 4: Verificación básica de la conexión

Ahora que el token de GitHub está configurado, crea un directorio de trabajo y abre la CLI de Claude Code:

mkdir demo && cd demo
claude

El comando claude inicia una sesión interactiva en el directorio actual. 

Cualquier archivo que Claude escriba durante la priorización se guardará aquí. 

Luego, haz una consulta simple de solo lectura para confirmar que se está usando el conector:

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

La primera vez que Claude Code use una herramienta de GitHub, pedirá tu aprobación. 

Aprueba herramientas de solo lectura como list_issues, get_issue, search_issues, etc. 

Si Claude recurre a curl contra la API pública de GitHub en lugar de usar herramientas MCP, el conector no está cargado. Sal de la sesión y reiníciala.

Una ejecución correcta devuelve algo como:

Cuando veas números de issues reales llegando por MCP, estamos listos para la priorización de verdad.

Paso 5: Genera un resumen del backlog

La tarea de calentamiento es de solo lectura. Queremos un mapa de lo que hay en el tracker antes de hacer nada más.

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 obtiene los issues vía el conector, los lee y escribe un archivo markdown agrupándolos por área con números representativos. Este archivo ya es útil: cualquier maintainer puede ojearlo en 60 segundos y saber qué semana le espera.

Paso 6: Señala candidatos a duplicados

La detección de duplicados es donde un agente demuestra su valor. 

Leer 50 issues de principio a fin y agrupar por problema subyacente es pesado para una persona, pero un modelo puede mantenerlos todos en contexto y detectar solapamientos que una búsqueda por palabras clave pasaría por alto.

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.

Esto es lo que produjo Claude en mi ejecución:

Lo más interesante del resultado son los clusters 2 al 4. 

Un detector ingenuo basado en keywords habría cerrado los cuatro como duplicados. 

Claude se negó explícitamente a llamarlos duplicados. 

Los marcó como clusters de componentes dentro del mismo subsistema, con causas raíz distintas, y me indicó cuáles cerrar de verdad (solo el Cluster 1) y cuáles triagear juntos pero mantener abiertos.

Es el comportamiento que esperas de una persona cuidadosa priorizando issues, y justo por eso el patrón de archivos locales + revisión merece la pena. 

Si hubiéramos conectado esto directamente a la API de GitHub y cerrado automáticamente todo lo que marcó Claude, habríamos cerrado tres bugs reales.

Paso 7: Revisa y decide qué publicar

Este es el sentido del patrón de archivos locales. 

Antes de que nada toque GitHub, revisa cada archivo .md que guardó Claude y comprueba si el agrupamiento encaja con tu intuición. 

¿Los clusters de alta confianza parecen realmente duplicados? Lee 2-3 respuestas de borrador y comprueba si suenan como tú.

Si quieres publicar comentarios o aplicar etiquetas, tienes dos opciones:

• Manual: puedes pegar los borradores en GitHub tú mismo. Para una sesión puntual de priorización en el repo de otra persona, está bien y suele ser lo correcto.
• Autorizar escrituras en un repo tuyo: genera un PAT aparte con scope repo, añádelo como un conector distinto (por ejemplo, github-write) y vuelve a ejecutar los prompts pidiéndole a Claude que aplique etiquetas y publique comentarios. Claude Code pedirá aprobación la primera vez que se use cada herramienta de escritura.

La clave de seguridad en la vía de escritura es mantener separados los tokens de lectura y de escritura. 

Conclusión

En este tutorial te mostré cómo conectar Claude Code a GitHub vía MCP y usarlo para priorizar un repositorio open source real de principio a fin. 

En lugar de crear un bot de GitHub a medida o configurar webhooks, el flujo lee los issues a través del servidor oficial de GitHub MCP, escribe cuatro artefactos de priorización como archivos locales y te permite revisarlo todo antes de decidir qué publicar.

La idea de fondo es que los conectores convierten a Claude Code de un agente de programación en una herramienta que puede leer tus herramientas y prepararte trabajo para revisar. 

Lo sensato por defecto es mantener ese trabajo en local hasta que lo hayas visto y, cuando confíes en el patrón, dejar que el agente actúe selectivamente donde el coste de un error sea bajo.

A partir de aquí, puedes ampliar el proyecto de varias formas:

• Añadir conectores con permisos de escritura en repos que te pertenezcan para aplicar etiquetas y comentarios automáticamente tras la revisión,
• Encadenar conectores de Linear o Slack para sincronizar las decisiones de triage con el flujo de trabajo de tu equipo,
• Convertir los prompts en un job de CI programado que genere un PR semanal de priorización,
• O generalizar los prompts anteriores en un comando slash reutilizable de Claude Code que funcione con cualquier URL de repo.