São Paulo · Brasil skill para agente

15 de mai. de 2026 · risco médio · primeira versão

review-github-pr-with-agent

Skill para revisar Pull Requests com agente de código olhando segurança, teste, escopo, dados e verificação sem aprovar ou fazer merge sozinho.

Entender antes de copiar Ver texto copiável Baixar Markdown

antes de delegar

Antes de copiar, confira se a tarefa cabe neste procedimento.

Use esta parte para decidir com calma: caso indicado, risco, limites e verificações. Se a tarefa tocar cliente, produção, pagamento, segredo ou publicação, a confirmação humana vem antes da execução.

serve quando

Quando usar

Conduzir revisão de PR com agente sem transformar sugestão em aprovação automática.

limite humano

Não deixe o agente fazer isso

  • Aprovar, fazer merge, publicar release ou comentar publicamente sem revisão humana.
  • Ler ou expor segredos, variáveis de ambiente, dados de cliente ou tokens durante a revisão.
  • Mudar escopo do PR ou virar autor secreto de correções sem branch, teste e diff explícitos.
compatibilidade

Agentes compatíveis

  • Hermes Agent
  • Claude Code
  • Codex
  • agente Markdown genérico
pré-requisito

Ferramentas necessárias

  • leitura de contexto
  • editor de arquivo
  • terminal quando autorizado
  • navegador quando autorizado
risco

Risco médio

Pode mexer com ferramenta, arquivo, terminal ou conta. Peça plano, escopo e evidência antes de executar.

verificação

Regras de parada

  • Não peça nem exponha segredos, tokens, senhas ou dados de cliente no prompt.
  • Não permita publicação, deploy, merge, exclusão em massa ou mensagem externa sem confirmação humana.
  • Quando a ação tocar produção, cliente, pagamento ou credencial, pare e peça decisão humana.

checklist de decisão

Antes de rodar, responda este filtro.

A página precisa de checklist de severidade, teste e limite de ação; diagrama separado não melhora a decisão.

  1. Caso: a tarefa combina com “quando usar” ou está pedindo outra coisa?
  2. Risco: há produção, cliente, pagamento, segredo, publicação ou exclusão?
  3. Escopo: quais arquivos, contas, comandos ou mensagens estão liberados?
  4. Parada: quando o agente deve recusar e devolver a decisão para humano?
  5. Evidência: qual log, diff, link, teste ou resumo prova que terminou?

material relacionado

guia humano Claude Code e Codex: onde agentes de código ajudam e onde atrapalham template Checklist de PR review com agente de código

Perto deste assunto

Escolha pelo que ajuda agora: guia, template, texto ou instrução prática. A proximidade vem do mapa público do caderno.

guia práticoPlaybooks de operação com agentes.Agente bom não é autonomia solta. É rotina copiável, entrada clara, ferramenta certa, limite de risco e verificação.template para copiarPR review com agente de códigoquando Claude Code, Codex ou outro agente precisa revisar um PR sem virar aprovador automático. Uso: escopo, segurança, testes, dados, severidade e saída de revisãoguia de agenteClaude Code e Codex sem teatroComo usar agentes de código em tarefas pequenas, testáveis e revisáveis sem entregar o repo inteiro para uma mudança mal definida.skill para agenteagent-safety-boundariesSkill para definir confirmação, zonas de risco e regra de parada antes de dar ferramenta, arquivo ou terminal a um agente.skill para agentechoose-agent-setup-pathSkill para escolher entre agente hospedado, Hermes em VPS, Claude Code, Codex ou chat comum antes de instalar qualquer coisa.

instrução copiável

Texto copiável para o agente.

Copie daqui quando o escopo já estiver claro. Se a tarefa tocar produção, cliente, pagamento, segredo ou publicação, pare e peça confirmação humana antes de executar.

Skill: review-github-pr-with-agent

Use esta skill quando um agente for revisar um Pull Request no GitHub. O trabalho é encontrar risco e evidência, sem virar autor secreto do PR nem aprovador automático.

Agentes compatíveis

  • Hermes Agent: pode ler PR, rodar comandos e preparar comentário com revisão humana.
  • Claude Code: bom para inspecionar diff, navegar repo e sugerir correção.
  • Codex: bom para revisão focada em teste, bug e alteração pequena.
  • Agente Markdown genérico: pode revisar patch colado ou checklist sem ferramenta.

Risco

Risco médio. Vira alto se o agente puder comentar publicamente, aprovar, fazer merge, publicar release, acessar segredo ou alterar produção.

Entrada mínima

  • Link do PR ou branch.
  • Objetivo do PR.
  • Comandos de teste/build/lint.
  • Áreas que não devem ser alteradas.
  • Se o agente pode ou não comentar no GitHub.

Processo

  1. Leia título, descrição e arquivos alterados.
  2. Resuma o objetivo em uma frase.
  3. Procure bloqueadores: segurança, dados, quebra de contrato, teste ausente, escopo estranho.
  4. Rode verificação disponível se tiver permissão.
  5. Separe achado de sugestão estética.
  6. Produza revisão com severidade, arquivo, evidência e correção sugerida.

Não deixe o agente fazer isso

  • Aprovar, fazer merge, publicar release ou comentar agressivamente em nome do humano.
  • Empurrar commit de correção sem diff revisado.
  • Ignorar teste falhando porque “parece simples”.
  • Revisar só estilo e deixar segurança/dados passarem.
  • Expor segredo, log sensível ou dado de cliente no comentário.

Saída esperada

Formato: bloqueadores, importantes, nits, o que passou, comandos rodados, comandos não rodados e recomendação: aprovar, pedir mudança ou revisar manualmente.

Checklist visual

1. O objetivo do PR está claro?Sem objetivo, o agente revisa estilo e perde risco.
2. O diff toca segurança, dados ou contrato?Esses pontos viram bloqueador antes de sugestão estética.
3. Existe comando de verificação?Build, teste e lint entram como evidência, não como decoração.
4. Quem aprova?O agente pode preparar revisão. A decisão pública continua humana.

O que executar agora

Use o checklist de revisão de PR com agente antes de entregar o diff para uma ferramenta. Se ainda está separando onde Claude Code e Codex ajudam, leia o guia sobre agentes de código ou a série Playbooks de operação com agentes.

Vídeo

Ainda não há vídeo bom para este caso. Não é promessa. A versão útil precisa mostrar um PR real, achados com severidade, comandos rodados e uma revisão que não aprova nem faz merge sozinha.