Dirige agentes de GitHub desde un PR antes de que escriban código
`steer: true` abre un PR borrador antes de ejecutar el agente y permite corregir su rumbo desde la revisión.
El problema no es crear el PR al final
Cuando un agente termina una tarea y abre el pull request al final, la revisión llega tarde para cambiar decisiones de diseño, alcance o enfoque. Podemos comentar el resultado, pedir cambios y lanzar otra iteración, pero ya hemos gastado tiempo y contexto en una dirección que quizá no era la correcta. Esto se nota especialmente en tareas de mantenimiento, refactors y automatizaciones que tocan varios ficheros de un proyecto Laravel.
GitHub Agentic Workflows incorpora una opción experimental llamada steer dentro de safe-outputs.create-pull-request. Con steer: true, el flujo reserva un pull request en borrador antes de que el agente empiece a trabajar. Ese PR sirve como punto de seguimiento mientras la ejecución está en marcha, no como una promesa de que el cambio vaya a terminar bien.
Un PR que existe antes de que exista el cambio
El PR inicial se crea en modo borrador y queda asociado a una rama controlada por el workflow. Cuando el agente produce finalmente una salida create_pull_request, el sistema actualiza ese mismo PR en vez de abrir uno nuevo. Si la ejecución termina sin cambios, o falla antes de producir la salida esperada, la documentación indica que el PR provisional se cierra y se elimina su rama.
La parte útil no es solo ver que hay un trabajo en curso. El agente puede leer comentarios y comentarios de revisión escritos por personas en ese PR cuando contienen la palabra clave steer. Así puedo dejar una instrucción concreta durante la ejecución, por ejemplo pedir que no cambie la API pública de un servicio Laravel, que limite el arreglo a una migración o que descarte una solución basada en Redis.
La configuración mínima verificada
La opción requiere declarar de forma explícita el permiso pull-requests: read. El compilador no lo añade por su cuenta, algo que me parece correcto: leer comentarios de revisión es una capacidad que debe quedar visible en el workflow. Además, la precreación necesita credenciales de salida segura con permisos de escritura sobre contenidos, pull requests y comprobaciones.
---
on: issues
permissions:
contents: read
pull-requests: read
safe-outputs:
create-pull-request:
steer: true
---Este bloque no sustituye al resto del workflow: sigue haciendo falta definir el disparador, las instrucciones para el agente y la autenticación del motor elegido. La configuración genera una advertencia de característica experimental al ejecutar gh aw compile. Conviene asumir que su comportamiento puede cambiar hasta que deje de estar marcado como experimental.
Dónde lo usaría en Laravel
Lo probaría primero en tareas de bajo riesgo y con un resultado fácil de revisar. Un buen caso sería abrir un PR borrador para actualizar documentación interna, mejorar tipos PHPDoc, detectar código muerto o preparar una propuesta de tests sobre una incidencia. Si el agente empieza a ampliar demasiado el cambio, puedo escribir un comentario con steer y concretar el límite sin esperar al final de la ejecución.
También encaja en repositorios donde hay decisiones de arquitectura que no quiero delegar por completo. Por ejemplo, un agente puede investigar por qué una cola falla en producción y preparar un cambio, mientras yo le indico desde el PR que no modifique config/queue.php, que priorice una prueba de regresión o que analice primero un job concreto. El PR deja de ser solo la entrega final y pasa a ser la interfaz de control de una tarea automática.
Encaje con un homelab
GitHub Agentic Workflows puede dirigirse a runners autoalojados mediante runs-on. La documentación exige Linux con soporte de Docker para esos runners, porque el sandbox y la pasarela MCP se ejecutan en contenedores. Eso permite pensar en una máquina del homelab para automatizaciones de repositorio que necesiten herramientas locales, acceso a una red privada o una configuración que no encaje en un runner hospedado.
No lo convertiría en una excusa para dar acceso total a la red doméstica a cualquier workflow. Un runner que puede alcanzar Proxmox, NAS, servicios Docker o secretos internos merece el mismo cuidado que una máquina de CI de producción. Separaría los runners por función, limitaría las etiquetas que pueden usarlos y mantendría los repositorios que ejecutan agentes bajo revisión estricta.
La letra pequeña
steer no convierte al agente en una conversación en tiempo real garantizada. El agente lee los comentarios de dirección durante su ejecución, pero no hay que asumir que reaccionará de forma instantánea ni que reinterpretará correctamente una instrucción ambigua. Los comentarios deben ser cortos, verificables y centrados en decisiones: qué no tocar, qué prueba añadir o qué alternativa descartar.
Tampoco sirve para operaciones entre repositorios ni para forks. El modo de PR precreado está limitado a un único PR por ejecución en el mismo repositorio y no se puede combinar con opciones como target-repo, head-repo, allowed-repos, allowed-branches, allowed-base-branches o checkout: false. Además, en staged mode no se reserva ningún PR, porque ese modo no debe provocar efectos en la API de GitHub.
La rama precreada pertenece al workflow y su nombre se construye a partir de un prefijo estático y metadatos confiables de la ejecución. Eso reduce riesgos, pero no elimina la responsabilidad de revisar permisos, secretos y reglas de protección de ramas. Para mí, esta función tiene sentido cuando el agente propone cambios revisables; no cuando se pretende usar un comentario como autorización informal para desplegar o administrar infraestructura.
Una automatización que admite corrección
La novedad interesante no es que un agente abra PRs, porque eso ya forma parte de muchas herramientas. Lo diferente es adelantar el PR al inicio y usarlo como canal de intervención mientras el trabajo sigue abierto. En un equipo pequeño, o en un proyecto personal con bastante automatización, ese cambio puede evitar que una tarea correcta técnicamente sea incorrecta por alcance.
Empezaría con un workflow que solo cree cambios pequeños y con permisos mínimos. Después revisaría los PRs generados, los comentarios de dirección y los casos en los que el agente no siguió la intención. Si el proceso aporta control sin añadir ruido, entonces sí tendría sentido moverlo a tareas más relevantes del repositorio.
Fuente: Weekly Update – August 24, 2026
Documentación oficial: Safe Outputs para pull requests · Runners autoalojados