Usar revisión impulsada por IA

Esta guía te muestra cómo hacer que los agentes revisores revisen una pull request y cómo publicar el resultado en GitHub.

Iniciar una revisión con IA

Abre la PR y ve a su pestaña Resumen
Abre el menú de desbordamiento ⋯ de la fila de acciones y elige Ask AI

El elemento solo aparece mientras la PR está abierta —es una acción previa a la fusión—. El mismo botón se ofrece como Ask AI en el estado vacío de la pestaña Revisar, antes de que exista ninguna revisión.

Control Center inicia el pipeline predefinido pr_review y abre la pestaña Revisar de la PR para que puedas verlo en marcha. El pipeline:

Abre el espacio de revisión propio de la PR, cuyo worktree aislado tiene la PR en checkout en su head
Despliega los revisores correspondientes al nivel de revisión del espacio de trabajo —tres de forma predeterminada (los agentes predefinidos qa, architect e engineer, en paralelo)—. No hay detección de lenguaje ni de dominio
Hace que el agente líder (CEO) consolide sus hallazgos en un recorrido guiado
Finaliza: ordena los hallazgos en grupos de consenso y calcula el veredicto. Cuando la asociación alcanza awaiting approval, aparece Publicar en GitHub en la pestaña Revisar

Hasta dónde llega la revisión lo determina el nivel de revisión del espacio de trabajo —light (un revisor), balanced (tres, el valor predeterminado) o thorough (los cinco, lo que agrega a los especialistas en seguridad y rendimiento)—, que se configura en Ajustes → Espacio de trabajo → General, en la tarjeta Política del espacio de trabajo. Un nivel más ligero registra exactamente los mismos hallazgos; solo que destaca menos de ellos.

Todos los revisores publican en el único espacio de revisión de la PR, que es lo que hace que sus hallazgos sean comparables. Consulta Revisión con IA para ver cómo encajan las piezas.

pr_review solo incluye un disparador manual. Para que se ejecute con cada PR publicada, agrega tú mismo un disparador; consulta Despachar agentes revisores. También puedes iniciar una desde el propio GitHub, sin necesidad de un disparador de pipeline: menciona al bot del servidor en la PR o agrega la etiqueta ai-review; consulta Hablar con Control Center desde una PR de GitHub.

Si un aviso indica que ya se está ejecutando una revisión para esta pull request, es que hay una en curso; quédate en la pestaña Revisar o abre Pipelines para encontrarla.

Leer los hallazgos

Los revisores registran los hallazgos como nodos de revisión en el espacio de revisión. Cada uno incluye:

Campo	Descripción
Tipo	`bug`, `suggestion`, `recommendation`, `question` o `ticket`
Prioridad	P0 (crítico) → P3 (detalle menor)
Categoría	`security`, `stability`, `data_integrity`, `correctness`, `performance` o `maintainability`
Archivo y línea	Dónde está anclado el hallazgo
Código original	El código al que se refiere el hallazgo
Código sugerido	La corrección propuesta
Confianza	Cuán seguro está el revisor
Estado	`open` → `consensus-ready` → `resolved` o `dismissed`

Un hallazgo solo alcanza consensus-ready cuando lo confirma un revisor par. Un agente no puede confirmar su propio hallazgo, así que la opinión de un solo revisor nunca asciende por sí sola.

La pestaña Revisar muestra la lista de hallazgos, filtrable por tipo y estado, con un interruptor para los hallazgos descartados, junto al artefacto que publicó el agente consolidador. La vista determinista —cohortes, el panel multieje, los diffs de contrato y visuales— se calcula del lado del servidor, pero no tiene ninguna superficie en la app; consulta Cómputo de revisión para saber qué produce esa pasada.

Consultar el panel de desacuerdos

Cuando dos revisores anclan hallazgos al mismo archivo y la misma línea, pero los valoran de forma muy distinta —prioridades separadas por dos o más niveles, o uno lo llama bug mientras que el otro lo llama suggestion—, aparece un panel de desacuerdos encima de la lista de hallazgos. Léelos primero: son los puntos en los que divergen las opiniones de los revisores y donde más vale tu criterio.

Leer el veredicto

Cuando el agente líder finaliza, calcula un veredicto:

Veredicto	Significado
Ship	No se encontró nada que bloquee
Hold	Problemas que deberían resolverse antes de fusionar
Block	Problemas críticos que deben corregirse

El veredicto incluye una puntuación de confianza agregada y recuentos de hallazgos por prioridad.

Los ejes de revisión se integran después en él y solo pueden hacerlo más grave. Un eje con compuerta que falla fuerza Block; un eje con compuerta que no pudo completarse (partial) o que no pudo ejecutarse en absoluto (unavailable) fuerza como mínimo Hold. La ausencia de evidencia nunca convierte una compuerta en verde.

Publicar la revisión en GitHub

La publicación es un paso aparte y deliberadamente condicionado a tu aprobación. El pipeline pr_review mantiene la revisión en Control Center; no publica nada en GitHub.

En la pestaña Revisar, espera hasta que aparezca Publicar en GitHub
Presiona Publicar en GitHub

Control Center envía una sola revisión de GitHub. Los hallazgos ya resueltos o descartados se omiten. El botón incluye todos los hallazgos abiertos restantes y, con Ship, envía APPROVE. (La herramienta MCP publish_review_to_github sigue limitándose de forma predeterminada a los hallazgos confirmados por pares y no aprueba a menos que pases approve_on_ship.) Los que llevan un anclaje de archivo y línea se convierten en comentarios en línea; todo lo demás se integra en el cuerpo del resumen, cada elemento con un pie de «— Control Center AI review» para que la fuente no deje lugar a dudas. Un veredicto Block se envía como REQUEST_CHANGES; Hold como COMMENT; Ship como APPROVE desde este botón. Después aparece un aviso que dice Publicado. La revisión se publica con la identidad de la app del servidor.

Si GitHub rechaza un anclaje en línea porque la línea no forma parte del diff, se reenvía toda la revisión con todos los hallazgos integrados en el cuerpo, para que nada se descarte en silencio.

Otros pipelines integrados sí publican directamente en GitHub: cross_review, pr_triage, ticket_to_pr y pre_merge_gate terminan cada uno con un paso de comentario. Solo pr_review retiene su salida para que la revises tú.

Despachar los revisores tú mismo

Para controlar qué roles revisan la PR y qué archivos mira cada uno, usa la herramienta MCP dispatch_reviewers dentro de un espacio de revisión existente, o agrega nodos de revisor a un pipeline. Ambas vías, con la firma exacta de la herramienta, están en Despachar agentes revisores.