Reviews GitHub PRs for architecture, tests, scope creep, unrelated changes; drafts comments. For issues, analyzes discussion/codebase and drafts/posts replies.
From reviewnpx claudepluginhub umputun/cc-thingz --plugin reviewThis skill is limited to using the following tools:
Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.
Migrates code, prompts, and API calls from Claude Sonnet 4.0/4.5 or Opus 4.1 to Opus 4.5, updating model strings on Anthropic, AWS, GCP, Azure platforms.
Orchestrates subagents to execute phased plans: deploys for implementation, verification, anti-pattern checks, code quality review, and commits only after passing checks.
Comprehensive pull request review that analyzes code quality, architecture, test coverage, and identifies scope creep (unrelated changes mixed into the PR).
1. Fetch PR metadata + discussion history + merge status
1.5. Ask review mode: Full (default) or Quick
--- Full path ---
2. Setup worktree, launch subagent for deep analysis (read files, validate, architecture, scope creep, cleanup)
3. Present condensed findings from subagent, ask to proceed
4. Resolve open questions (if any)
5. Draft review comment
--- Quick path ---
Q1. Read diff inline, summarize what/why/size
Q2. Flag obvious issues from diff
Q3. Draft review comment
Determine if the target is a PR or an issue. If a URL is provided, check if it contains /pull/ or /issues/. If just a number, detect type:
gh pr view <number> --json number 2>/dev/null && echo "PR" || echo "ISSUE"
For issues, skip worktree/diff/architecture analysis. Focus on understanding the issue and drafting a helpful comment.
gh issue view <number> --json title,body,author,state,labels,comments,createdAt
Read the full discussion - understand what was reported, what others said, whether there are linked PRs
Investigate the codebase if the issue references specific code, files, or behavior:
Draft a comment addressing the issue - could be: analysis of root cause, a proposed approach, questions for clarification, or acknowledgment with next steps
Post as a regular comment (not a review):
cat > /tmp/issue-comment.md << 'COMMENT_END'
<comment content>
COMMENT_END
gh issue comment <number> --body-file /tmp/issue-comment.md
Use AskUserQuestion before posting:
question: "Post this comment to issue #<number>?"
header: "Comment"
options:
- Post (post as shown above)
- Edit (tell me what to change)
- Cancel (discard draft)
After posting → done. No worktree cleanup needed for issues.
Get PR number from $ARGUMENTS. If not provided, list recent PRs and ask user to select:
# if no PR number provided, list recent PRs
gh pr list --limit 5 --state all
# get PR details
gh pr view <number> --json title,body,additions,deletions,changedFiles,files,author,state,headRefName
# get all comments (PR comments and review comments)
gh pr view <number> --json comments,reviews
Capture:
Before reviewing, understand what has already been discussed:
# get PR comments (general discussion)
gh api repos/{owner}/{repo}/issues/<number>/comments --jq '.[] | "[\(.user.login)] \(.body)"'
# get review comments (inline code comments)
gh api repos/{owner}/{repo}/pulls/<number>/comments --jq '.[] | "[\(.user.login) on \(.path):\(.line)] \(.body)"'
# get reviews with their state (approved, changes_requested, commented)
gh api repos/{owner}/{repo}/pulls/<number>/reviews --jq '.[] | "[\(.user.login) - \(.state)] \(.body)"'
Summarize discussion:
Check automated reviews (Copilot, etc.): Read any automated review comments - they can have valuable findings. If Copilot or other bots flagged real issues, verify them and include in your review if valid. Don't dismiss automated feedback just because it's automated.
CRITICAL - Check for inline suggestions:
# get inline review comments (where actual suggestions live)
gh api repos/{owner}/{repo}/pulls/<number>/comments --jq '.[] | "[\(.user.login) on \(.path):\(.line // .original_line)]\n\(.body)\n---"'
Look specifically for:
suggestion tags containing proposed fixesThe review body is often just a summary. The inline comments are where the real feedback is.
Important: Do not re-raise issues that were already discussed and resolved. Focus on new findings or unaddressed concerns.
Check if PR is mergeable and CI status:
gh pr view <number> --json mergeable,mergeStateStatus,statusCheckRollup
Report:
If PR has conflicts or is behind, note this early - it may explain "deletions" in the diff that are actually just missing commits from the base branch.
Print summary:
PR #<number>: <title>
Author: <author> | State: <state>
+<additions>/-<deletions> across <changedFiles> files
Merge status: <mergeable> | <mergeStateStatus>
CI: <pass/fail summary>
Discussion: <N> comments, <M> reviews
- Resolved: <list of addressed issues>
- Open: <list of unresolved questions>
After presenting the Phase 1 summary, ask the user to choose review depth:
question: "Review mode for PR #<number>?"
header: "Mode"
options:
- Full review (Recommended) — clone, run tests/linter, architecture analysis, scope creep detection
- Quick review — diff-only, summarize what/why/size, flag obvious issues
Lightweight review based on diff and metadata only. No worktree, no subagent, no test/linter execution.
gh pr diff <number>
From the diff and Phase 1 metadata, present:
Scan the diff for issues detectable without full file context:
If nothing found, say so explicitly.
After presenting the summary and any flagged issues, skip directly to Phase 5 (Draft Review Comment). All Phase 5 rules apply: check previous comments, use writing-style skill, don't restate what the PR does.
No worktree cleanup needed since quick review never creates one.
CRITICAL: Delegate all file reading, validation, and architecture analysis to a subagent to protect the main conversation's context window. The subagent does the heavy lifting and returns a condensed report.
Create the worktree before launching the subagent:
# fetch the PR ref directly (does NOT affect current checkout)
git fetch origin pull/<number>/head:pr-<number>
# create worktree from the fetched ref
git worktree add "/tmp/pr-review-<number>" pr-<number>
Do NOT use gh pr checkout - it switches the main repo's branch, which is disruptive during a review.
Use the Task tool with subagent_type: "general-purpose" to run the full analysis. Pass all context the subagent needs in the prompt:
prompt: |
You are reviewing PR #<number> for <repo>.
**PR metadata:**
- Title: <title>
- Description: <body>
- Files: <file list from Phase 1>
- Discussion summary: <from Phase 1.1>
**Worktree location:** /tmp/pr-review-<number>
**Repo location:** <repo_path>
**Your tasks (do all of these):**
1. **Read changed files** - read each changed file in full from the worktree
to understand context, not just the diff. Focus on what the code actually
does vs what the PR description claims.
2. **Run validation** - from the worktree directory:
- Run project test suite (e.g., `npm test`, `pytest`, `go test ./...`, etc.)
- Run project linter (e.g., `eslint .`, `ruff check`, `golangci-lint run`, etc.)
- Run race/concurrency checks if applicable (e.g., thread sanitizer, `-race` flag, etc.)
Detect project type from files present (package.json, pyproject.toml, go.mod, Cargo.toml, etc.)
Record all failures.
3. **Architecture analysis** - check for:
- Over-engineering (unnecessary abstractions, premature generalization)
- Pattern violations (inconsistent with existing codebase)
- Error handling issues
- Concurrency issues
- Security concerns
- Test quality (fake tests, missing coverage)
4. **Scope creep detection** - categorize each file as:
- Core (implements PR purpose)
- Supporting (tests, config for core changes)
- Related cleanup (minor fixes in touched files)
- Unrelated (doesn't connect to PR purpose)
**IMPORTANT: Do NOT clean up the worktree.** The main conversation handles cleanup after all review phases complete.
**Return a structured report with these sections:**
- **Functionality**: 3-5 sentence explanation of what the PR does
- **Key decisions**: notable implementation choices
- **Validation results**: test pass/fail, linter issues, race conditions
- **Architecture issues**: list with file:line references
- **Over-engineering**: specific instances with simpler alternatives
- **Scope creep**: unrelated files with explanation
- **Positives**: what's done well
- **Open questions**: design decisions that need user input
Be specific - use file:line references. Skip sections with no findings.
The subagent returns a condensed report. This is what enters the main conversation context - not the raw file contents or diff.
Present the subagent's report to the user.
Use AskUserQuestion to confirm next step:
question: "How would you like to proceed?"
header: "Continue?"
options:
- Draft review comment (proceed to Phase 5)
- Investigate specific finding (ask subagent for details)
- Done (end review without posting)
If user selects "Investigate specific finding", launch another targeted subagent to dig into the specific area, then ask again.
If the subagent report contains open questions (design decisions needing user input), ask about EACH one specifically before proceeding:
question: "Section type change: Logger.PrintSection(string) → Logger.PrintSection(Section). Accept typed approach for compile-time safety?"
header: "Decision"
options:
- Accept (keep typed Section approach)
- Reject (revert to string-based)
- Need more context
Wait for user response on each open question. If user selects:
Repeat for all open questions before proceeding.
Only proceed when user explicitly asks to draft/post the review.
NEVER duplicate what the user already said in their previous comments.
Before drafting, review the discussion history from Phase 1.1:
Exclude from draft:
Include in draft only:
If user already covered everything and there's nothing new → say "no new findings to add" and don't draft.
Activate writing-style skill for proper tone:
/review:writing-style
CRITICAL: Don't restate what the PR does. The author knows what they built. Focus only on:
Keep it casual and brief. Examples of good review comments:
LGTM
lgtm. one minor thing - `loadPatterns` could filter in a single pass instead of two, but not a blocker
couple issues:
1. test failure in `TestFoo` - looks like missing mock setup
2. linter complains about unused param on line 42
otherwise looks good
I don't get why we need the Factory pattern here - there's only one implementation. could simplify to just `NewNotifier()` directly?
Only add sections if there are actual issues:
Omit sections with no findings. For clean PRs, just "LGTM" is fine.
Code examples: when suggesting fixes, always show proper error handling - never ignore errors even in snippets.
Always display the complete draft review as a text block before asking:
--- Draft Review Comment ---
**Overall impression**
<actual review content here>
**Issues to address**
...
--- End Draft ---
Use AskUserQuestion tool with these options:
question: "Post this review to PR #<number>?"
header: "Review"
options:
- Approve (post review and approve)
- Comment (post as review comment, no approval)
- Request changes (post review requesting changes)
- Edit (tell me what to change)
- Cancel (discard draft)
Approve / Comment / Request changes: Write to temp file and post as a formal PR review (not a regular comment). This ensures GitHub marks the review as done and it appears in latestReviews:
# write to temp file to avoid escaping issues
cat > /tmp/pr-review.md << 'REVIEW_END'
<review content>
REVIEW_END
# use --approve, --comment, or --request-changes based on user's choice
gh pr review <number> --body-file /tmp/pr-review.md --comment
After Approve - offer to merge:
When the user selected "Approve" and the approval was posted successfully, analyze the PR commits to recommend a merge strategy:
# check commit history for the PR
gh pr view <number> --json commits --jq '.commits[] | "\(.oid[:8]) \(.messageHeadline)"'
Strategy recommendation logic:
Present the recommendation with reasoning:
# example for clean commits:
question: "PR #<number> approved. Merge strategy? (3 clean commits: 'add auth middleware', 'add auth tests', 'update docs')"
header: "Merge"
options:
- Rebase and merge (Recommended) — preserves clean commit history
- Squash and merge — collapse into single commit
- Merge commit — creates merge commit
- Skip — don't merge
# example for messy commits:
question: "PR #<number> approved. Merge strategy? (5 commits including 'wip', 'fix lint', 'address review')"
header: "Merge"
options:
- Squash and merge (Recommended) — cleans up noisy commit history
- Rebase and merge — preserves all commits as-is
- Merge commit — creates merge commit
- Skip — don't merge
If user selects a merge strategy:
# --rebase, --squash, or --merge based on user's choice
gh pr merge <number> --rebase --delete-branch
If merge fails (CI not passing, conflicts, branch protection), report the error and move on to cleanup.
Edit: Ask user for specific changes, update draft, display again, and repeat the ask.
Cancel: Acknowledge and stop.
After the review is fully complete (comment posted, user cancelled, or user said "Done"), clean up:
cd <repo_path>
git worktree remove "/tmp/pr-review-<number>" --force 2>/dev/null || true
git branch -D pr-<number> 2>/dev/null || true
This must happen AFTER all phases are done - the worktree is needed for follow-up investigations in Phases 3-4.
User: "review pr 42"
→ Phase 1: fetch metadata, +150/-30, 5 files
→ Phase 2: launch subagent → reads files, tests pass, lint clean, no issues
→ Phase 3: present condensed report - adds retry logic with exponential backoff
→ User: "post the review"
→ Phase 5: draft and post "LGTM"
User: "review pr 58"
→ Phase 1: fetch metadata, +2k/-100, 25 files
→ Phase 2: launch subagent → reads 25 files, 1 test timeout, CacheFactory unnecessary,
unrelated changes in config.yaml and Logger interface
→ Phase 3: present condensed report
→ User: "why does it use interface instead of concrete client?"
→ launch targeted subagent to investigate → interface allows mocking
→ User: "draft the review"
→ Phase 5: draft review highlighting issues, post to PR
User: "review pr 73"
→ Phase 1: fetch metadata, +800/-50, 12 files
→ Phase 2: launch subagent → reads files, tests pass, OVER-ENGINEERING:
NotifierFactory, NotifierBuilder, NotifierRegistry for single email sender
→ Phase 3: present condensed report - suggest simplifying to EmailNotifier
→ User: "yeah, way too complex. draft the review"
→ Phase 5: draft review with specific simplification suggestions
User: "review pr 95"
→ Phase 1: fetch metadata, +200/-30, 6 files
→ Phase 1.5: [AskUserQuestion] "Review mode?" → user selects Quick
→ Q1: read diff, summarize: adds configurable tenant for auth
→ Q2: no obvious issues, tests included
→ Q3: draft and post "lgtm"
User: "review pr 89"
→ Phase 1: fetch metadata, +400/-50, 8 files
→ Phase 2: launch subagent → reads files, 2 test failures, open question
about Section type change
→ Phase 3: present condensed report
→ Phase 4: [AskUserQuestion] "Section type change: Accept typed approach?"
→ User: "Accept"
→ User: "draft the review"
→ Phase 5: draft review noting test failures, user's acceptance of Section approach
git fetch + worktree