Guide GitHub agents from a pull request before they write codeGuide GitHub agents from a pull request before they write code

The problem starts when the PR appears too late

When an agent opens its pull request only after finishing the task, review arrives too late to influence important choices about scope, design, or implementation. We can request changes and run another iteration, but time and context have already been spent on a path that may not be the right one. This is particularly noticeable in maintenance work, refactors, and automations that touch several files in a Laravel project.

GitHub Agentic Workflows now includes an experimental steer option under safe-outputs.create-pull-request. With steer: true, the workflow allocates a draft pull request before the agent starts its work. That PR becomes a place to follow the run while it is still active, rather than a guarantee that the task will complete successfully.

A pull request before there is a patch

The initial PR is opened as a draft and attached to a workflow-owned branch. Once the agent produces its create_pull_request output, the system updates that existing PR instead of creating another one. According to the documentation, if the run ends without changes or fails before producing the expected output, the temporary PR is closed and its branch is deleted.

The useful part is not merely seeing that work is underway. The agent can read user-authored comments and review comments on that PR when they include the steer keyword. That gives me a way to redirect an active run: keep a Laravel service API unchanged, restrict the work to a migration, or drop a Redis-based approach before it grows into a larger change.

The verified minimum configuration

The feature requires an explicit top-level pull-requests: read permission. The compiler will not add that permission automatically, which is the right default: the ability to read review feedback should be visible in the workflow definition. Pre-creating the PR also requires a safe-output token with write access to contents, pull requests, and checks.

---
on: issues
 
permissions:
  contents: read
  pull-requests: read
 
safe-outputs:
  create-pull-request:
    steer: true
---

This is not a complete workflow by itself. The trigger, agent instructions, and authentication for the selected engine still need to be configured. Running gh aw compile emits an experimental-feature warning when steer is enabled, so I would treat its behavior as subject to change.

Where I would use it in Laravel

I would start with low-risk tasks that have a clearly reviewable outcome. Good candidates include internal documentation updates, PHPDoc improvements, dead-code investigations, or preparing a test proposal for an issue. If the agent starts expanding the change too far, I can leave a steer comment and set a boundary without waiting for the run to finish.

It also fits repositories where architectural decisions should not be delegated completely. An agent might investigate why a queue is failing and prepare a fix, while I tell it through the PR not to edit config/queue.php, to prioritize a regression test, or to inspect a specific job first. In that setup, the PR stops being just the final delivery mechanism and becomes a control surface for automated work.

How it fits in a homelab

GitHub Agentic Workflows can target self-hosted runners through runs-on. The official documentation requires Linux and Docker support for those runners because the sandbox and MCP gateway run in containers. That makes a homelab machine a plausible option for repository automation that needs local tooling, private-network access, or an environment that does not fit a hosted runner.

I would not use that as an excuse to give every workflow unrestricted access to a home network. A runner that can reach Proxmox, a NAS, Docker services, or internal secrets deserves the same care as a production CI machine. I would separate runners by purpose, restrict which labels can target them, and keep the repositories that run agents under close review.

The small print

steer does not turn an agent run into a guaranteed real-time conversation. The agent reads steering comments during execution, but there is no reason to assume immediate reactions or perfect interpretation of vague instructions. Comments should be short, testable, and focused on decisions: what must not change, which test to add, or which option to reject.

It is also not meant for cross-repository operations or forks. Pre-created PR mode is limited to one same-repository pull request per run, and it cannot be combined with target-repo, head-repo, allowed-repos, allowed-branches, allowed-base-branches, or checkout: false. Staged mode does not allocate a PR either, because staged runs must not perform GitHub API side effects.

The pre-created branch belongs to the workflow and uses a name built from a static prefix plus trusted run metadata. That helps reduce risk, but it does not remove the need to review permissions, secrets, and branch-protection rules. I see this feature as useful for agents proposing reviewable changes, not as a way to treat a PR comment as informal approval for deployments or infrastructure administration.

Automation that can still be corrected

The interesting part is not that an agent can open pull requests; plenty of tools already do that. The change is moving the PR to the beginning of the run and making it a channel for intervention while the work is still happening. For a small team, or a personal project with significant automation, that can prevent a technically valid task from becoming the wrong change in practice.

I would begin with a workflow that can only create small changes and has minimal permissions. Then I would review the generated PRs, the steering comments, and the cases where the agent failed to follow the intended direction. If that provides more control without creating review noise, it may be worth applying to more important repository tasks.

Source: Weekly Update – August 24, 2026

Official documentation: Safe Outputs for pull requests · Self-hosted runners