Review loop

Orchestrator supports two complementary review loops: observing feedback already posted on a claimed GitHub PR, and launching an Orchestrator reviewer agent against a worker's PR.

Start with a worker session that has a linked PR and a current head. Open that worker, then use the inspector's Reviews section. The reviewer runs against the worker's PR; it is not the worker agent and does not own the worker's branch. Use the Dashboard review controls to find the PR summary, review status, and Files view.

GitHub feedback

The SCM observer records review state and unresolved comments. When changes are requested or unresolved feedback changes, lifecycle sends the focused unresolved comments to the owning worker. Resolved threads drop out of the next message.

Delivery follows the session interface:

• Chat receives a durable provider turn in the conversation.
• Terminal UI receives the message through the running agent session.

Feedback is signature-deduplicated. Orchestrator does not repeat an unchanged comment set on every poll.

If feedback does not arrive, confirm the PR is claimed by this worker, the repository host is authenticated, and the comment remains unresolved on the current head. A claim records ownership but does not check out the PR branch. Read the linked review on GitHub or GitLab before asking the worker to act on an older comment.

Orchestrator reviewer agents

Select reviewers independently in project settings; the agent catalog distinguishes reviewer support from worker and Chat support. Without an explicit reviewer, Orchestrator reviews with the project's default worker agent and its model when that agent is Claude Code, Codex, OpenCode, Muse, or Kimchi; otherwise it inherits one of those from the worker, or falls back to Claude Code. Other reviewer harnesses must be selected explicitly.

From the desktop, open the worker and use the Reviews section in the inspector. From the CLI:

ao review trigger <worker-session-id>
ao review ls <worker-session-id>
ao review cancel <worker-session-id>

Reviewer runs are separate from worker sessions. Their verdict and body are recorded against the worker.

Reviews requested by agents

A worker can request a review of its own PR: inside the worker, ao review trigger reviews the calling session. An orchestrator runs ao review trigger <worker-session-id> instead of spawning a worker to review. These runs are labelled Requested by agent in the inspector.

• The project setting Workers request Orchestrator review (workersRequestReview) tells new workers to request a review once their PR is ready and again after each fix. When it is off, workers ask the user or orchestrator first.
• A head that already has a review, or a review still running, is not reviewed again; the command says so. --rerun reviews the same commit again, and with a different --agent it adds a reviewer that runs alongside the first. Each live reviewer can be opened from the inspector.
• The command turns on the session's review auto-inject unless --no-inject is passed. The reviewer posts an inline comment for each change it requires; with auto-inject on, Orchestrator forwards those comments to the worker like any other review comments. Optional suggestions stay in the review summary. An approval adds no comments, so the worker checks ao review ls for the verdict. Orchestrator's approval is never a GitHub approval.

In the inspector, choose the reviewer harness (and offered model/mode), start the run, then open its Chat or terminal surface. Read the result, then use Send to worker agent in the review actions to send its findings to the worker. A reviewer harness can have different permissions from the worker; an experimental reviewer is not automatically sandboxed. If the trigger is unavailable, check the linked PR, reviewer readiness, and the reason shown by the UI. ao review ls shows the run state; ao review cancel stops a run that should not continue.

Enable automatic review per session, or use the project autoReview default for future workers. It starts only for an eligible PR head while the worker is idle. In Files, inspect workspace or PR changes and available commits; local inspection does not automatically publish a review. The mobile review and reviewer views expose the corresponding session results.

Best practices

• Keep the PR claimed by the worker that should act on feedback.
• Resolve addressed GitHub threads so later nudges contain only remaining work.
• Use inline comments for localized changes and a top-level review body for design-level feedback.
• Inspect the current PR head before replaying old feedback after a force-push.

Approval and merge

An Orchestrator reviewer result is not the same as a human or repository-host approval. Inspect remaining GitHub/GitLab threads and branch protection before requesting merge. Automatic review starts only on an eligible PR head while the worker is idle; it does not approve or merge by itself.

Approval plus passing checks contributes to merge readiness. Orchestrator creates a durable merge-ready notification but does not automatically merge from a reaction rule. Merge explicitly in the desktop or with:

ao pr merge <pr-number> --url <pr-url> --expected-head-sha <sha>

Resolve review comments explicitly when appropriate:

ao pr resolve-comments <pr-number> [comment-id...]

Current limits

There is no ao review-check command, configurable review polling throttle, bugbot-comments reaction, or YAML retry budget in the current rewrite. GitHub and GitLab have SCM observation; this page's thread-resolution examples describe GitHub. Provider review semantics differ, so inspect the repository host when an action is unavailable.