/ocr-review-loop

name: "OCR Review-to-Approval Loop"
description: "Drive a PR to an approved code review by looping OCR's multi-agent review and address steps. Runs /ocr:review then /ocr:address repeatedly until the review verdict is APPROVE, then one final /ocr:address for leftover suggestions, posting every review and every address round to the GitHub PR as comments with machine-readable markers. This is the pre-review CONTRIBUTING.md requires before maintainer review (APPROVE verdict, at least 2 distinct personas, covering the PR head). Use when the user asks to 'review and address in a loop', 'iterate review until approved', 'auto review-and-fix this PR', 'loop /ocr:review and /ocr:address', or to take a changeset all the way to a clean APPROVE with the default reviewer team. Wraps the /ocr:review (.ocr/commands/review.md) and /ocr:address (.ocr/commands/address.md) skills; needs a feature branch with an open GitHub PR and the gh CLI for posting."

OCR Review-to-Approval Loop

What This Skill Does

Orchestrates an autonomous **review → address → re-review** loop on a pull request, using OCR's existing multi-agent review pipeline, until the review reaches an **APPROVE** verdict — then runs one final address pass for leftover suggestions. Every review and every address round is posted to the GitHub PR as a comment, producing a transparent, reviewable audit trail.

In this repo the loop is **required before maintainer review** (CONTRIBUTING.md → "Required: OCR review loop before maintainer review"). Each posted comment carries a hidden marker that the `ocr-review-gate` workflow reads to decide whether the PR keeps its `needs-ocr-review` label. The policy needs: the latest review verdict is APPROVE, the team had **at least 2 distinct personas** (3+ encouraged), and the PR's **current head commit** is the one that APPROVE review covered, or the one pushed by an address pass posted after it (normally the final pass, `round=final`).

It is a thin **orchestrator** over two skills it does not reimplement:

• **`/ocr:review`** → `.ocr/commands/review.md` (the 8-phase multi-agent review that emits a verdict)
• **`/ocr:address`** → `.ocr/commands/address.md` (corroborate feedback against code, then implement)

When to Use

• "Review and address in a loop until it's approved."
• "Iterate /ocr:review and /ocr:address on this PR."
• "Auto review-and-fix PR #N to a clean approval."
• Getting a PR ready for maintainer review under the contribution policy.

When NOT to Use (use the underlying skills directly)

• A **single** review with no auto-fixing → `/ocr:review`.
• Addressing **one** existing review's feedback → `/ocr:address`.
• There is no PR / not on a feature branch (this skill commits and posts).

Prerequisites

• On a **non-default** git branch with an **open GitHub PR** (the loop commits + pushes each round).
• `gh` CLI installed and authenticated (for posting; skip with `--no-post`).
• OCR set up in the repo (`.ocr/` exists, `ocr` CLI available). Run `/ocr:doctor` if unsure.
• A clean working tree. If there are uncommitted or untracked changes, **ask the user** whether

they belong in the PR before committing anything; never `git add -A` blindly, since this skill pushes to a public PR.

Arguments

/ocr-review-loop [pr] [--team <spec>] [--max-rounds N] [--no-final-suggestions] [--no-post]

• `pr` (optional): PR number. Default: the open PR for the current branch.
• `--team <spec>` (optional): reviewer team override (`reviewer-id:count,...`), forwarded to

`/ocr:review`. **Default: the project's default team** (`ocr team resolve`). Must contain at least 2 distinct personas; 3+ encouraged, e.g. `principal:2,quality:2,security:1`.

• `--max-rounds N` (optional): safety cap on review rounds. **Default: 5.** The loop never

runs forever.

• `--no-final-suggestions` (optional): stop at APPROVE; skip the final suggestions pass.
• `--no-post` (optional): run locally; do not post to GitHub. Present the trail in-chat instead.

This leaves no evidence on the PR, so it does **not** satisfy the contribution policy.

---

The Loop (core algorithm)

> Execute this inline, to completion, in the conversation. Do not schedule across turns or > background the work. Drive each review's phases 4→7 within one turn (OCR's "don't strand > the pipeline" rule). See `reference/loop-mechanics.md` for the exact CLI/session details, > the marker formats, and the GitHub comment templates.

**0. Preconditions.** Resolve the PR and branch; refuse to run on the default branch. Confirm `gh` (unless `--no-post`) and OCR setup. Resolve the reviewer team (default unless `--team`) with `ocr team resolve [--team "<spec>"] --json`, which returns `[{persona, instance_index, name, model}]`, and count the **distinct `persona` values**. **If there are fewer than 2, STOP** before reviewing and explain the policy: the loop needs at least 2 distinct personas (e.g. `--team principal:2,quality:2`, which is the default), and 3 or more are encouraged (e.g. `--team principal:2,quality:2,security:1`). Instance counts don't help (`principal:3` is still one persona), and ephemeral `--reviewer` personas don't count because they have no persona id.

**1. Review-address loop.** Count iterations with a local `iteration` (starting at 1, capped by `max-rounds`). The **round number** used in file paths and markers is OCR's own (`round-{n}` in the session), which continues across same-day re-runs, so never assume it equals `iteration`. While the verdict is not `APPROVE` and `iteration <= max-rounds`:

1. **Push, then review the whole PR** — make sure the tree is clean (ask before committing anything the loop didn't produce), `git push`, and confirm the PR's head SHA equals local `HEAD` (retry once if GitHub hasn't caught up), so the reviewed commit is the PR's commit. Record that full 40-hex SHA. Invoke `/ocr:review` with the **full PR range as the target**: the PR's base commit (`baseRefOid`, fetched so it exists lo