Responder automáticamente a los comentarios de revisión de PR
Una vez que los revisores dejan comentarios en una solicitud de extracción (pull request), Claude Code puede obtener esos comentarios, realizar los cambios de código correspondientes y enviar un commit de seguimiento a la misma rama, sin que tengas que copiar manualmente la retroalimentación en un prompt.
Resumen
Este flujo de trabajo tiene tres partes: obtener los comentarios de revisión, actuar sobre ellos y enviar el resultado.
La CLI gh se encarga tanto de la obtención como del envío; Claude Code se encarga de leer los comentarios y escribir la corrección.
Dado que el commit de seguimiento aterriza en la misma rama que el PR original, aparece directamente en el PR existente, no se abre un nuevo PR.
Esto es útil tanto para un desarrollador que trabaja interactivamente ("ir a abordar los comentarios en el PR #482") como para un componente básico de flujos de trabajo de seguimiento más automatizados.
Funciona de la misma manera, ya se trate de comentarios de un revisor humano o de un bot de revisión automatizado que ejecuta Claude Code sin interfaz gráfica.
Receta
Tarjeta de receta de referencia rápida, lista para copiar y pegar.
# 1. Descarga la rama del PR localmente.
gh pr checkout 482
# 2. Obtén los comentarios de revisión (pide a Claude Code que los lea y los aborde).
gh pr view 482 --comments
# 3. Después de realizar los cambios, confirma y envía la corrección.
git add -A
git commit -m "Abordar comentarios de revisión en el PR #482"
git pushCuándo usar esto:
- Un revisor dejó comentarios específicos y accionables en un PR y deseas que se aborden sin tener que volver a escribir cada uno manualmente.
- Estás retomando un PR después de la revisión y quieres que la rama se descargue y los comentarios se carguen en un solo paso.
- Estás construyendo un bucle completo de "revisión y corrección" automatizado y necesitas que la versión manual funcione primero.
- Los comentarios son a nivel de línea y hacen referencia a código específico, que Claude Code puede resolver directamente contra el archivo.
Ejemplo de trabajo
#!/usr/bin/env bash
set -euo pipefail
PR_NUMBER=482
# 1. Descarga la rama del PR para que las ediciones aterricen en la rama correcta.
gh pr checkout "$PR_NUMBER"
# 2. Obtén los comentarios de revisión, incluidos los comentarios en línea (a nivel de línea),
# a través de la API REST de GitHub mediante gh api.
gh api "repos/{owner}/{repo}/pulls/$PR_NUMBER/comments" \
--jq '.[] | "\(.path):\(.line) - \(.body)"'
# 3. En este punto, pregunta directamente a Claude Code:
# "Lee los comentarios de revisión anteriores y corrige cada uno en la base de código."
# Claude Code edita los archivos referenciados.
# 4. Verifica que nada más se haya roto.
# (ejecuta tu comando de prueba del proyecto aquí, por ejemplo, pytest / npm test / go test ./...)
# 5. Confirma y envía el seguimiento.
git add -A
git commit -m "Abordar comentarios de revisión: validar límites de ventana, agregar caso de prueba faltante"
git push
# 6. Confirma que el PR ahora refleja la actualización.
gh pr view "$PR_NUMBER" --json commits --jq '.commits[-1].messageHeadline'Lo que esto demuestra:
- Uso de
gh apidirectamente contra el endpoint de comentarios de revisión de PR para obtener detalles a nivel de línea quegh pr view --commentsno siempre expone. --jqfiltrando la respuesta de la API en una lista legible simple sobre la que Claude Code puede actuar directamente.- Mantener la corrección y la verificación (pruebas) como un paso explícito antes de confirmar, no como una ocurrencia tardía.
- Enviar a la rama existente para que el seguimiento aparezca como nuevos commits en el mismo PR abierto, no uno separado.
- Confirmar que el envío aterrizó verificando el último mensaje de commit del PR.
Inmersión profunda
Cómo funciona
gh pr checkout <número>descarga la rama principal del PR y cambia tu directorio de trabajo local a ella, creando una rama de seguimiento local si aún no existe.gh pr view --commentsdevuelve los comentarios de conversación de nivel superior del PR; para los comentarios adjuntos a líneas específicas de una diferencia,gh api repos/{owner}/{repo}/pulls/{number}/commentses más preciso, ya que devuelve la ruta del archivo y el número de línea de cada comentario.- Una vez que Claude Code tiene el texto del comentario y el archivo/línea al que se refiere, edita el código referenciado de la misma manera que lo haría para cualquier otro cambio solicitado.
git push(sin-u, una vez que la rama ya está siendo rastreada desde la descarga) envía los nuevos commits a la rama existente del PR, que GitHub adjunta automáticamente al PR abierto; no crea un segundo PR.- Si el PR está protegido por verificaciones de estado requeridas, esas verificaciones se vuelven a ejecutar automáticamente contra los nuevos commits, al igual que cualquier otro push a la rama.
Fuentes de comentarios de un vistazo
| Fuente | Comando | Mejor para |
|---|---|---|
| Comentarios de PR de nivel superior | gh pr view <n> --comments | Discusión general, retroalimentación no específica de línea |
| Comentarios de revisión en línea | gh api repos/{owner}/{repo}/pulls/{n}/comments | Retroalimentación a nivel de línea vinculada a código específico |
| Resúmenes de revisión formales | gh api repos/{owner}/{repo}/pulls/{n}/reviews | Veredictos de "Aprobado" / "Cambios solicitados" con un cuerpo de resumen |
Notas de Bash
# Resolver después de aplicar una corrección: marcar hilos de revisión en línea resueltos a través de la
# API de GraphQL no está expuesto directamente por los comandos gh pr. La mayoría de los equipos dejan
# que los hilos se resuelvan automáticamente visualmente una vez que cambia la línea referenciada, o
# los resuelven manualmente en la interfaz de usuario de GitHub después de confirmar la corrección.
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=482Posibles problemas
- Obtener comentarios con
gh pr view --commentsy falta de detalle a nivel de línea. La vista de nivel superior no expone a qué línea exacta se refiere un comentario en línea. Solución: usagh api repos/{owner}/{repo}/pulls/{number}/commentspara retroalimentación precisa a nivel de línea. - Editar la rama incorrecta porque el PR no se descargó primero. Realizar cambios sin ejecutar
gh pr checkoutprimero puede hacer que confirmes enmaino en una rama no relacionada. Solución: siempre ejecutagh pr checkout <número>antes de realizar cualquier edición. - Enviar sin volver a ejecutar las pruebas. Una corrección que satisface el comentario del revisor de forma aislada aún puede romper algo más. Solución: ejecuta la suite de pruebas del proyecto antes de confirmar el seguimiento, no solo después.
- Mensajes de commit vagos como "corregir comentarios de revisión". Estos hacen que el historial de commits del PR sea difícil de hojear meses después. Solución: nombra lo que realmente cambió, por ejemplo, "Validar los límites de la ventana de tasa de límite según el comentario de revisión".
- Asumir que un hilo de comentarios se resuelve automáticamente una vez que el código cambia. GitHub no siempre marca los hilos en línea como resueltos automáticamente solo porque la línea referenciada cambió. Solución: resuelve manualmente el hilo en la interfaz de usuario de GitHub, o anota en un comentario de respuesta que se ha abordado.
- Volver a solicitar la revisión antes de enviar la corrección. Notificar a los revisores antes de que el commit se aplique les hace perder tiempo revisando algo que aún no ha cambiado. Solución: confirma que el envío se realizó correctamente (
gh pr view --json commits) antes de solicitar otra revisión.
Alternativas
| Alternativa | Usar cuando | No usar cuando |
|---|---|---|
| Abordar comentarios manualmente en un editor | La corrección es trivial y más rápida de escribir directamente | Los comentarios son numerosos o hacen referencia a lógica que Claude Code ya escribió y entiende |
| Responder a comentarios sin cambios de código | El comentario del revisor es una pregunta, no un cambio solicitado | El comentario pide claramente una corrección de código específica |
| Un trabajo de CI que responde automáticamente a los comentarios en cada push | Quieres que esto esté completamente automatizado sin la intervención del desarrollador | Las correcciones requieren decisiones de juicio que una regla programada no puede tomar de manera confiable |
| Agrupar todos los comentarios en un solo commit de seguimiento grande | Los comentarios son pequeños y relacionados | Los comentarios abarcan preocupaciones no relacionadas que es mejor rastrear como commits separados |
Preguntas frecuentes
¿Necesito copiar y pegar los comentarios de revisión en mi prompt?
No, gh pr view --comments o gh api .../comments los obtienen directamente, y puedes dirigir Claude Code a esa salida en lugar de volver a escribir nada.
¿Esto abre un nuevo PR para la corrección?
No, enviar a la misma rama agrega commits al PR abierto existente; GitHub no crea un segundo PR para los commits de seguimiento.
¿Qué pasa si un comentario de revisión no está claro sobre qué cambio quiere?
Trátalo como cualquier solicitud ambigua: haz una pregunta aclaratoria o responde al comentario en GitHub en lugar de adivinar una corrección.
¿Puede esto funcionar con revisiones formales de "Cambios solicitados", no solo con comentarios en línea?
Sí, gh api repos/{owner}/{repo}/pulls/{number}/reviews devuelve los veredictos de revisión formales y sus cuerpos de resumen, que se pueden leer de la misma manera que los comentarios en línea.
¿Se vuelven a ejecutar las verificaciones de estado requeridas después del commit de seguimiento?
Sí, enviar nuevos commits a la rama de un PR vuelve a activar las verificaciones configuradas para ejecutarse en eventos pull_request o push para esa rama.
¿Debería cada comentario de revisión tener su propio commit?
No necesariamente; agrupar correcciones relacionadas en un solo commit con un mensaje claro suele ser más fácil de revisar que un commit por comentario, a menos que los comentarios toquen partes del código claramente no relacionadas.
¿Cómo sé a qué archivo y línea se refiere un comentario en línea?
La respuesta del endpoint gh api .../comments incluye los campos path y line para cada comentario, razón por la cual se prefiere a gh pr view --comments para la retroalimentación a nivel de línea.
¿Puedo marcar un hilo de revisión como resuelto desde la línea de comandos?
Solo a través de la API de GraphQL (gh api graphql), ya que la resolución de hilos no está expuesta a través de los subcomandos más simples basados en REST de gh pr.
¿Qué sucede si envío una corrección pero el PR tiene conflictos de fusión con la rama base?
El envío aún se realiza y aterriza en el PR, pero el PR en sí se mostrará como no fusionable hasta que los conflictos se resuelvan por separado, generalmente fusionando o rebasando en la rama base más reciente.
¿Es esto diferente de ejecutar Claude Code como un bot de revisión automatizado?
Sí, este flujo de trabajo responde a comentarios ya dejados por otra persona (humana o bot); un bot de revisión automatizado es lo que genera los comentarios en primer lugar.
¿Puedo usar esto para abordar comentarios en el PR de otra persona?
Sí, siempre que tengas acceso de envío a la rama de ese PR (normalmente requiere ser un colaborador en el mismo repositorio o que el PR sea de una rama, no de una bifurcación que no poseas).
Relacionado
- Crear un Pull Request desde una Sesión de Claude Code con gh - cómo se abre el PR al que responde este flujo de trabajo en primer lugar.
- Cómo Claude Code Encaja en tu Flujo de Trabajo de Pull Request de GitHub - dónde se encuentra este punto de contacto en relación con la apertura y la revisión.
- Ejecutar Claude Code como un Bot de Revisión de Código Automatizado en CI - la fuente automatizada de los comentarios a los que este flujo de trabajo puede responder.
- Mejores prácticas de integración de GitHub - patrones para mantener los commits de seguimiento seguros y revisables.
Versiones de Stack: Escrito contra la línea de modelos de Claude actual alrededor de junio de 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (el predeterminado) y Claude Haiku 4.5. Los nombres de los modelos, los precios y las características del producto cambian rápidamente; verifica los detalles actuales en platform.claude.com/docs antes de confiar en ellos.