Hablar con Control Center desde una PR de GitHub

Esta guía muestra cómo trabajar con Control Center sin salir de GitHub: solicita una revisión con IA desde la página de la PR, haz 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 dice en GitHub mediante sondeo, así que un portátil detrás de NAT se comporta exactamente igual que un despliegue público.

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 en el 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 al registrarla.

1. Ve a Ajustes → Servidor → Inicio de sesión único y baja hasta la tarjeta Aplicaciones de proveedor
2. Abre el bloque GitHub y haz clic en Probar
3. Copia Login del bot cuando se rellene. Si aún muestra la pista de vacío, el login es siempre <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] nunca es ambigua.

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:

• Añade 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 hueco nativo del revisor solicitado. No hay 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 ha empezado (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 con 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: añadirla es la petición, y no se rearma cuando se quita y se vuelve a añadir. 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 se ha visto el comentario
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 sin revisión todavía despierta al agente CEO del espacio de trabajo; una vez que se ha ejecutado una revisión, responde el agente que habló en último lugar, así que los seguimientos recaen en quien tiene el contexto.

Sigue la conversación 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 hace falta 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 sigue necesitando 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 única 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 torno a un minuto: el intervalo de barrido. La etiqueta ai-review no tiene comentario al que reaccionar
Respuestas	Publicadas 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á desconectado: 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 no vinculado se omite antes de registrar nada, así que vincularlo después sigue funcionando
• ¿Está vinculada tu cuenta de GitHub y eres miembro con un rol de escritura? Busca en la PR la respuesta de rechazo del bot: en ella se indica cuál de las dos cosas falta
• ¿Aun 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 añadió antes de que el servidor viera la PR (el primer barrido registra lo pendiente en silencio en lugar de lanzarlo todo de golpe), 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 con IA: leer los hallazgos que produce una revisión iniciada por mención
• Configurar la integración con 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