From review-skills
Use when you are the author of a pull request and want a managed, multi-round review loop — you have a branch ready for review and want to open the PR and handle reviewer feedback round by round until it converges. Triggers: "open a PR and get it reviewed", "respond to the review", running a converging review cycle as the author. Pairs with the review-pr skill (the reviewer half). Requires an authenticated `gh` CLI.
How this skill is triggered — by the user, by Claude, or both
Slash command
/review-skills:request-pr-reviewThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
This is one half of a paired, multi-round PR review workflow. **This skill is the
This is one half of a paired, multi-round PR review workflow. This skill is the
author/implementer. The reviewer runs review-pr in a separate session. The two
sessions converge through the PR and never communicate directly.
Core principle: respond to review with technical rigor — verify before implementing, push back when the reviewer is wrong, never perform agreement.
| You run this | in the session that owns the branch |
| Reviewer runs | review-pr in a separate session you trigger |
| Channel | the PR only — see Wire protocol |
| Counterpart skill | review-pr |
gh pr comment <PR> --body "…" — an issue comment whose
body ends with a turn marker:
<!-- review-loop:implementer round=N done=true|false -->.
done=false — you pushed changes (or are still answering blocking findings);
the reviewer should look again. Use it on every changes-requested rebuttal
and on any post-approval rebuttal that carries new commits.done=true — you are finished and intend no further changes. Post it only
when the latest reviewer verdict is approved. It is your convergence signal:
it releases the reviewer to disarm.COMMENT reviews tagged <!-- review-loop:reviewer round=N -->,
each ending with a verdict trailer:
<!-- review-verdict: {"verdict":"approved","round":N,"blocking":0,"nits":0} -->.
A single GitHub account cannot --approve its own PR, so the verdict is a marker.approved (no blocking findings — provisional, not the end
of the loop), escalated (the reviewer stopped without convergence — see Exit),
or changes-requested. A reviewer review with no parseable verdict trailer
counts as changes-requested.Each side numbers its own posts from 1. Your round number = 1 + the count of
existing review-loop:implementer turn markers on the PR. Your rebuttal N
answers reviewer review N.
gh pr view --json number,url,state.git push -u origin HEAD.gh pr create --fill — always --fill; bare gh pr create opens an
interactive editor, which is unsupported here. (--fill derives title/body
from the commits.) If gh reports no commits / no diff vs. the base branch,
stop and tell the user — there is nothing to review.review-pr <number> in
another session. The user may be away — make the message self-contained.--once: if a reviewer review already exists, respond to it once (steps
5–8) and stop; if none exists, stop here. Otherwise arm the Monitor — once.The Monitor runs for the whole loop and emits one line per new reviewer review — do not re-arm it. On each notification, finish any in-progress round first, then:
"verdict":"escalated" → the reviewer has stopped without convergence; do
not respond or keep waiting — go to Exit without convergence;"verdict":"approved" → all blocking findings are clear, but the review may
carry nits and the loop is not closed yet — go to Respond to approval;changes-requested, or no parseable trailer) → triage and respond
(steps 6–8); your rebuttal's turn marker carries done=false.reference/feedback-triage.md before triaging — it carries the
feedback-reception discipline this step depends on. For each point:
address review feedback (round N); git push.gh pr comment ending in your turn marker
<!-- review-loop:implementer round=N done=false -->:
approved clears every blocking finding, but its nits are unaddressed and the
loop stays open until you post done=true. This is a branch off step 5 — do
not jump straight to Converged.
reference/feedback-triage.md first — verifying each against the code and
pushing back on the unsound ones.done=true.address review nits (round N) (commit + push as in step 7), then
git push, then post a rebuttal whose turn marker is
<!-- review-loop:implementer round=N done=false --> (Fixed/Skipped
sections as in step 8). Keep monitoring — the reviewer re-reviews the new
commits, then re-approves (or flags a regression). On the next approved,
return to Respond to approval; on changes-requested, triage and
respond via steps 6–8.Post the converge comment — it must end with a done=true turn marker,
which is the signal that releases the reviewer:
Converged at round N — all blocking items resolved; nits triaged.
<!-- review-loop:implementer round=N done=true -->
(N = 1 + the count of existing review-loop:implementer turn markers.) Then
TaskStop the Monitor (use the task id captured when you armed it).
Notify the user with a round-by-round summary, then surface — do not run — the primed merge command:
gh pr merge <PR> --squash --delete-branch
Run it only on the user's explicit go-ahead. Never auto-merge.
Stop, TaskStop the Monitor, and escalate to the user — stating the open
disagreement and what each side last said — when either:
"verdict":"escalated" (the reviewer hit its own cap
or a stalemate); orchanges-requested reviews without reaching an
approved verdict (stop after posting that 5th rebuttal). Post-approval
done=false rounds do not count toward this cap — once the reviewer has
approved, converge via done=true rather than escalating.Arm this once as a persistent Monitor (persistent: true). It tracks state in
its own loop and survives every round — do not re-arm it. Capture the returned
task id for TaskStop at convergence.
PR=<number>; seen=0
while true; do
body=$(gh pr view "$PR" --json reviews --jq '.reviews[].body' 2>/dev/null || true)
r=$(echo "$body" | grep -oP 'review-loop:reviewer round=\K[0-9]+' | sort -n | tail -1 || true)
if [ -n "$r" ] && [ "$r" -gt "$seen" ]; then
v=$(echo "$body" | grep -oP 'review-verdict: \K\{[^}]*\}' | tail -1 || true)
echo "reviewer round $r verdict: ${v:-MISSING}"; seen="$r"
fi
sleep 30
done
Each emitted line is your cue to triage and respond — unless the verdict is
approved, in which case go to Respond to approval.
request-pr-review --once — open the PR (if needed) and respond to the current
review once, without arming the Monitor. If the current review is approved,
run Respond to approval once (triage nits, then converge with done=true or
post a done=false rebuttal). If no review exists yet, it just opens the PR.
approved as the finish line. approved only clears blocking
findings; the loop closes when you post done=true. Triage the nits first.Guides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.
npx claudepluginhub jowch/review-skills --plugin review-skills