Respondendo Automaticamente a Comentários de Revisão de PR

Uma vez que os revisores deixam comentários em um pull request, o Claude Code pode buscar esses comentários, fazer as alterações de código correspondentes e enviar um commit de acompanhamento para o mesmo branch - sem que você precise copiar o feedback para um prompt manualmente.

Resumo

Este fluxo de trabalho tem três partes: buscar os comentários de revisão, agir sobre eles e enviar o resultado.

A CLI gh lida tanto com a busca quanto com o envio; o Claude Code lida com a leitura dos comentários e a escrita da correção.

Como o commit de acompanhamento é feito no mesmo branch do PR original, ele aparece diretamente no PR existente - nenhum novo PR é aberto.

Isso é útil tanto para um desenvolvedor trabalhando interativamente ("vá abordar os comentários no PR #482") quanto como um bloco de construção para fluxos de trabalho de acompanhamento mais automatizados.

Funciona da mesma forma, quer os comentários venham de um revisor humano ou de um bot de revisão automatizado executando o Claude Code sem interface gráfica.

Receita

Cartão de receita de referência rápida - pronto para copiar e colar.

# 1. Faça o checkout do branch do PR localmente.
gh pr checkout 482
 
# 2. Busque os comentários de revisão (peça ao Claude Code para lê-los e abordá-los).
gh pr view 482 --comments
 
# 3. Após as alterações serem feitas, comite e envie a correção.
git add -A
git commit -m "Abordar feedback de revisão no PR #482"
git push

Quando usar isso:

Um revisor deixou comentários específicos e acionáveis em um PR e você quer que eles sejam abordados sem ter que digitar cada um manualmente.
Você está retomando um PR após a revisão e quer que o branch seja feito o checkout e os comentários carregados em uma única etapa.
Você está construindo um loop totalmente automatizado de "revisar e corrigir" e precisa que a versão manual funcione primeiro.
Os comentários são a nível de linha e referenciam código específico, que o Claude Code pode resolver diretamente contra o arquivo.

Exemplo de Trabalho

#!/usr/bin/env bash
set -euo pipefail
 
PR_NUMBER=482
 
# 1. Faça o checkout do branch do PR para que as edições caiam no branch correto.
gh pr checkout "$PR_NUMBER"
 
# 2. Busque os comentários de revisão, incluindo comentários inline (nível de linha),
#    através da API REST do GitHub usando gh api.
gh api "repos/{owner}/{repo}/pulls/$PR_NUMBER/comments" \
  --jq '.[] | "\(.path):\(.line) - \(.body)"'
 
# 3. Neste ponto, peça diretamente ao Claude Code:
#    "Leia os comentários de revisão acima e corrija cada um na base de código."
#    O Claude Code edita os arquivos referenciados.
 
# 4. Verifique se nada mais quebrou.
# (execute o comando de teste do seu projeto aqui, por exemplo, pytest / npm test / go test ./...)
 
# 5. Comite e envie o acompanhamento.
git add -A
git commit -m "Abordar feedback de revisão: validar limites da janela, adicionar caso de teste ausente"
git push
 
# 6. Confirme se o PR agora reflete a atualização.
gh pr view "$PR_NUMBER" --json commits --jq '.commits[-1].messageHeadline'

O que isso demonstra:

Usar gh api diretamente contra o endpoint de comentários de revisão de PR para obter detalhes de nível de linha que gh pr view --comments nem sempre expõe.
--jq filtrando a resposta da API em uma lista legível simples que o Claude Code pode usar diretamente.
Manter a correção e a verificação (testes) como uma etapa explícita antes de comitar, não como uma reflexão tardia.
Enviar para o branch existente para que o acompanhamento apareça como novos commits no mesmo PR aberto, não um separado.
Confirmar que o envio foi bem-sucedido verificando a mensagem do último commit do PR.

Mergulho Profundo

Como Funciona

