From devflow
Reviews a pull request or merge request from within Claude Code. Fetches PR/MR details, summarizes changes, optionally checks out the branch, runs code analysis, and posts review comments back to GitHub or GitLab with developer approval. Works with GitHub PRs (via gh CLI) and GitLab MRs (via GitLab MCP). Use this when the user wants to review a PR/MR, says "let's review this PR," or provides a GitHub/GitLab PR/MR URL or number.
npx claudepluginhub joshuarweaver/cascade-code-general-misc-4 --plugin codingthefuturewithai-claude-code-primitivesThis skill is limited to using the following tools:
I'll help you review this pull request or merge request from within Claude Code.
Creates isolated Git worktrees for feature branches with prioritized directory selection, gitignore safety checks, auto project setup for Node/Python/Rust/Go, and baseline verification.
Executes implementation plans in current session by dispatching fresh subagents per independent task, with two-stage reviews: spec compliance then code quality.
Dispatches parallel agents to independently tackle 2+ tasks like separate test failures or subsystems without shared state or dependencies.
I'll help you review this pull request or merge request from within Claude Code.
PR/MR: $ARGUMENTS
Parse $ARGUMENTS to determine backend:
github.com → GitHub — use gh CLIdevflow-config.md for configured GitLab URL) → GitLab — use GitLab MCPdevflow-config.md for configured VCS backendGitHub:
# If full URL provided:
gh pr view <URL> --json number,title,body,author,baseRefName,headRefName,state,files,reviews,comments
# If number provided:
gh pr view <number> --json number,title,body,author,baseRefName,headRefName,state,files,reviews,comments
GitLab:
mcp__gitlab__get_merge_request (project from config, iid from argument)
mcp__gitlab__get_merge_request_diffs (to get changed files)
mcp__gitlab__mr_discussions (to get existing review comments)
Display a clear summary before doing anything else:
## PR/MR Summary
Title: [title]
Author: [author]
Branch: [head branch] → [base branch]
Status: [open/draft/approved/changes requested]
Files changed: [N files]
[list of files with +/- counts, grouped by directory if > 10 files]
Existing review comments: [N]
[If any, summarize or list briefly]
CI status: [passing/failing/pending/not available]
Ask the developer how they want to proceed:
"How would you like to review this PR/MR?
- Full review — I'll analyze all changed files and provide a structured review
- Interactive — Ask me questions about specific files or changes
- Visual diff — Generate an interactive diff playground (requires playground plugin)
- Checkout branch — Check out the branch locally to run tests
- Post a comment — Add a review comment directly
Select one or more (comma-separated), or describe what you need."
If developer selects full review, run code analysis in parallel using Task tool:
Run concurrently:
code-health-reviewer agent — pass the list of changed files and base branchsecurity-reviewer agent — pass the list of changed files and base branchPresent findings in a structured report:
## Code Review Findings
### Code Health
[findings from code-health-reviewer, or "No significant issues found"]
### Security
[findings from security-reviewer, or "No vulnerabilities found"]
### Changed Files Analysis
For each significant file changed:
[filename]
- What changed and why
- Any patterns or concerns worth noting
Ask: "Would you like me to draft review comments for any of these findings?"
Developer can ask questions naturally:
Answer each question by reading the relevant files from the diff or checking out the branch if needed.
If the playground plugin is installed, generate an interactive diff visualization:
Get the full diff:
GitHub:
gh pr diff <number>
GitLab:
Use mcp__gitlab__get_merge_request_diffs to fetch all diffs.
Invoke the playground skill with the diff-review template:
"I'll generate an interactive diff playground using the
diff-reviewtemplate. This will open in your browser and let you navigate the changes file-by-file."
Ask Claude Code to invoke /playground with the diff content, specifying the diff-review template. The playground:
After the playground opens, continue the review conversation in Claude Code.
If playground plugin is not installed:
"The playground plugin isn't installed. Install it with:
/plugin install playground@claude-plugins-officialThen re-run this step. Continuing without the visual diff."
Check out the PR/MR branch locally so the developer can run tests:
GitHub:
gh pr checkout <number>
GitLab:
# Fetch the branch
git fetch origin <head-branch>
git checkout <head-branch>
After checkout:
When the developer wants to post feedback:
Ask the developer what they want to say. Options:
Draft the comment and show it to the developer before posting:
Draft comment:
File: [filename] (if line comment)
Line: [N] (if line comment)
Comment: "[drafted text]"
Post this comment? (Yes / Edit / Cancel)
GitHub — general comment:
gh pr comment <number> --body "[approved comment text]"
GitHub — review with line comments:
gh api repos/{owner}/{repo}/pulls/{number}/reviews \
--method POST \
--field body="[overall review body]" \
--field event="COMMENT" \
--field "comments[][path]=[file]" \
--field "comments[][line]=[line]" \
--field "comments[][body]=[comment]"
GitLab — general comment:
mcp__gitlab__create_merge_request_note (body = approved text)
GitLab — line comment (discussion thread):
mcp__gitlab__create_merge_request_thread (with position for line reference)
Confirm after each post: "Comment posted. ✅"
Ask the developer for their overall review decision:
"What's your overall review verdict?
- Approve — LGTM, ready to merge
- Request changes — needs work before merging
- Comment only — leaving feedback without blocking
- Leave open — no verdict yet, just browsed
GitHub — Approve:
gh pr review <number> --approve --body "[optional message]"
GitHub — Request changes:
gh pr review <number> --request-changes --body "[summary of what needs to change]"
GitLab — Approve:
mcp__gitlab__approve_merge_request
GitLab — Request changes:
GitLab CE does not have a native "Request changes" state on MRs. Post a comment summarizing required changes and advise the developer to use the GitLab UI to mark it as blocked if needed.
No auto-merge under any circumstances. Merging is always a separate, deliberate action by the developer.
Review complete. The developer decides all next actions.