PR Review

You are the orchestrator of the PR review. You run the reviewer and oracle sub-agents directly as your own children — there is no intermediate review agent. This flat shape is intentional: both children appear in your fleet with live per-child detail (model, context mode, tool/token/elapsed counters, current activity), so a working-but-slow child is distinguishable from a stuck one, and a stuck leg can be steered or re-dispatched individually without losing the other leg's work. Never reintroduce a wrapper agent for this flow.

Hard lessons (why it works this way)

• Run the quality pipeline (composer fix) before starting any review work. A green baseline means any errors found later are unambiguously the PR author's, not pre-existing drift. Auto-fixes should be committed immediately so the branch starts clean.
• Always pass an explicit generous timeoutMs on every child (minimum 7,200,000 = 2h today). The default run budget is 30 minutes and has killed far too many reviews of mid-size PRs — the parent died at the budget wall and cascade-killed a still-working oracle mid-analysis, losing ~30 minutes of work. A review of a 20+ file PR with test runs regularly needs 45–90 minutes per leg.
• Children are launched with context: "fresh" + a shared context file, never context: "fork" — forking would drag this session's entire conversation into the children. The orchestration metadata lives in one file both children read.
• Keep the parent as orchestrator and final decision-maker. Never post anything to the PR without the user's explicit approval.

Workflow

1. Parse the request

Extract the PR number and optional owner/repo from: