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. 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.
npx skills add https://github.com/spencermarx/open-code-review --skill OCR Review-to-Approval Loop
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.
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)/ocr:review./ocr:address.gh CLI installed and authenticated (for posting; skip with --no-post)..ocr/ exists, ocr CLI available). Run /ocr:doctor if unsure./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).
--max-rounds N (optional): safety cap on review rounds. Default: 5. The loop neverruns 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.> 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
> 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).
1. Review-address loop. Starting at round = 1, while the verdict is not APPROVE and
round <= max-rounds:
/ocr:review (default team, or --team). It runs the full pipelineand finalizes rounds/round-{round}/final.md + round-meta.json with a verdict.
OCR review — Round {round}. *(skip if --no-post)*round-meta.json / final.md):APPROVE → exit the loop (proceed to step 2 below).NEEDS DISCUSSION → STOP the loop. This is a human gate — surface theclarifying questions to the user and await direction. Do not fabricate a fix.
REQUEST CHANGES → continue./ocr:address on rounds/round-{round}/final.md. Corroborate everyitem against the actual code; implement the blockers and should-fixes (these clear the
gate); decline incorrect feedback with evidence; you MAY defer pure suggestions to the
final pass. Verify (typecheck + lint + tests) until green, then commit (atomic,
conventional) and push.
deferred. *(skip if --no-post)*
round += 1; loop.2. Final suggestions pass (only after APPROVE, unless --no-final-suggestions):
invoke /ocr:address once more to clear remaining suggestions, verify, commit, push, and
post a final address comment that includes a loop-summary table (round → verdict → outcome).
3. Stop conditions. If round exceeds max-rounds without APPROVE, stop and report
the outstanding blockers — never loop indefinitely. If APPROVE was reached on round 1, skip the
loop body and go straight to the final suggestions pass.
--max-rounds (default 5). If not approved by then, stop and surface why.NEEDS DISCUSSION is a human gate. Pause and ask; never invent a resolution for genuineambiguity.
.ocr/commands/address.md: verify each finding against thecode; implement valid items; decline wrong feedback with evidence. Don't gold-plate —
fix only what the review actually raised.
failures before pushing.
be fixed (needs a product/architecture decision), stop and say so rather than forcing APPROVE.
(a closed session starts round-{n+1}), reusing discovered-standards.md / context.md.
comment templates** → reference/loop-mechanics.md
/ocr:review,/ocr:address
Interact with Obsidian vaults using the Obsidian CLI to read, create, search, and manage notes, tasks, properties, and more. Also supports plugin and theme development with commands to reload plugins, run JavaScript, capture errors, take screenshots, and inspect the DOM. Use when the user asks to interact with their Obsidian vault, manage notes, search vault content, perform vault operations from the command line, or develop and debug Obsidian plugins and themes.
Comprehensive project architecture blueprint generator that analyzes codebases to create detailed architectural documentation. Automatically detects technology stacks and architectural patterns, generates visual diagrams, documents implementation patterns, and provides extensible blueprints for maintaining architectural consistency and guiding new development.
Securely inspect and automate microscopy data workflows against OMERO.server with omero-py, BlitzGateway, OMERO CLI, tables, annotations, ROIs, rendering, and documented OMERO.web APIs. Use for scoped OMERO inventory, metadata export, import/export planning, or reviewed write workflows.
Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes — Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue/PRD asked for?). Runs both reviews in parallel sub-agents and reports them side by side. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to "review since X".
Master API documentation with OpenAPI 3.1, AI-powered tools, and modern developer experience practices. Create interactive docs, generate SDKs, and build comprehensive developer portals.
Creates comprehensive API changelogs documenting breaking changes, deprecations, and migration strategies for API consumers. Use when managing API versions, communicating breaking changes, or creating upgrade guides.
Master API documentation with OpenAPI 3.1, AI-powered tools, and modern developer experience practices. Create interactive docs, generate SDKs, and build comprehensive developer portals. Use PROACTIVELY for API documentation or developer portal creation.
Analyze fundamental data primitives, type systems, and state management patterns in a codebase. Use when (1) evaluating typing strategies (Pydantic vs TypedDict vs loose dicts), (2) assessing immutability and mutation patterns, (3) understanding serialization approaches, (4) documenting state shape and lifecycle, or (5) comparing data modeling approaches across frameworks.
Take spencermarx/ocr review-to-approval loop from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.