gh pr checkout <número> busca o branch head do PR e muda seu diretório de trabalho local para ele, criando um branch de rastreamento local se um ainda não existir.
gh pr view --comments retorna os comentários de conversação de nível superior do PR; para comentários anexados a linhas específicas de uma diff, gh api repos/{owner}/{repo}/pulls/{number}/comments é mais preciso, pois retorna o caminho do arquivo e o número da linha de cada comentário.
Uma vez que o Claude Code tenha o texto do comentário e o arquivo/linha a que ele se refere, ele edita o código referenciado da mesma forma que faria para qualquer outra alteração solicitada.
git push (sem -u, uma vez que o branch já está sendo rastreado a partir do checkout) envia os novos commits para o branch existente do PR, que o GitHub anexa automaticamente ao PR aberto - ele não abre um segundo PR.
Se o PR for protegido por verificações de status obrigatórias, essas verificações serão reexecutadas automaticamente contra os novos commits, assim como qualquer outro push para o branch.

Fontes de Comentários em Resumo

Fonte	Comando	Melhor Para
Comentários de PR de nível superior	`gh pr view <n> --comments`	Discussão geral, feedback não específico de linha
Comentários de revisão inline	`gh api repos/{owner}/{repo}/pulls/{n}/comments`	Feedback de nível de linha vinculado a código específico
Resumos de revisão formais	`gh api repos/{owner}/{repo}/pulls/{n}/reviews`	Vereditos "Aprovado" / "Alterações Solicitadas" com um corpo de resumo

Notas do Bash

# Resolver após aplicar uma correção: marcar threads de revisão inline como resolvidas via
# API GraphQL não é exposto diretamente pelos comandos gh pr - a maioria das equipes deixa
# as threads se resolverem visualmente assim que a linha referenciada muda, ou
# resolvem manualmente na interface do GitHub após confirmar a correção.
gh api graphql -f query='
  query($owner:String!, $repo:String!, $pr:Int!) {
    repository(owner:$owner, name:$repo) {
      pullRequest(number:$pr) { reviewThreads(first:20) { nodes { id isResolved } } }
    }
  }' -f owner="{owner}" -f repo="{repo}" -F pr=482

Armadilhas

Buscar comentários com gh pr view --comments e falta de detalhes de nível de linha. A visualização de nível superior não expõe a linha exata a que um comentário inline se refere. Correção: use gh api repos/{owner}/{repo}/pulls/{number}/comments para feedback preciso de linha.
Editar o branch errado porque o PR não foi feito o checkout primeiro. Fazer alterações sem executar gh pr checkout primeiro pode fazer com que você comite em main ou em um branch não relacionado. Correção: sempre execute gh pr checkout <número> antes de fazer qualquer edição.
Enviar sem reexecutar testes. Uma correção que satisfaz o comentário do revisor isoladamente ainda pode quebrar outra coisa. Correção: execute a suíte de testes do projeto antes de comitar o acompanhamento, não apenas depois.
Mensagens de commit vagas como "corrigir comentários de revisão." Isso torna o histórico de commits do PR difícil de escanear meses depois. Correção: nomeie o que realmente mudou, por exemplo, "Validar limites da janela de taxa por comentário de revisão."
Assumir que uma thread de comentário se resolve automaticamente assim que o código muda. O GitHub nem sempre marca threads inline como resolvidas automaticamente apenas porque a linha referenciada mudou. Correção: resolva manualmente a thread na interface do GitHub, ou anote em um comentário de resposta que ela foi abordada.
Solicitar revisão novamente antes de realmente enviar a correção. Pingar revisores antes que o commit seja feito desperdiça o tempo deles revisando algo que ainda não mudou. Correção: confirme se o envio foi bem-sucedido (gh pr view --json commits) antes de solicitar outra olhada.

Alternativas

