Claude Code Auto Review Loop (uses herdr and /review)

Reviews every open, non-draft PR in one GitHub repo that requests the user's review. Bare-approves the good ones. Hands rejects to the user. Nothing else reaches GitHub unless the user asks for it in their own words.

Requires a /review <number> skill that prints an approve or reject verdict. The finding-verifier agent is optional: the review skill may use it to check findings.

Args, both optional, in any order: an interval (default 30m) and an owner/repo. If no repo is given, use the repo of the current folder: gh repo view --json nameWithOwner -q .nameWithOwner. Fill <owner/repo> below with that value. Then invoke the loop skill with <interval> followed by the tick prompt, verbatim. The loop skill schedules the job and runs the first tick now.

Tick prompt:

Run the auto-review-loop skill tick: review the new PRs in <owner/repo> that request my review.

Every <owner/repo> below means the repo named in the tick prompt.

List the PRs:

gh pr list --repo <owner/repo> --search "is:open draft:false user-review-requested:@me" --json number,headRefOid,url

Log: ~/.claude/pr-autoreview.log , one line per event:<number> <sha> <seen|approve|reject|followup> <time> . Write<time> withdate -u +%FT%TZ . Older lines may have a date only. Read those as the start of that day.Sort each PR by its latest log line for that number. Ignore seen lines when you check whether a number "is in the log", except in the first two rows:Log state Kind What happens Number not in the log at all fresh Append a seen line and skip it. This gives the developer one interval of breathing room.Latest line is seen with a different SHAfresh The developer is still pushing. Append a new seen line and skip it again.Latest line is seen with the same SHAnew Full review (step 3). It can be approved. Number in the log with a different SHA returning Full review (step 3), plus the follow-up check. Never approved. Number+SHA in the log same commit Look for comments or reviews by anyone other than the user that are newer than the latest log time. If there are none, skip it silently. If there are some, run the follow-up check only, with no code review. A reject the user has not posted still requests their review, so it lists again on every tick. The "newer than the latest log time" test keeps it quiet until someone does something. 2. If nothing needs work, say so in one line and stop. 3. Review every new and returning PR in parallel:

• If HERDR_ENV=1: start one Herdr agent per PR (--kind claude , namedrev<number> ). Load theherdr skill for the commands. Before you split panes, check the layout: split right once, then split down. Send each agent this prompt:

/review <number>

Rules: read-only on GitHub. Do NOT run gh pr review, gh pr comment, gh pr edit, gh pr merge, any gh api write, or pass --comment to anything. Do not check out branches or edit the working tree. When done, write your full final review reply (verdict first) to <scratchpad>/review-<number>.md, then reply with exactly one line: VERDICT <approve|reject> <one-line reason>.

Wait withherdr agent wait rev<n> in a background Bash call. A wait can return at once if the agent has not started working yet, so confirm that the review file exists before you read the verdict.

• Otherwise: run/review <number> yourself for each PR. Run thecode-review forks in parallel and launch thefinding-verifier agents in one message.

For each result, first check that the PR head SHA has not changed ( gh pr view <n> --json headRefOid ). If it changed, skip the PR. The next tick picks it up.

• New PR, approve: run exactlygh pr review <number> --approve , with no body.
• New PR, reject: copy the full review to~/pr-reviews/<number>.md . Send a PushNotification with the PR link and the one-line reason.
• Returning or same commit: never approve. Do the follow-up check:
  1. Read the conversation. These reads are allowed: gh pr view <n> --comments --json comments,reviews , andgh api repos/<owner/repo>/pulls/<n>/comments for line comments.
  2. Find the user's earlier points. Use their review comments on GitHub and the earlier ~/pr-reviews/<n>.md .
  3. For each point, say whether the developer replied and what they said. If there is a new commit, also say whether the new code fixes it.
  4. Add the new review's verdict, if one ran.
  5. Save it to ~/pr-reviews/<number>-followup.md .
  6. Send a PushNotification: Follow-up #<n> <link>: <x> of <y> points fixed, <short note> .
• Read the conversation. These reads are allowed:
• Then append the log line. A returning or same-commit PR gets followup as its verdict.

After you have handled every result, close each Herdr pane you made this tick with herdr pane close <pane_id> , using the pane IDs from thepane split results. Do not reuse review agents across ticks, because old context leaks into new reviews. Close only panes you made. Report a short table: PR, verdict, reason.

You run the approvals yourself, in the main thread. Agents never write to GitHub.

The user may later ask to post the rejection comments as if they wrote them. Do this:

1. Find which finding lines are in the PR diff (gh pr diff <n> , then map the hunks to new-file line numbers). GitHub accepts inline comments only on lines that are in the diff.
2. Show the plan first: each comment, the file:line it goes on, and any finding that has no line it can go on. Wait for the user's "post".
3. Post one review per PR from the user's gh login: The payload has

gh api -X POST repos/<owner/repo>/pulls/<n>/reviews --input payload.json

commit_id (the head SHA),event: "REQUEST_CHANGES" andcomments: [{path, line, side: "RIGHT"}] . A range also getsstart_line andstart_side .

• Put only inline line comments in the review. Do not add a filler summary such as "Requesting changes for the items below."
• Use body only for findings that have no line in the diff. Name their file and line in the text.
• If GitHub refuses an empty body , tell the user before you add any text.
• Write comments in plain words, as the user. Do not mention Claude and do not add AI attribution.

4. Posting on request does not change the loop's rule. The ticks still post bare approvals only.