Prerequisites
This workflow assumes:
- changes enter production through pull requests;
- the default branch can require checks and review;
- tests can run from a documented command; and
- releases have a known rollback or containment path.
GitHub documents required reviews, status checks, conversation resolution, and other controls in protected branches. Exact features depend on repository settings and plan. The gate below is platform-independent policy.
Require seven fields
Place this template in every agent-written pull request:
Human owner:
Outcome and non-goals:
Risky boundaries touched:
Diff budget and exceptions:
Reproduction commands:
Failure signals:
Rollback or containment:
The human owner is not the person who clicked “merge.” The owner has inspected the changed paths, can state why each class of change exists, and accepts the release decision.
Gate the diff before the tests
First inspect scope:
git diff --stat origin/main...HEAD
git diff --name-status origin/main...HEAD
git diff --check origin/main...HEAD
These commands are illustrative and should be reviewed for the repository's branch model. Fail the gate when unrelated generated files, secrets, dependency locks, migrations, infrastructure, or permission code appear without an explicit reason.
A diff budget is not a universal line limit. It is the expected set of files and change classes. Expansion pauses the review and either narrows the patch or updates the risk statement.
Run checks from a clean state
The pull request must name exact commands and tested environment assumptions. Run them from a clean checkout or CI worker, not only the agent's modified workspace. Include dependency installation, static checks, unit tests, build, and one behavior-level check appropriate to the change.
Record the failing command and output location. “CI failed” is not a useful failure signal if the owner cannot tell which gate rejected the patch.
Review boundaries agents often cross
Require explicit review when the diff changes:
- authentication or authorization;
- tenant or customer scoping;
- schema or data migration;
- file handling;
- secrets or environment configuration;
- third-party API behavior;
- infrastructure or deployment;
- logging or retention; or
- a destructive operation.
Passing tests do not prove these boundaries safe. They prove only the named cases passed in the named environment.
Attach recovery to the change
The pull request should say whether recovery means reverting code, disabling a flag, restoring data, applying a forward fix, or stopping a worker. If a migration is not backward-compatible, a source revert may make the incident worse.
For high-consequence changes, rehearse the recovery outside production and record the result. If recovery has not been tested, state that limitation.
Merge decision
The gate passes only when:
- the human owner is named;
- the diff matches its declared boundary;
- reproducible checks pass from clean state;
- material risks have a review owner;
- failure signals are observable; and
- recovery is specific to the change.
This process does not certify generated code. It converts an agent's output into a bounded proposal that an accountable developer can accept or reject.