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

A developer published an auto-review-loop skill for Claude Code that periodically polls a GitHub repository for open, non-draft pull requests requesting the user's review, runs a /review skill on each to produce an approve or reject verdict, and bare-approves the ones that pass while handing rejects back to the user. The loop tracks each PR by number and head SHA in a local log (~/.claude/pr-autoreview.log), giving freshly pushed commits one interval of breathing room before review and re-reviewing returning commits without ever auto-approving them. When HERDR_ENV=1, it spawns one Herdr agent per PR in split panes to run reviews in parallel; otherwise it runs the reviews directly and can launch optional finding-verifier agents to check findings.

| name | auto-review-loop | |---|---| | description | Use when the user types /auto-review-loop, or asks to start, restart or run the recurring loop that reviews the PRs in a repo that request their review and auto-approves the good ones. Also use when they ask to post the comments for a PR that loop rejected. | 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. 1. 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 with date -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 SHA fresh The developer is still pushing. Append a new seen line and skip it again.Latest line is seen with the same SHA new 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 , named rev<number . Load the herdr 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 with herdr 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 the code-review forks in parallel and launch the finding-verifier agents in one message. 4. 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 exactly gh 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 , and gh 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. 5. 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 the pane 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" and comments: {path, line, side: "RIGHT"} . A range also gets start line and start 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.