claude-pr-review-bot
Un revisor de pull requests para GitHub Actions que le pide a Claude un solo documento de hallazgos y que solo puede comentar.
C# sobre .NET 10. Salida estructurada contra un JSON Schema, una sola herramienta read_file, hallazgos filtrados contra las líneas que GitHub acepta y una única revisión por corrida. Nunca aprueba, pide cambios ni bloquea un merge.
- Rol:
- Diseño y desarrollo
- Año:
- 2026
- bugs detectados en un pull request real de demo
- 3/3
- de costo medido de esa revisión con Claude Haiku 5.5
- USD 0,0009
- permisos para aprobar, bloquear o hacer merge
- 0
- herramienta: read_file, que lee por SHA desde la API
- 1
Capturas
El problema
El revisor con IA obvio le da al modelo una herramienta para publicar comentarios y ejecuta cada llamada apenas llega. Eso cuesta un viaje de ida y vuelta por hallazgo, puede dejar media revisión publicada si una llamada falla y nunca le da al código un momento para ver el conjunto completo y decidir que es ruido. Una versión temprana dejó 47 comentarios en un solo pull request, la mayoría en archivos generados.
Restricciones
- Debe revisar pull requests de forks, lo que exige secretos bajo pull_request_target
- El código del contribuidor nunca debe ejecutarse junto a la API key
- Un prompt injection dentro de un diff no debe poder aprobar ni bloquear nada
- Un costo por pull request predecible y visible
Cómo funciona
- El bot obtiene de la API de GitHub los archivos modificados y sus parches, y convierte los hunks en el conjunto de líneas donde GitHub acepta comentarios.
- Claude recibe el diff como contenido no confiable y devuelve sus hallazgos en un solo documento que cumple un JSON Schema. Cuando un hunk no alcanza para entender el cambio, puede llamar a read_file, que trae el archivo en el SHA del head pasando por una validación de rutas.
- Un filtro descarta los hallazgos fuera del diff, se queda con el más grave por línea y limita el total. Después se publica una única revisión de tipo COMMENT, y cada hallazgo descartado queda en el log.
Decisiones clave
Los hallazgos son datos, no acciones
La salida estructurada devuelve el conjunto completo de una vez, así que el código puede filtrarlo, deduplicarlo y limitarlo antes de que algo llegue a GitHub, y un fallo no publica nada en vez de media revisión.
Costo de la decisión: La revisión aparece completa al final de la corrida, no comentario por comentario.
Solo puede comentar, por diseño
El cliente de GitHub tiene cinco métodos y ninguno puede aprobar, pedir cambios ni hacer merge. Lo peor que puede lograr un prompt injection es que el bot se quede callado.
Costo de la decisión: No puede imponer nada; si un equipo quiere un control que bloquee, lo mantiene en su propio CI.
Se compila desde el código fuente en cada corrida
La action compuesta compila el bot en la versión fijada, así que el código que revisa tu pull request es exactamente el que está en el repositorio.
Costo de la decisión: Cerca de un minuto por corrida; una action en Docker sería más rápida, pero menos transparente.
Resultados
- En un pull request real de demo, Claude Haiku 5.5 detectó los tres bugs que introducía (una caché no segura con varios hilos, un catch que convierte timeouts en rechazos y una API key escrita en la consola) en una sola llamada, por USD 0,0009.
- Alrededor de USD 0,12 por pull request de 400 líneas con Claude Opus 5 y de USD 0,05 con Sonnet 5, con los tokens de entrada, salida y caché registrados en cada turno.
- El prompt de sistema va en caché, y una lista de exclusión para lockfiles y código generado redujo a menos de la mitad el diff promedio que llega al modelo.
- Un modo de prueba con hallazgos de ejemplo ejecuta todo el flujo en CI en cada push, sin API key.
- El diseño está explicado en un artículo de DEV.to, en inglés y en español.
Tecnologías
- .NET 10
- C# 14
- Claude API
- Structured outputs
- GitHub Actions
- xUnit