O PR tem 30 arquivos, o colega pediu revisão para hoje e você quer um primeiro passe antes de ler linha por linha. A Verboo Code tem dois comandos prontos para isso: /review, que lê um pull request do GitHub e devolve uma revisão geral, e /security-review, que olha só as mudanças da sua branch atrás de vulnerabilidade com alta confiança.
O que o /review faz na Verboo Code?
Ele manda o agente agir como revisor de código usando a CLI do GitHub: lista os PRs abertos com gh pr list, abre o escolhido com gh pr view, lê o diff com gh pr diff e escreve uma revisão em seções. Tudo roda local, na sua máquina, com o modelo que você escolheu na sessão.
A revisão cobre cinco pontos, definidos no prompt do comando: correção do código, convenções do projeto, impacto em performance, cobertura de testes e segurança. O formato de saída é uma visão geral do PR, análise de qualidade, sugestões específicas e riscos.
Como revisar um pull request com /review, passo a passo?
O /review depende do gh instalado e autenticado, porque é ele que busca o PR. Faça isso uma vez por máquina:
# confere se o gh está logado
gh auth status
# se não estiver
gh auth loginDepois, dentro da sessão, na pasta do repositório:
# sem número: o agente roda gh pr list e mostra os PRs abertos
/review
# com número: vai direto para o PR 42
/review 42
O que vier depois do nome do comando entra no prompt como número do PR. Se você passar texto em vez de número, o agente recebe esse texto no lugar, então prefira só o número e peça o foco extra na mensagem seguinte, por exemplo "agora olha só as migrations".
Qual a diferença entre /review e /security-review?
O /review revisa um PR do GitHub de forma ampla. O /security-review revisa a branch em que você está, sem precisar de PR aberto, e procura só vulnerabilidade com chance real de exploração.
/review | /security-review | |
|---|---|---|
| O que revisa | Um pull request do GitHub | As mudanças da branch atual |
| De onde vem o diff | gh pr diff <número> | git diff origin/HEAD... |
Precisa de gh | Sim, autenticado | Não, só git |
| Precisa de PR aberto | Sim | Não |
| Foco | Correção, convenção, performance, testes, segurança | Só vulnerabilidade nova introduzida pela branch |
| Filtro de ruído | Nenhum explícito | Descarta achado com confiança abaixo de 8 (escala de 1 a 10) |
| Ferramentas liberadas | As da sessão, conforme suas permissões | Pré-liberadas: git diff, git status, git log, git show, git remote show, Read, Glob, Grep, LS e Task |
Como rodar uma revisão de segurança antes de abrir o PR?
Na branch com as suas mudanças, digite /security-review. Antes de chamar o modelo, a CLI roda quatro comandos git e cola a saída no prompt:
git status
git diff --name-only origin/HEAD...
git log --no-decorate origin/HEAD...
git diff origin/HEAD...Com o diff na mão, o agente lança uma subtarefa para achar vulnerabilidades e, para cada achado, outra subtarefa em paralelo só para filtrar falso positivo. No fim fica apenas o que passou com confiança 8 ou mais. Cada item sai com arquivo e linha, severidade (High, Medium ou Low), categoria como sql_injection ou xss, cenário de exploração e recomendação de correção.
O prompt também exclui de propósito categorias que geram muito ruído: negação de serviço, rate limit, segredo guardado em disco, biblioteca desatualizada, arquivo só de teste e problema de memória em linguagem com memória segura. Se você precisa revisar uma dessas, peça na conversa, fora do comando.
Armadilha: sem origin/HEAD, o /security-review não tem com o que comparar. Os quatro comandos usam origin/HEAD como base. Repositório criado com git init e só depois ligado a um remoto costuma não ter essa referência, e o git responde fatal: ambiguous argument 'origin/HEAD...'. Crie a referência apontando para a branch padrão do remoto:
# descobre a branch padrão do remoto e grava origin/HEAD
git remote set-head origin --auto
# confere
git rev-parse --abbrev-ref origin/HEADA segunda linha deve devolver algo como origin/main. Rode o /security-review de novo.
Como trazer os comentários do PR para dentro da sessão?
Use /pr-comments. Ele descobre o PR da branch atual com gh pr view --json number,headRepository, busca os comentários gerais e os comentários de revisão pela API do GitHub e mostra tudo agrupado por thread, com arquivo, linha e o trecho do diff de cada comentário.
O fluxo que fecha o ciclo fica assim: /pr-comments para ver o que o revisor pediu, um pedido seu para o agente corrigir, e o /diff para conferir o que mudou antes do commit.
Dá para confiar só na revisão do agente?
Não como única revisão. O /review é um primeiro passe: aponta o óbvio, resume o PR e encontra o que salta no diff. Ele lê o diff que o gh devolve, então contexto que não está no diff, como uma regra de negócio em outro módulo, só entra se o agente decidir abrir o arquivo. Peça isso direto quando importar: "abre o src/billing/ e confere se a mudança quebra o cálculo de desconto".
Para padronizar o que o agente cobra em toda revisão (nome de teste, padrão de erro, pasta proibida), escreva as regras no AGENTS.md com /memory. Elas entram no contexto de toda sessão, inclusive na de revisão.
Revisão boa pede que o agente abra os arquivos em volta do diff, não só o diff. Na Verboo Code os planos rodam com token ilimitado, então pedir para ler o módulo inteiro antes de opinar custa o mesmo que ler só as linhas alteradas.
