When several agents open pull requests at once, the same reviewer should not look at a docs fix and a database migration in the same way. Routing sorts each pull request into a lane, so the small safe ones move fast and the risky ones get the attention they need.
overlane pr route --number 7 --ci passed --secret-scan passed --guardrails passed --conflict passed --review-done
overlane pr approve --number 7 --evidence "read the diff" --evidence "ran the tests" --reason "inside the task scope"
overlane pr batchThe four lanes
| Lane | When | Approval needed |
|---|---|---|
blocked |
Any check is not clean | Nothing counts yet. Fix the check, then route again. |
fast |
Low risk, checks clean | An independent agent’s approval with evidence, or a person. |
standard |
Medium risk | The same, and the review run must have finished for this head. |
approver |
High risk or a sensitive path | The configured approver, and the review run must have finished. |
Checks come first
Five checks are read before anything else: CI, the secret scan, the guardrails check, the merge conflict check (see claims) and unresolved critical review findings. If any one is not passed, the pull request is blocked, whatever its size. A check you do not report counts as missing, and missing blocks too, so a forgotten check cannot let a change through. A blocked route exits 6 and names the first blocker’s next command.
How risk is decided
Risk comes from the shape of the diff, with no model:
- Sensitive paths force the approver lane. Authentication and identity code, billing and payments, database migrations, CI workflows, secrets and key files, and infrastructure files (Wrangler, Docker, Terraform). A 12-line change under
migrations/is approver lane. A page of documentation about billing is not billing code. - Size. More than 200 changed lines or 12 files is medium. More than 1000 lines or 40 files is high.
- Source code. More than 50 changed lines of source is medium. Documentation-only and tests-only changes are low.
- A fork is at least medium.
The optional model label
If the team switched on the review_risk decision (it is off by default, see models in review), a decision model labels the change low, medium or high, after the checks, and only when the lane can still rise. The label follows three rules:
- It can raise a lane: a high label moves a fast-path change to the approver lane.
- It never lowers one. A low label leaves a standard route standard.
- It never approves. An unsure or failed answer keeps the deterministic route and the route records why.
When the checks block the pull request, or the change is already in the approver lane, the model is not asked at all. Every decision is recorded through the decision port like any other use.
Approvals
overlane pr approve records one approval for one head commit. After a push, route again and approve the new head; an approval for an old head does not count.
- An agent’s approval needs evidence (the checks it made) and a reason. It is refused when the approver is the author, or shares the author’s token lineage, run or lease. Pass
--author-tokentopr routewhen an agent opened the pull request, so its own approval is refused. - A person’s approval needs neither.
- The approver lane accepts a person the project lists as an approver, or one holding a role the project names as an approver role (set with
overlane pr policy). A project can also allow an independent agent with evidence there:overlane pr policy --allow-agent-approver. - A decision model’s label is never an approval.
Every attempt is stored, accepted or refused, with the reason.
Batching
overlane pr batch groups related pull requests so one reviewer looks once: the same task, overlapping claimed scope, or one stacked on another. Only pull requests in the same lane join a batch, a blocked one never does, and a batch is capped at the project’s size (5 by default, --max-batch to change). A batch approves nothing; each pull request is approved at its own head.
Native and GitHub pull requests
The same commands work for both. The change is read from your checkout with git, so a native pull request needs no GitHub account.
Agent use and the override
An agent routes the pull request it opened, asks a second agent to review it, and merges once the lane is satisfied. A person can approve any lane they hold the role for, change who the approver is, and can always read the stored routes and attempts.
Command reference: pr route, pr approve, pr batch and pr policy.