pr-review-loop
Skill0 starsChanged 37 days agoMITView on GitHub
After this session opens a PR in a repo with a .claude/ship-profile.json, wait for its AI review and checks on the self-hosted runners, act on what they and any other comments raise, push, and do that once more; then post that the PR needs human review. Started automatically by the cdr plugin's hook after `gh pr create`; also `/cdr:pr-review-loop <PR#>`.
- Commits and pushes
18 other projects use a version of this.
Adopted by
Most recently taken up by
- ksprashu/agent-skill-forgetheir own version, first seen Nov 8, 2026
- tloncorp/tlon-appstheir own version, first seen Nov 2, 2026
- gabonio/agent-operator-toolkittheir own version, first seen Nov 1, 2026
- wollemiahq/skillstheir own version, first seen Nov 1, 2026
- vrodokanakis/claude-skillstheir own version, first seen Oct 25, 2026
- typeweaver/skillstheir own version, first seen Oct 20, 2026
Other versions18 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 18
- basicmachines-co/basic-memory★ 4.5ksame name
- phase-rs/phase★ 323same name
- tloncorp/tlon-apps★ 109same name
- fagemx/gstack-game★ 68same name
- fagemx/edda★ 36same name
- xpepper/pr-review-agent-skill★ 6same name
- GavinGreenwood/agentic-workflow-template★ 5same name
- ksprashu/agent-skill-forge★ 3same name
- adevra/claude-pr-review-loop★ 2same name
- typeweaver/skills★ 2same name
8 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
The file
We split this skill into the rules it gives an agent
5 rules. 0 are common, 3 are distinctive, and 2 are very specific to this project.
0
Common
Most of the 16 edited versions we read keep these.
3
Distinctive
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 12
Read <main checkout>/.claude/ship-profile.json first (the main checkout: dirname of git rev-parse --path-format=absolute --git-common-dir).
- Distinctive: line 23
No profile: say so in one line and stop.
- Very specific: line 47
If the PR merged while you waited (gh pr view <N> --json state), fixes can't go onto it.
- Distinctive: line 50
Triage: every finding the verifier kept and every comment that asks for a change.
- Distinctive: line 60
After round 1, go back to step 1 for round 2.
“Common” is measured: kept by at least 6 in 10 of the 16 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
PR review loop
Two rounds, then a human. Each round: wait, read, act, update the PR. Never a third round.
The profile
Read <main checkout>/.claude/ship-profile.json first (the main checkout: dirname of
git rev-parse --path-format=absolute --git-common-dir). It gives:
repo: owner/name.base: the branch AI review runs on PRs into.review.workflow: the AI review workflow (a reviewer posts findings, a verifier keeps or dismisses each, a bot posts one comment; cdr'spr-reviewskill is one).review.checks: the gates workflow (it may be the same workflow). Both run when a PR intobaseis opened and on every push to it, onreview.runners, so the push that ends round 1 is what starts round 2's review.gates: the commands that must pass before you push (<wt>is the checkout you work in).review.flakes: known flaky failures, which get a rerun, not a code change.
No profile: say so in one line and stop.
Start
gh pr view <N> -R <repo> --json baseRefName,headRefName,createdAt,state. The base must bebase: no AI review runs for a PR into another branch, so for one, skip the loop and say so in one line.- Work in the checkout or worktree that holds the PR's branch (the one it was created from).
- Tell the user one line: "Watching PR #N: review round 1 of 2."
Each round (r = 1, then 2)
- Wait. Run
REPO=<repo> REVIEW_WORKFLOW=<review.workflow> CHECKS_WORKFLOW=<review.checks> ${CLAUDE_PLUGIN_ROOT}/bin/wait-review <N> <since>withrun_in_background: trueandtimeout: 7200000.<since>is the PR'screatedAtfor round 1 and the time you recorded just before round 1's push for round 2. Don't poll: the session is re-invoked when it exits. The runners are shared, so a round can queue behind other PRs.- Exit 0: both runs finished; read on.
- Exit 3: no review run appeared for the head (the runners are down, or the workflow trigger changed). Act on the comments it printed if any, then hand off, and tell the user the review never ran.
- Exit 4: timed out. Hand off, saying so.
- Read its output: the run results and every comment, inline comment and review since
<since>. The AI review comment lists findings with the verifier's verdicts. Apr-reviewcomment starts with<!-- cdr:pr-review verdict=<v> head=<sha> -->:request-changesmeans fix its Required changes,accept-with-suggestionsmeans triage its Suggestions and Uncertain lines,acceptmeans nothing from the review (checks skipped after arequest-changesverdict are not failures). A failed checks run:gh run view <id> -R <repo> --log-failed | tail -200. If the PR merged while you waited (gh pr view <N> --json state), fixes can't go onto it. Open a follow-up PR againstbasefrom the same branch; the hook starts that PR's own loop. Post the hand-off on the merged PR, pointing to the follow-up. - Triage every finding the verifier kept and every comment that asks for a change. Check each against the code yourself: a verdict is not proof. Real: fix it. Not real: decline it, with file:line evidence. If nothing is actionable (no kept findings, no change requests, checks green), stop here and hand off.
- Fix the way the repo does: a regression test shown failing without its fix, one finding per commit, the
profile's
gates.typecheckandgates.testgreen (andgates.smokewhengates.smokeWhenholds), no Claude co-author trailer. A checks failure that matches one ofreview.flakesgetsgh run rerun <id> -R <repo> --failed, not a code change. - Update the PR. Record
date -u +%Y-%m-%dT%H:%M:%SZ(round 2's<since>), then push. Post one PR comment that starts with<!-- pr-review-loop round r -->: what was fixed (with commit) and what was declined (with the reason). Edit the PR body if the fixes change what it says. No Claude attribution in either. - After round 1, go back to step 1 for round 2. After round 2, hand off: don't wait for or act on the review your round-2 push starts.
Hand off
Post a PR comment that starts with <!-- pr-review-loop done --> and leads with Needs human review. Give the
rounds run, what was fixed, what was declined and why, anything still open, and, when round 2 pushed, that a
review of that push is still coming. Then tell the user in chat: "PR #N needs human review", one line on where it
stands, and the link. Never merge.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

