devflow:build:review-pr

PR / MR Review

I'll help you review this pull request or merge request from within Claude Code.

PR/MR: $ARGUMENTS

---

Phase 1: Detect Backend and Fetch Details

Backend Detection

Parse $ARGUMENTS to determine backend:

• Contains github.com → GitHub — use gh CLI
• Contains a GitLab domain (check devflow-config.md for configured GitLab URL) → GitLab — use GitLab MCP
• Bare number with no URL → check devflow-config.md for configured VCS backend
• No argument → ask: "Please provide a PR/MR URL or number."

Fetch PR/MR Details

GitHub:

# 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)

---

Phase 2: Present Summary

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]

---

Phase 3: Interactive Options

Ask the developer how they want to proceed:

"How would you like to review this PR/MR?

1. Full review — I'll analyze all changed files and provide a structured review
2. Interactive — Ask me questions about specific files or changes
3. Visual diff — Generate an interactive diff playground (requires playground plugin)
4. Checkout branch — Check out the branch locally to run tests
5. Post a comment — Add a review comment directly

Select one or more (comma-separated), or describe what you need."

---

Phase 4a: Full Code Review

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 branch
• security-reviewer agent — pass the list of changed files and base branch

Present 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?"

---

Phase 4b: Interactive Review

Developer can ask questions naturally:

• "What does the change to UserService.php do?"
• "Are there any test gaps?"
• "Explain the database migration"
• "Is the error handling correct in the auth controller?"

Answer each question by reading the relevant files from the diff or checking out the branch if needed.

---

Phase 4c: Visual Diff Playground

If the playground plugin is installed, generate an interactive diff visualization:

1. Get the full diff:

   GitHub:

   gh pr diff <number>
   

   GitLab: Use mcp__gitlab__get_merge_request_diffs to fetch all diffs.

2. Invoke the playground skill with the diff-review template:

   "I'll generate an interactive diff playground using the diff-review template. 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:

   • Shows file-by-file diffs with syntax highlighting
   • Lets the developer navigate and annotate
   • Generates copy-ready review comment prompts at the bottom

3. 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-official Then re-run this step. Continuing without the visual diff."

---

Phase 4d: Checkout Branch

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:

• Show current branch confirmation
• Detect and suggest the test command from CLAUDE.md or package.json
• Ask: "Would you like to run the tests now?"
• If yes, run them and show results

---

Phase 5: Draft and Post Review Comments

When the developer wants to post feedback:

Drafting Comments

Ask the developer what they want to say. Options:

• General PR/MR comment (not tied to a specific line)
• Specific line comment (tied to a file and line number)

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)

Posting Comments (requires developer approval)

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. ✅"

---

Phase 6: Final Review Action

Ask the developer for their overall review decision:

"What's your overall review verdict?

1. Approve — LGTM, ready to merge
2. Request changes — needs work before merging
3. Comment only — leaving feedback without blocking
4. 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.

---

⚠️ Important Constraints

• Never merge — the review skill does not merge PRs or MRs
• Every comment requires approval before posting — show draft, wait for yes
• Every review action requires approval — show what will be submitted, wait for yes
• Branch checkout is optional — never check out a branch without asking first
• If the PR/MR is already merged or closed — report that and stop: "This PR/MR is already [merged/closed]. Nothing to review."

---

⛔ STOP

Review complete. The developer decides all next actions.