Alternativa	Usar Quando	Não Usar Quando
Abordar comentários manualmente em um editor	A correção é trivial e mais rápida de digitar diretamente	Os comentários são numerosos ou referenciam lógica que o Claude Code já escreveu e entende
Responder a comentários sem alterações de código	O comentário do revisor é uma pergunta, não uma alteração solicitada	O comentário pede claramente uma correção de código específica
Um trabalho de CI que responde automaticamente a comentários em cada push	Você quer isso totalmente automatizado sem um desenvolvedor no loop	As correções precisam de chamadas de julgamento que uma regra scriptada não pode fazer de forma confiável
Agrupar todos os comentários em um único commit de acompanhamento grande	Os comentários são pequenos e relacionados	Os comentários abrangem preocupações não relacionadas que são melhor rastreadas como commits separados

FAQs

Preciso copiar e colar os comentários de revisão no meu prompt?

Não - gh pr view --comments ou gh api .../comments os busca diretamente, e você pode apontar o Claude Code para essa saída em vez de digitar qualquer coisa novamente.

Isso abre um novo PR para a correção?

Não - enviar para o mesmo branch adiciona commits ao PR aberto existente; o GitHub não cria um segundo PR para commits de acompanhamento.

E se um comentário de revisão não for claro sobre qual mudança ele quer?

Trate-o como qualquer solicitação ambígua - faça uma pergunta esclarecedora ou responda ao comentário no GitHub em vez de adivinhar uma correção.

Isso funciona com revisões formais de "Alterações Solicitadas", não apenas comentários inline?

Sim - gh api repos/{owner}/{repo}/pulls/{number}/reviews retorna os vereditos de revisão formais e seus corpos de resumo, que podem ser lidos da mesma forma que comentários inline.

As verificações de status obrigatórias são reexecutadas após o commit de acompanhamento?

Sim, enviar novos commits para o branch de um PR reativa quaisquer verificações configuradas para serem executadas em eventos pull_request ou push para esse branch.

Cada comentário de revisão deve ter seu próprio commit?

Não necessariamente - agrupar correções relacionadas em um único commit com uma mensagem clara é geralmente mais fácil de revisar do que um commit por comentário, a menos que os comentários toquem em partes claramente não relacionadas do código.

Como sei a qual arquivo e linha um comentário inline se refere?

A resposta do endpoint gh api .../comments inclui os campos path e line para cada comentário, razão pela qual é preferível a gh pr view --comments para feedback de nível de linha.

Posso marcar uma thread de revisão como resolvida da linha de comando?

Apenas via API GraphQL (gh api graphql), pois a resolução de threads não é exposta pelos subcomandos mais simples baseados em REST do gh pr.

O que acontece se eu enviar uma correção, mas o PR tiver conflitos de mesclagem com o branch base?

O envio ainda é bem-sucedido e chega ao PR, mas o próprio PR mostrará como não mesclável até que os conflitos sejam resolvidos separadamente, geralmente mesclando ou rebaseando no branch base mais recente.

Isso é diferente de executar o Claude Code como um bot de revisão automatizado?

Sim - este fluxo de trabalho responde a comentários já deixados por outra pessoa (humana ou bot); um bot de revisão automatizado é o que gera os comentários em primeiro lugar.

Posso usar isso para abordar comentários no PR de outra pessoa?

Sim, desde que você tenha acesso de envio ao branch desse PR (geralmente requer ser um colaborador no mesmo repositório ou o PR ser de um branch, não de um fork que você não possui).

Relacionados

Criando um Pull Request de uma Sessão Claude Code com gh - como o PR ao qual este fluxo de trabalho responde é aberto em primeiro lugar.
Como o Claude Code se Encaixa no Seu Fluxo de Trabalho de Pull Request do GitHub - onde este ponto de contato se situa em relação à abertura e revisão.
Executando o Claude Code como um Bot de Revisão de Código Automatizado em CI - a fonte automatizada dos comentários aos quais este fluxo de trabalho pode responder.
Melhores Práticas de Integração com GitHub - padrões para manter os commits de acompanhamento seguros e revisáveis.

Versões da Stack: Escrito contra a linha de modelos Claude atual por volta de junho de 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (o padrão), e Claude Haiku 4.5. Nomes de modelos, preços e recursos de produtos mudam rapidamente - verifique os detalhes atuais em platform.claude.com/docs antes de confiar neles.