ocr-review-loop
starsforks
How to install ocr-review-loop?
spencermarx/open-code-review/ocr-review-loop
$npx -y skills add spencermarx/open-code-review --skill ocr-review-loopDrive 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 th
SKILL.md
| 1 | # OCR Review-to-Approval Loop |
| 2 | |
| 3 | ## What This Skill Does |
| 4 | |
| 5 | Orchestrates an autonomous **review → address → re-review** loop on a pull request, |
| 6 | using OCR's existing multi-agent review pipeline, until the review reaches an **APPROVE** |
| 7 | verdict — then runs one final address pass for leftover suggestions. Every review and every |
| 8 | address round is posted to the GitHub PR as a comment, producing a transparent, reviewable |
| 9 | audit trail. |
| 10 | |
| 11 | It is a thin **orchestrator** over two skills it does not reimplement: |
| 12 | - **`/ocr:review`** → `.ocr/commands/review.md` (the 8-phase multi-agent review that emits a verdict) |
| 13 | - **`/ocr:address`** → `.ocr/commands/address.md` (corroborate feedback against code, then implement) |
| 14 | |
| 15 | ## When to Use |
| 16 | |
| 17 | - "Review and address in a loop until it's approved." |
| 18 | - "Iterate /ocr:review and /ocr:address on this PR." |
| 19 | - "Auto review-and-fix PR #N to a clean approval." |
| 20 | |
| 21 | ## When NOT to Use (use the underlying skills directly) |
| 22 | |
| 23 | - A **single** review with no auto-fixing → `/ocr:review`. |
| 24 | - Addressing **one** existing review's feedback → `/ocr:address`. |
| 25 | - There is no PR / not on a feature branch (this skill commits and posts). |
| 26 | |
| 27 | ## Prerequisites |
| 28 | |
| 29 | - On a **non-default** git branch with an **open GitHub PR** (the loop commits + pushes each round). |
| 30 | - `gh` CLI installed and authenticated (for posting; skip with `--no-post`). |
| 31 | - OCR set up in the repo (`.ocr/` exists, `ocr` CLI available). Run `/ocr:doctor` if unsure. |
| 32 | - A green-ish working tree: any uncommitted changes will become part of what is reviewed. |
| 33 | |
| 34 | ## Arguments |
| 35 | |
| 36 | ``` |
| 37 | /ocr-review-loop [pr] [--team <spec>] [--max-rounds N] [--no-final-suggestions] [--no-post] |
| 38 | ``` |
| 39 | |
| 40 | - `pr` (optional): PR number. Default: the open PR for the current branch. |
| 41 | - `--team <spec>` (optional): reviewer team override (`reviewer-id:count,...`), forwarded to |
| 42 | `/ocr:review`. **Default: the project's default team** (`ocr team resolve`). |
| 43 | - `--max-rounds N` (optional): safety cap on review rounds. **Default: 5.** The loop never |
| 44 | runs forever. |
| 45 | - `--no-final-suggestions` (optional): stop at APPROVE; skip the final suggestions pass. |
| 46 | - `--no-post` (optional): run locally; do not post to GitHub. Present the trail in-chat instead. |
| 47 | |
| 48 | --- |
| 49 | |
| 50 | ## The Loop (core algorithm) |
| 51 | |
| 52 | > Execute this inline, to completion, in the conversation. Do not schedule across turns or |
| 53 | > background the work. Drive each review's phases 4→7 within one turn (OCR's "don't strand |
| 54 | > the pipeline" rule). See `reference/loop-mechanics.md` for the exact CLI/session details |
| 55 | > and the GitHub comment templates. |
| 56 | |
| 57 | **0. Preconditions.** Resolve the PR and branch; refuse to run on the default branch. Confirm |
| 58 | `gh` (unless `--no-post`) and OCR setup. Resolve the reviewer team (default unless `--team`). |
| 59 | |
| 60 | **1. Review-address loop.** Starting at `round = 1`, while the verdict is not `APPROVE` and |
| 61 | `round <= max-rounds`: |
| 62 | |
| 63 | 1. **Review** — invoke `/ocr:review` (default team, or `--team`). It runs the full pipeline |
| 64 | and finalizes `rounds/round-{round}/final.md` + `round-meta.json` with a `verdict`. |
| 65 | 2. **Post the review** to the PR, headed `OCR review — Round {round}`. *(skip if `--no-post`)* |
| 66 | 3. **Gate on the verdict** (read it from `round-meta.json` / `final.md`): |
| 67 | - **`APPROVE`** → exit the loop (proceed to step 2 below). |
| 68 | - **`NEEDS DISCUSSION`** → **STOP the loop.** This is a human gate — surface the |
| 69 | clarifying questions to the user and await direction. Do **not** fabricate a fix. |
| 70 | - **`REQUEST CHANGES`** → continue. |
| 71 | 4. **Address** — invoke `/ocr:address` on `rounds/round-{round}/final.md`. Corroborate every |
| 72 | item against the actual code; implement the **blockers and should-fixes** (these clear the |
| 73 | gate); decline incorrect feedback with evidence; you MAY defer pure **suggestions** to the |
| 74 | final pass. **Verify** (typecheck + lint + tests) until green, then **commit** (atomic, |
| 75 | conventional) and **push**. |
| 76 | 5. **Post the address round** to the PR: what was addressed, declined (with reasoning), and |
| 77 | deferred. *(skip if `--no-post`)* |
| 78 | 6. `round += 1`; loop. |
| 79 | |
| 80 | **2. Final suggestions pass** (only after `APPROVE`, unless `--no-final-suggestions`): |
| 81 | invoke `/ocr:address` once more to clear remaining **suggestions**, verify, commit, push, and |
| 82 | post a final address comment that inc |
People who liked this also viewed
6 picksType
- tddSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- test-driven-developmentUse when implementing any feature or bugfix, before writing implementation codeSkillsJul 2026
- qaSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- verification-before-completionUse when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidenceSkillsJul 2026
- webapp-testingToolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser lSkillsJul 2026
- playwright-best-practicesUse when writing Playwright tests, fixing flaky tests, debugging failures, implementing Page Object Model, configuring CI/CD, optimizing performance, mocking APIs, handling authentication or OAuth, teSkillsJul 2026
