Lleva las decisiones de tu reunión de triaje de bugs a GitHub Issues automáticamente con SuperIntern MCP
Imagina el final de tu reunión semanal de triaje de bugs.
Acabáis de pasar 30 minutos tomando decisiones con cuidado: "este es P1, va al próximo milestone", "a este ponle la etiqueta de pendiente de reproducir", "ese ya debería estar arreglado, ciérralo." La reunión termina y ninguna de esas decisiones existe todavía en ningún sitio. Alguien abre GitHub con el acta en la otra pantalla, busca cada issue, cambia etiquetas, asigna milestones y responsables y, si queda tiempo (nunca queda), escribe un comentario con el porqué. Un día de 20 issues, solo ese trabajo de sincronización se come 30 minutos. Y si se pospone, el tracker y las decisiones reales del equipo se desalinean durante días, hasta que el siguiente triaje empieza con un "espera, ¿esto no lo habíamos puesto en P1?"
En esta guía conectamos el MCP de SuperIntern y el servidor MCP de GitHub a Claude, para que aplicar las decisiones del triaje a los issues de GitHub sea un único prompt, con ejemplos reales que puedes copiar.
⚠️ Este artículo se ha elaborado de forma independiente a partir de información pública y comentarios de usuarios disponibles en agosto de 2026.
Índice
- El objetivo de hoy: antes / después
- Cómo funciona: tres roles
- Configuración
- Demo 1: aplicar las decisiones del triaje en una sola pasada
- Demo 2: registrar bugs reportados de palabra, con comprobación de duplicados
- Demo 3: auditoría semanal de la deriva entre reuniones y tracker
- Consejos para el día a día
- Más allá de GitHub: el mismo patrón en otros sitios
- Preguntas frecuentes
El objetivo de hoy: antes / después
Antes: tras el triaje, alguien alterna entre el acta y GitHub, abriendo los issues uno a uno para aplicar a mano etiquetas, milestones y responsables. No hay tiempo de dejar por escrito el razonamiento, así que tres semanas después nadie recuerda por qué un issue pasó a P1.
Después: al acabar la reunión, se lo pides a Claude una sola vez: "aplica las decisiones del triaje de hoy a GitHub." Claude lee las decisiones del acta, localiza cada issue, actualiza etiquetas, milestones y responsables, y deja en cada issue un comentario con el razonamiento y la reunión de origen.
Para situarnos: SuperIntern es una app de escritorio botless (ningún bot entra en tus reuniones) que captura transcripciones y actas con IA automáticamente. En el triaje solo tienes que discutir sobre bugs como siempre. Las decisiones se van acumulando solas como datos de reunión, así que lo único que queda por automatizar es el volcado a GitHub.
Cómo funciona: tres roles
Tres participantes hacen posible este flujo.
| Rol | Quién | Qué hace |
|---|---|---|
| Proporciona los datos de reunión | SuperIntern MCP | Sirve transcripciones, transcripción en vivo, actas con IA y notas de reunión, en solo lectura |
| Criterio y redacción | Claude (el cliente de IA) | Lee los datos, extrae las decisiones, las asocia a issues y redacta los cambios |
| Destino de la acción | GitHub (MCP) | Busca issues, actualiza etiquetas y milestones, asigna personas, comenta y crea issues nuevos |
MCP (Model Context Protocol) es un estándar abierto para conectar asistentes de IA a herramientas externas de forma segura. El MCP de SuperIntern sirve tus datos de reunión al cliente de IA en solo lectura, mientras que el servidor MCP oficial de GitHub se encarga de buscar, crear y actualizar issues. Es decir, quien toca tus issues de GitHub es Claude, no SuperIntern. Tus datos de SuperIntern no pueden modificarse nunca vía MCP, la IA solo ve las reuniones a las que tú tienes acceso, y todas las escrituras ocurren en el lado de GitHub. Puedes probarlo sin ningún riesgo para tus actas.
Configuración
Necesitas exactamente dos conexiones. El lado de SuperIntern no requiere clave de API; basta un inicio de sesión en el navegador. Para GitHub, según tu cliente, inicias sesión con OAuth en el navegador o usas un Personal Access Token.
1. Conecta SuperIntern MCP a Claude
En Claude, ve a Ajustes, luego Conectores, elige "Añadir conector personalizado" y registra la URL de conexión.
https://mcp.app.super-intern.com/mcp
Se abre la pantalla de inicio de sesión de SuperIntern; entra con tu cuenta, autoriza y listo. Los requisitos de plan (Plus o superior en espacios personales, activación por un administrador en Enterprise) y los pasos para Claude Code, Cursor y otros clientes están en nuestra guía de configuración de MCP.
2. Conecta el servidor MCP de GitHub a Claude
GitHub ofrece un servidor MCP oficial. Ten en cuenta que su servidor remoto (https://api.githubcopilot.com/mcp/) depende de OAuth a través de una GitHub App registrada, algo que el flujo "Añadir conector personalizado" de Claude no admite por ahora. Conéctate por una de las vías de la guía oficial de instalación:
- Claude Desktop: añade el servidor MCP local de GitHub (Docker) a
claude_desktop_config.json. En el primer uso se abre un inicio de sesión de GitHub en el navegador (OAuth), así que no hay que crear ningún token - Claude Code: conéctate al servidor remoto con un Personal Access Token:
claude mcp add-json github '{"type":"http","url":"https://api.githubcopilot.com/mcp","headers":{"Authorization":"Bearer YOUR_GITHUB_PAT"}}'
El JSON de configuración exacto para Claude Desktop y los pasos para Cursor y otros clientes están en la guía oficial de instalación.
¿No estás seguro de que ambas conexiones funcionen? Pregunta primero esto:
Muéstrame mis 3 reuniones más recientes de SuperIntern y 3 issues abiertos de nanohuman/app
Si te devuelve ambas cosas, ya está todo listo.
Demo 1: aplicar las decisiones del triaje en una sola pasada
El uso más frecuente es el volcado en bloque justo después del triaje. Las decisiones de triaje suelen cambiar el estado de issues existentes, así que la clave es identificar bien cada issue y actualizarlo, no crear otros nuevos.
Obtén el acta con IA de la reunión "Triaje de bugs" de hoy y extrae la decisión sobre cada issue.
Localiza los issues correspondientes en nanohuman/app por número o descripción.
Aplica las etiquetas de prioridad y los milestones acordados y asigna a los responsables decididos.
Añade en cada issue un comentario con el razonamiento y el nombre de la reunión de origen.
Para los issues que decidimos cerrar, comenta primero el motivo y ciérralos después.
Claude lee el acta, busca en GitHub y responde algo así:
He actualizado 8 issues.\
- #482 "Los resultados de búsqueda se reinician al cambiar de pestaña": añadidos P1 y milestone v0.14, asignado a Sara. Priorizado porque tres cuentas de clientes lo han reproducido\
- #475 "Caracteres corruptos en la exportación CSV": añadido P2, a la espera de pasos de reproducción\
- #468 "Tooltip desalineado en ajustes": añadidos P3 y good first issue\
- #441 "Maquetación rota en el dashboard antiguo": confirmado como corregido en v0.13, comentado el motivo y cerrado
Cada issue tiene ahora un comentario citando como origen la "reunión de triaje de bugs (14 ago)".
El detalle importante: no son solo etiquetas y milestones, el razonamiento queda como comentario. Abres cualquier issue y puedes rastrear cuándo y por qué recibió su prioridad. Tres semanas después, nadie tiene que preguntar "¿por qué esto es P1?" Y como las actas con IA de SuperIntern estructuran bien las decisiones, la extracción es estable.
Demo 2: registrar bugs reportados de palabra, con comprobación de duplicados
Los triajes y las dailies están llenos de reportes de bugs de palabra: "por cierto, la pantalla de exportación hace una cosa rara." Si nadie crea el issue en el momento, el reporte queda enterrado en el acta y muere ahí.
Obtén la transcripción de la "Daily de ingeniería" de hoy y lista cada mención verbal de un bug o defecto.
Contrástalas con los issues existentes de nanohuman/app.
Donde ya exista un issue, añade como comentario el contexto nuevo de la reunión.
Solo para los reportes que no existan en ningún sitio, crea issues nuevos con pasos de reproducción.
Redacta títulos que describan el síntoma e indica en el cuerpo quién lo reportó y en qué reunión.
Fíjate en que este prompt usa la transcripción, no el acta. Los reportes verbales suelen caerse del resumen, pero la transcripción conserva incluso el comentario de pasada. Pedir "pasos de reproducción" hace que Claude convierta el flujo que la persona describió de palabra en una lista de reproducción real, y te ahorra tener que preguntarle después.
Demo 3: auditoría semanal de la deriva entre reuniones y tracker
En la reunión se dijo "lo arreglamos", pero el issue no se ha movido. O un issue que todos acordaron cerrar sigue abierto. Una vez a la semana, detecta esta deriva entre lo acordado en reuniones y lo que dice GitHub. Consultar varias reuniones a la vez es justo el punto fuerte de MCP.
Obtén todas las reuniones de esta semana del proyecto "Equipo de producto" y localiza cada punto
donde se mencionó un issue de GitHub o se tomó una decisión sobre uno.
Compara con el estado actual de los issues de nanohuman/app.
Muéstrame una tabla de los issues cuya decisión de reunión aún no está reflejada,
con reunión, decisión y estado actual. No apliques nada todavía.
Este prompt pide a propósito primero una tabla, sin cambios. La auditoría semanal lanza una red amplia y puede pescar comentarios casuales; revisar la tabla y responder "aplica estos tres" es el doble paso seguro. Ejecutado cada viernes, tu tracker se mantiene como un espejo honesto de lo que el equipo decidió de verdad.
Consejos para el día a día
Nombra el repositorio explícitamente. Poner "en nanohuman/app" en el prompt evita confusiones en organizaciones con muchos repositorios. Deja tus repos habituales fijados en un prompt guardado.
Empieza con un simulacro. Las primeras sesiones, añade "muéstrame los cambios previstos antes de aplicarlos." Cuando hayas visto lo bien que Claude asocia expresiones de la reunión ("aquel bug del buscador") con issues reales, pasa a la aplicación directa.
Decid los números de issue en voz alta. Los equipos que dicen "#482" durante el triaje meten esos números en la transcripción, y la asociación de Claude se vuelve casi perfecta. Si compartís pantalla con la lista de issues durante el triaje, probablemente ya lo hacéis.
Fija tu esquema de etiquetas en el prompt. "Prioridad con P1/P2/P3 y tipo con bug/enhancement" evita que se creen por accidente etiquetas que no existen en vuestro esquema.
Mejora los nombres propios en el lado de SuperIntern. Cuanto mejor se transcriban los nombres de funciones y pantallas, mejor será la asociación con issues. Registrar los nombres frecuentes de funciones y compañeros en el diccionario personalizado de SuperIntern merece esos dos minutos.
Solo se escribe en GitHub. Tus datos de SuperIntern nunca se modifican vía MCP. Si un volcado sale mal, se corrige en GitHub; el acta original sigue siendo la fuente de verdad. Además, GitHub guarda su propio historial de cambios en cada issue, lo que tranquiliza de cara a auditorías.
Más allá de GitHub: el mismo patrón en otros sitios
El patrón "SuperIntern MCP sirve los datos, Claude decide, otra herramienta recibe la acción" va mucho más allá de GitHub.
- Otros trackers: los equipos que usan Linear pueden seguir casi el mismo flujo en nuestra guía práctica de Linear
- Avisos en Slack: comparte el resumen del triaje directamente en el canal de desarrollo. Mira la guía práctica de Slack
- Hasta el código: conecta SuperIntern MCP a Claude Code y pasa de "aquel P1 del triaje" a un fix que conoce la discusión de la reunión. Nuestro artículo de spec-to-code lo muestra
Seguimos cubriendo estas combinaciones una a una, siempre con prompts reales.
Preguntas frecuentes
P. ¿SuperIntern MCP está disponible en el plan gratuito?
R. No. Los espacios de trabajo personales necesitan el plan Plus o superior. Los espacios con plan Team pueden usarlo directamente, y en Enterprise un administrador debe activar antes el "acceso MCP" en los ajustes del espacio.
P. ¿SuperIntern escribe directamente en mis issues de GitHub?
R. No. Todas las actualizaciones, creaciones y comentarios de issues los realiza Claude a través del servidor MCP de GitHub. SuperIntern MCP solo sirve datos de reunión en solo lectura; SuperIntern nunca escribe en herramientas externas.
P. ¿Puede la IA modificar mis actas o transcripciones?
R. No. Todas las herramientas de SuperIntern MCP son de solo lectura; no existen operaciones de creación, edición ni borrado. Las escrituras ocurren únicamente en el lado de GitHub.
P. ¿Funciona con repositorios privados?
R. Sí. El servidor MCP de GitHub actúa con los permisos de las credenciales con las que te conectaste (tu inicio de sesión OAuth o tu Personal Access Token), así que cubre exactamente los repositorios a los que esas credenciales tienen acceso, y ninguno más.
P. ¿Y si aplica cambios equivocados en masa?
R. Usa el hábito del simulacro de los consejos: "muéstrame los cambios previstos antes de aplicarlos" te da un punto de control humano. Incluso si algo sale mal, el historial de cada issue en GitHub permite revertirlo, y tus datos de SuperIntern no se ven afectados.
P. ¿Puedo usar un cliente de IA distinto de Claude?
R. Tanto SuperIntern MCP como el servidor MCP de GitHub funcionan con clientes compatibles con MCP como Claude Code, Codex y Cursor. Cualquier cliente que pueda conectarse a ambos ejecutará los prompts de este artículo casi sin cambios.
El valor de una reunión de triaje está en decidir, no en transcribir después las decisiones a GitHub. Quédate con las decisiones; delega la transcripción.