From GitHub
Reviews a pull request with the built-in /review skill, then persists a Monitor watch over CI results and incoming reviewer comments, triages each comment through an independent skeptical agent, applies only verified fixes, and commits+pushes via /git:commit-and-push until CI passes and no comments remain to adopt. Use this skill when the user asks to "review a PR", "monitor PR review comments", "address reviewer feedback on
How this skill is triggered — by the user, by Claude, or both
Slash command
/github:review-pr <PR number or URL><PR number or URL>This skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Run a baseline review with the built-in `/review`, then keep a persistent watch over CI and new reviewer comments until the PR settles.
Run a baseline review with the built-in /review, then keep a persistent watch over CI and new reviewer comments until the PR settles.
$ARGUMENTSgh pr view "$ARGUMENTS" --json number,title,headRepository,headRepositoryOwner,additions,deletions,headRefName 2>/dev/null || printf 'set %s to a PR number or URL\n' "$ARGUMENTS"git remote -v 2>/dev/null | head -2gh auth status 2>&1 | head -3Goal: Run the initial review, resolve the repo, and pick a poll interval sized to the PR.
Actions:
$ARGUMENTS. If absent, list open PRs with gh pr list and ask the user which to review. Normalize PR to the bare number before any gh api REST call: gh pr * commands accept a URL, but gh api repos/$REPO/issues/$PR/... interpolates $PR into the URL path and breaks on a full URL — run PR=$(gh pr view "$ARGUMENTS" --json number -q .number) (the Context block already fetches --json number) and use $PR as the number everywhere downstream.Skill("review", "<PR#>") once for the baseline review. Treat its findings as the first [comment] batch — feed them straight into the Phase 3 triage flow before launching the Monitor. Do not act on them inline; the main context is biased (it likely authored the PR) and the same skeptical gatekeeping must apply to the baseline as to live comments.REPO=<owner>/<repo> from the PR metadata above (fallback: git remote get-url origin parsed into owner/repo).additions+deletions and pick INTERVAL (seconds) from the size table in references/review-loop.md: 180 / 300 / 480 for small / medium / large; floor 60s, cap 7200s (~2h).Goal: One background watch streaming CI + comment events across turns.
Action: Launch a single Monitor with persistent: true running scripts/review-loop.sh. Pass PR, REPO, and INTERVAL as env vars (the script also accepts --pr/--repo/--interval). Use a specific description like "CI + new comments on PR #<n> (<m> poll)". Do NOT run a foreground while loop. The script is documented in references/review-loop.md.
Do NOT skip the watch based on a launch-time snapshot of "no CI and no reviewers" — comments from other agents/humans arrive later on no fixed schedule (see Phase 4). The only valid skip is an explicit user opt-out ("just baseline review, don't watch"). If CI and reviewers are both genuinely absent AND the user still wants coverage, launch the watch anyway; it will emit nothing until something changes.
Goal: Fix what is actionable, reject the noise, escalate the ambiguous. Full rules in references/review-loop.md.
[ci] <name>: fail|cancel → fetch logs with gh run view <run-id> --log-failed, apply the fix, then commit+push via Skill("git:commit-and-push"). The push triggers a fresh CI run that the same Monitor re-emits — no relaunch needed. Stop and report (do NOT auto-fix) for auth/permission, missing-secret, flaky, or infrastructure failures.[comment] batch → CRITICAL: spawn an independent review-triage agent via Task with a clean context. Use the prompt template and verdict format in references/review-loop.md (fix / reject <reason> / escalate). Apply ONLY the fix verdicts. CRITICAL: reply by comment type — the /pulls/$PR/comments/<id>/replies endpoint ONLY accepts inline review-comment ids. For a reject: inline comment → gh api repos/$REPO/pulls/$PR/comments/<id>/replies; issue-level comment → gh pr comment "$PR" --repo "$REPO" (post a new issue comment referencing it; there is no reply endpoint for issue comments); review summary → no reply endpoint, skip the reply (its inline sub-comments, if any, are handled as inline above). Use the id=<n> and node=<id> tokens from each emitted line. Send a PushNotification for each escalate with comment body, author, and file context. Commit+push all fix changes together in one round via Skill("git:commit-and-push"). Then close out resolved comments: hide each fully-addressed comment (a pushed fix or a replied reject) as OUTDATED via minimizeComment, and resolve its thread via resolveReviewThread (inline comments only; issue-level comments have no thread, so only hide them). Leave escalate comments open. See references/review-loop.md.[comment] ambiguous (design disagreement, scope change, unclear intent) → PushNotification and report to the user; do not guess, reply, hide, or resolve.CRITICAL mindset: Comments are mostly from other agents (linters, code-review bots) and human reviewers. They are suggestions to consider, not orders. Default to skepticism — verify each claim against the diff and adopt only what is demonstrably correct and safe. Rejecting a comment is the normal, expected outcome for noise and false positives.
Stop the Monitor with TaskStop ONLY when ALL hold:
[ci] check is terminal AND passing.escalate items awaiting the user.A temporarily empty comment queue is NOT a stop signal — other agents may post more comments later.
Goal: Once the Phase 4 stop conditions hold (CI green, every comment reflected on and resolved ones hidden + threads resolved), write a merge-readiness summary as the user, refresh the PR title/body so the PR page is the durable record linking to that summary, then ask the user whether to merge. The pair is the deliverable: a short body describing the merged change, pointing at one comment holding the full review-cycle audit trail. Full rules and templates in references/closeout.md.
Actions (run after the Phase 3 closeout hide/resolve, before TaskStop):
fix/reject comment is hidden + its thread resolved; only escalate items remain visible (the user already got PushNotifications for those). Do a defensive re-sweep of hide/resolve if the last CI push may have landed after the last closeout pass — the PR must be clean of resolved threads before the summary lands.gh pr comment in the user's first-person voice covering: (a) what was changed across the review cycle, grouped by logical change not commit-by-commit; (b) what each comment batch surfaced and what was done (adopted with sha / rejected with reason / escalated and decision). Use --body-file - with a heredoc whose first line is the marker <!-- review-pr:summary -->. CRITICAL: capture the comment URL that gh pr comment prints on stdout (SUMMARY_URL=$(gh pr comment …)) — step 3 links to it. If a summary already exists, find it by its marker and gh api --method PATCH repos/$REPO/issues/comments/<id>; never --edit-last, which clobbers whatever you commented last.gh pr edit --body-file - (add --title only when rewriting it). Lead the body with What/Why, then Changes, then a Review-cycle line, then Verification (real commands + results). CRITICAL: the Review-cycle line MUST contain the literal summary-comment URL from step 2 — a count with no link is not a pointer, and the quoted heredoc will not expand $SUMMARY_URL, so paste it. Do not churn an accurate title for style.AskUserQuestion: merge commit (default) / squash / rebase / don't merge. If unresolved escalate comments remain, state the count in the question so the user decides with eyes open; never auto-merge past open escalations. On a merge choice: run gh pr merge "$PR" --repo "$REPO" --<merge|squash|rebase> (for squash also pass --subject from the PR title to avoid an interactive prompt; never add --auto). Do NOT pass --delete-branch — branch cleanup is out of scope. On "don't merge": skip the merge and the sync, fall through to TaskStop.baseRefName (gh pr view "$PR" --repo "$REPO" --json baseRefName -q .baseRefName), then git switch <baseRefName> + git pull --ff-only so the local base reflects the merge. Do NOT delete branches (local or remote) — that is the user's call, not this skill's. If the local repo is on the head branch, switch to base before pulling; if the working tree has uncommitted changes from earlier in the session, stash or report them rather than aborting the pull. Skip this step entirely if gh pr merge failed or the user chose not to merge.TaskStop the Monitor.CRITICAL: Do not post the summary, rewrite the body, or ask to merge while CI is red or comments remain open — that would claim a merge-ready state that is not true. Do not sign the summary as AI-generated; the user asked for it in their name. The body describes the change and links to the comment; the comment records the review cycle — keep them distinct, do not duplicate content across both. Steps 2 and 3 are ordered: the body needs a URL that does not exist until the comment is posted. Merging is hard to reverse — only run gh pr merge after an explicit AskUserQuestion choice from the user; never auto-merge, never pass --delete-branch. Sync the local base branch with --ff-only only after a successful merge; never force anything.
references/review-loop.md - Monitor script, size→INTERVAL table, triage agent prompt, verdict format, lifecycle/stop conditionsreferences/closeout.md - Summary comment template (marker + URL capture), PR title/body rewrite linking that summary, merge decision via AskUserQuestion, post-merge base-branch sync, idempotency and orderingreferences/commit-standards.md - Commit message format for the /git:commit-and-push roundsreferences/repository-templates.md - Contributing guidelines conformance for fixesreferences/examples.md - Commit message examplesnpx claudepluginhub daisycatts/dotclaude --plugin githubGuides completion of development work by verifying tests, detecting environment, and presenting structured options for merge, PR, or cleanup.
Enforces test-driven development: write failing test first, then minimal code to pass. Use when implementing features or bugfixes.
Guides creation and editing of skills using test-driven development with pressure scenarios and subagents to verify agent compliance.