Hablar con Control Center desde una PR de GitHub

Esta guía te muestra cómo trabajar con Control Center sin salir de GitHub: solicita una revisión con IA desde la página de la PR, hazle al bot una pregunta en un comentario y mantén la conversación en sus hilos de revisión.

El bot es la GitHub App del propio servidor —la misma que ya inicia la sesión de las personas y ejecuta trabajo en segundo plano. No se registra nada nuevo y nada tiene que ser accesible desde internet: el servidor descubre lo que se dijo en GitHub mediante sondeo, así que una computadora detrás de NAT se comporta exactamente igual que una implementación pública.

Requisitos previos

• El servidor tiene su GitHub App registrada e instalada, con Pull requests: read and write (para comentarios, hilos y reacciones) e Issues: read (para la búsqueda de comentarios). Ambas ya figuran en la lista de permisos de esa guía
• El repositorio está vinculado a un espacio de trabajo en Control Center
• Ni URL de webhook, ni túnel, ni callback: no hay nada que configurar del lado de la red

Averigua el nombre de tu bot

El login del bot es <appslug>[bot], donde appslug es el nombre que le diste a la app cuando la registraste.

1. Ve a Ajustes → Servidor → Inicio de sesión único y baja hasta la tarjeta Aplicaciones de proveedor
2. Abre el bloque GitHub y pulsa Probar
3. Copia Login del bot cuando se rellene. Si aún muestra el aviso de vacío, el login siempre es <appslug>[bot]: escribe eso, o el @appslug corto

GitHub no ofrece cuentas de app en su autocompletado de @, así que el login hay que escribirlo: por eso la tarjeta de ajustes permite copiarlo con un solo clic. El sufijo [bot] es opcional: @myapp y @myapp[bot] dirigen ambos al bot.

Elige un nombre de app distintivo

La forma corta se compara como texto. Si un usuario humano de GitHub comparte por casualidad el slug de tu app, mencionar a ese usuario con la forma corta también llega al bot. La forma completa @myapp[bot] siempre es inequívoca.

Solicita una revisión desde GitHub

Dos vías, y ambas inician el mismo pipeline predefinido pr_review que inicia el botón Ask AI:

• Agrega la etiqueta ai-review a la PR. Es lo más parecido que ofrece GitHub a asignar el bot como revisor: las cuentas de app no pueden ocupar el lugar reservado al revisor solicitado. No hay ningún comentario al que reaccionar, así que no se publica nada en GitHub; la revisión empieza en Control Center
• Comenta @myapp review (o solo @myapp) en la conversación de la PR. El bot reacciona con 👀 y después responde cuando la revisión ya empezó (o que ya hay una en curso)

Los revisores trabajan en el espacio de revisión de la PR; lee y publica los hallazgos como en Usar revisión impulsada por IA. Publicar de vuelta en GitHub sigue siendo una decisión que tomas en Control Center: iniciar una revisión desde GitHub no publica nada en GitHub por sí solo.

La etiqueta se dispara una vez por PR: agregarla es la petición, y no se rearma cuando se quita y se vuelve a agregar. Para ejecutar una revisión otra vez —tras un push, por ejemplo— menciona al bot.

Haz una pregunta

Comenta en la conversación de la PR:

@myapp why does the flaky test in runner_test.dart fail on CI but not locally?

Qué ocurre, en orden:

1. El bot reacciona con 👀 para que sepas que el comentario fue visto
2. La pregunta se publica en el espacio de revisión de la PR como tú: la misma atribución que si la hubieras escrito en Control Center
3. Un agente responde en el espacio, y la respuesta se publica de vuelta en la PR como un comentario que te @menciona

Una pregunta en una PR que todavía no tiene revisión despierta al agente CEO del espacio de trabajo; una vez que se ejecuta una revisión, responde el agente que habló al final, así que los seguimientos llegan a quien tiene el contexto.

Da seguimiento en un hilo de revisión

