Usar revisão com IA

Este guia mostra como fazer agentes revisores revisarem uma pull request e como publicar o resultado no GitHub.

Inicie uma revisão com IA

Abra a PR e vá até a aba Visão geral
Abra o menu de overflow ⋯ na linha de ações e escolha Ask AI

O item só aparece enquanto a PR está aberta — é uma ação de pré-merge. O mesmo botão é oferecido como Ask AI no estado vazio da aba Revisão, antes de existir qualquer revisão.

O Control Center inicia o pipeline pr_review predefinido e abre a aba Revisão da PR para você acompanhar. O pipeline:

Abre o espaço de revisão da própria PR, cujo worktree isolado tem a PR em checkout na sua ref de head
Distribui os revisores do nível de revisão do espaço de trabalho — três por padrão (os agentes predefinidos qa, architect e engineer, em paralelo). Não há detecção de linguagem nem de domínio
Faz o agente líder (CEO) consolidar os achados em um passo a passo
Finaliza: agrupa os achados em grupos de consenso e calcula o veredito. Quando a associação chega a awaiting approval, Publicar no GitHub aparece na aba Revisão

Até onde a revisão vai é o nível de revisão do espaço de trabalho — light (um revisor), balanced (três, o padrão) ou thorough (todos os cinco, incluindo os especialistas de segurança e desempenho) — definido em Configurações → Espaço de trabalho → Geral, no cartão Política do espaço de trabalho. Um nível mais leve registra exatamente a mesma quantidade de achados; apenas relata menos deles em destaque.

Todos os revisores publicam no único espaço de revisão da PR, e é isso que torna seus achados comparáveis. Consulte Revisão com IA para entender como as peças se encaixam.

O pr_review vem apenas com um gatilho manual. Para que ele dispare em toda PR publicada, adicione um gatilho você mesmo — consulte Despachar agentes revisores. Você também pode iniciar uma revisão pelo próprio GitHub, sem precisar de gatilho de pipeline: mencione o bot do servidor na PR ou adicione o rótulo ai-review — consulte Falar com o Control Center a partir de uma PR do GitHub.

Se um toast avisar que já existe uma revisão em andamento para esta pull request, é porque uma já está em execução; permaneça na aba Revisão ou abra Pipelines para encontrá-la.

Leia os achados

Os revisores registram achados como nós de revisão no espaço de revisão. Cada um carrega:

Campo	Descrição
Tipo	`bug`, `suggestion`, `recommendation`, `question` ou `ticket`
Prioridade	P0 (crítico) → P3 (detalhe)
Categoria	`security`, `stability`, `data_integrity`, `correctness`, `performance` ou `maintainability`
Arquivo e linha	Onde o achado está ancorado
Código original	O código sobre o qual o achado trata
Código sugerido	A correção proposta
Confiança	Quão confiante o revisor está
Status	`open` → `consensus-ready` → `resolved` ou `dismissed`

Um achado só chega a consensus-ready quando um revisor par o confirma. Um agente não pode confirmar o próprio achado, então a opinião de um único revisor nunca progride sozinha.

A aba Revisão mostra a lista de achados, filtrável por tipo e status, com um alternador para achados descartados, ao lado do artefato que o agente consolidador publicou. A visão determinística — coortes, o painel multi-eixo, diffs de contrato e visuais — é calculada no servidor, mas não tem superfície no app; consulte Computação de revisão para saber o que a passagem produz.

Confira o painel de discordâncias

Quando dois revisores ancoram achados no mesmo arquivo e linha, mas os avaliam de formas muito diferentes — prioridades com dois ou mais níveis de diferença, ou um chamando de bug enquanto o outro chama de suggestion —, um painel de discordância aparece acima da lista de achados. Leia esses primeiro: é onde as opiniões dos revisores divergem e o seu julgamento vale mais.

Leia o veredito

Quando o agente líder finaliza, ele calcula um veredito:

Veredito	Significado
Ship	Nada bloqueante encontrado
Hold	Problemas que devem ser resolvidos antes do merge
Block	Problemas críticos que precisam ser corrigidos

O veredito carrega uma pontuação de confiança agregada e contagens de achados por prioridade.

Os eixos de revisão então entram nele e só podem torná-lo mais severo. Um eixo com portão que falha força Block; um eixo com portão que não pôde ser concluído (partial) ou não pôde rodar de forma alguma (unavailable) força no mínimo Hold. A ausência de evidência nunca libera um portão.

Publique a revisão no GitHub

A publicação é um passo separado e deliberadamente condicionado ao usuário. O pipeline pr_review mantém a revisão no Control Center; ele não publica no GitHub.

Na aba Revisão, espere até Publicar no GitHub aparecer
Pressione Publicar no GitHub

O Control Center envia uma revisão do GitHub. Achados já resolvidos ou descartados são ignorados. O botão inclui todos os achados abertos restantes e, em Ship, envia APPROVE. (A ferramenta MCP publish_review_to_github ainda usa por padrão apenas achados confirmados por pares e não aprova, a menos que você passe approve_on_ship.) Os que carregam uma âncora de arquivo e linha viram comentários em linha; todo o resto é incorporado ao corpo do resumo, cada um com um rodapé “— Control Center AI review” para que a origem seja inequívoca. Um veredito Block é enviado como REQUEST_CHANGES; Hold como COMMENT; Ship como APPROVE a partir deste botão. Um toast então exibe Publicada. A revisão é publicada sob a identidade do app do servidor.

Se o GitHub rejeitar uma âncora em linha porque a linha não faz parte do diff, a revisão inteira é reenviada com todos os achados incorporados ao corpo, para que nada seja descartado em silêncio.

Outros pipelines integrados publicam diretamente no GitHub: cross_review, pr_triage, ticket_to_pr e pre_merge_gate terminam cada um em um passo de comentário. Só o pr_review retém a saída para você.

Despache os revisores você mesmo

Para ter controle sobre quais papéis revisam a PR e quais arquivos cada um examina, use a ferramenta MCP dispatch_reviewers dentro de um espaço de revisão existente, ou adicione nós de revisor a um pipeline. Os dois caminhos, com a assinatura exata da ferramenta, estão em Despachar agentes revisores.