Local PR Review

Premise

A code review must be anchored to expectations. Those expectations come from:

• Explicit intent sources (PR description, linked tickets, design docs) when available, plus
• A canonical spec file (author-provided in-repo on the branch when available, otherwise a review spec.md you write) to make expectations explicit and reviewable.

You do not change implementation code. You only write review artifacts.

Subagent permissions (load-bearing)

Each pass is implemented as a delegated subagent with its own persona load. Subagents must be launched with write access so they can persist their artifact directly. The "do not change implementation code" rule above is a content constraint on the work, not a capability constraint on the agent — the artifact files are repo-relative writes the subagent must perform.

Concretely: when delegating via the Task tool (or equivalent), do not set readonly: true on review-pass subagents. A read-only subagent will complete the substantive analysis but be unable to write the artifact, forcing the orchestrator to extract content from the subagent transcript — slow, lossy, and a recurrent footgun. The orchestrator's own discipline (no implementation edits) is enforced by the workflow shape, not by sandbox restriction on the writing agent.

If a pass fails for budget reasons (resource_exhausted or token-budget overrun), prefer one of: (a) re-launch with a tightened prompt that leans on already-landed sibling artifacts (code-review.md, system-design-review.md) rather than re-deriving them; (b) execute the pass inline in the orchestrator session, since the orchestrator typically already carries the canonical context loaded.