Responde dentro de un hilo de revisión en línea del que el bot forme parte: un comentario de diff que dejó, o una respuesta que publicó en ese hilo. No se necesita ninguna mención; el hilo es el direccionamiento:

> @myapp the retry loop looks O(n²) to me

what would the complexity be with the bounded queue instead?

Los turnos múltiples funcionan igual: cada respuesta es otra pregunta en la misma conversación, con el espacio de revisión como contexto, y la respuesta vuelve en el hilo.

Un seguimiento en la cronología de la conversación de la PR es un comentario nuevo de nivel superior, así que aún necesita una @mención.

Con quién habla el bot

Un comentario de GitHub llega con poco más que un login, así que el bot resuelve al autor antes de hacer nada:

• Tu cuenta de GitHub debe estar vinculada a tu identidad en Control Center: inicia sesión con GitHub, o pega un token, desde Ajustes → Espacio de trabajo → Perfil e identidad → Alojamiento de código
• Debes ser miembro con un rol de escritura (member, admin u owner) en el espacio de trabajo que vincula el repositorio

Cualquier otra persona recibe una sola respuesta cortés que explica qué falta —un login desconocido (no vinculado, o vinculado pero que no es miembro aquí) y un rol de solo lectura son los dos casos—, y sus palabras nunca entran en el espacio de trabajo. La etiqueta ai-review no pasa por este filtro: no tiene autor, así que inicia la revisión en el espacio de trabajo que ya tiene vinculado el repositorio.

Qué esperar

Cosa	Comportamiento
Acuse de recibo	👀 en un comentario en alrededor de un minuto: el intervalo de barrido. La etiqueta ai-review no tiene ningún comentario al que reaccionar
Respuestas	Se publican como el bot (la app), en la misma conversación en la que se hizo la pregunta
Atribución en el espacio	La pregunta es tuya; el agente se ejecuta en tu nombre, bajo la configuración de autonomía del espacio
Revisiones	Los hallazgos llegan al espacio de revisión; publicar en GitHub es manual

La latencia de alrededor de un minuto es el precio de no necesitar ningún acceso de red entrante. Nada del barrido es urgente y no se pierde nada mientras el servidor está sin conexión: un comentario que llega durante una caída se recoge en el siguiente barrido.

Solución de problemas

No ocurre nada con un comentario que menciona al bot.

• ¿Está la app instalada en la cuenta propietaria del repositorio, y el repositorio vinculado a un espacio de trabajo? Un repositorio sin vincular se omite antes de que se registre nada, así que vincularlo después igualmente funciona
• ¿Está vinculada tu cuenta de GitHub y eres miembro con un rol de escritura? Busca en la PR la respuesta de rechazo del bot: ahí se indica cuál de las dos cosas falta
• ¿Y aún así nada? El registro del servidor nombra el barrido y la PR cuando algo falla; busca pr_conversation: (el sondeo) y github_pr_conversation: (el puente)

La etiqueta no inicia una revisión.

Se dispara una vez por PR. Si ya se ejecutó una revisión, o la etiqueta se agregó antes de que el servidor viera la PR (el primer barrido registra lo pendiente en silencio en lugar de lanzarlo todo de golpe), mejor menciona al bot: @myapp review siempre inicia una, a menos que ya haya una revisión en curso.

La respuesta del bot nunca llegó a GitHub.

La respuesta en sí nunca se pierde: está en el espacio de revisión de la PR, en Control Center. Un fallo al publicar (GitHub caído, permisos cambiados) se registra y la respuesta no se reintenta; vuelve a preguntar en el hilo si te importa.

Guías relacionadas

• Crear la GitHub App: el registro del que nace el bot
• Usar revisión impulsada por IA: leer los hallazgos que produce una revisión iniciada por mención
• Configurar la integración de GitHub: vincular tu propia cuenta de GitHub, que es por lo que te resuelve el bot
• Usar espacios: la sala en la que aterriza todo esto