| name | review-pr |
| description | Multi-agent PR code review orchestrator. Fetches a PR by URL or branch name, spawns specialist sub-agents for architecture and quality review, then synthesizes findings into a structured report. Activate with: "review my PR", "review this PR", "/review-pr `<url_or_branch>`".
|
PR Review Orchestrator
Purpose
Run a structured, multi-agent code review on a pull request by delegating
architecture and quality concerns to specialist sub-agents and synthesizing
their findings into a single actionable report.
When to use
/review-pr <url_or_branch>- User says "review my PR", "review this PR", "review the PR", or "code review
<branch>".
- A PR has been created and the user wants quality feedback before merging.
- The user asks "is this ready to merge?" or "is this PR good?".
- After
/create-pr completes and the user wants a review pass.
Fetch the PR
If the user provides a GitHub PR URL, extract owner, repo, and pr_number:
# From URL: https://github.com/<owner>/<repo>/pull/<number>
If the user provides a branch name, fetch it:
gh pr view <branch> --json number,title,body,headRepository,url
If no URL or branch given, check if the current branch is a PR branch (not master/main):
git branch --show-current
If on master or main, abort and ask the user for a PR URL or branch name.
Otherwise, use the current branch:
gh pr view --json number,title,body,headRepository,url
Store the PR title, description, and owner/repo/number.
Fetch changed files and diff
gh pr diff <pr_number> --repo <owner>/<repo>
gh pr view <pr_number> --repo <owner>/<repo> --json files --jq '.files[].path'
Store the full diff and file list to pass to each sub-agent.
Classify the change
Scan the changed file paths for signals:
| Signal | Implication |
|---|
| New database migrations, schema changes | Architecture review is high priority |
| Auth, session, token, API key files | Security review is high priority |
| Hot-path code (controllers, handlers, middleware) | Performance review is high priority |
| Config, routes, infrastructure | Architecture review is high priority |
| Tests only | Light review, focus on test quality |
| Docs only | Light review, focus on clarity |
If the PR is large (>50 files), warn the user and ask if they want a
focused review on specific files.
Spawn sub-agents in parallel
Invoke two sub-agents via the Task tool, running them concurrently:
Architect agent
Prompt the architect agent with:
Review the architecture of this PR. Focus on:
- Domain boundaries and separation of concerns
- Correct placement of business logic
- Coupling and dependency direction
- New patterns introduced vs existing conventions
- Background vs foreground work (heavy ops in request cycle?)
## PR Under Review
Title: {pr_title}
Description: {pr_description}
## Changed Files
{file_list}
## Full Diff
{diff_content}
## Classification Notes
{classification_signals}
## Output Format
Return findings as:
## Architecture Review
### Findings
For each issue: [SEVERITY] file:line — problem description. Fix suggestion.
Severity: CRITICAL | HIGH | MEDIUM | LOW | NIT
### Summary
One paragraph. If no issues, say so explicitly.
Reviewer agent
Prompt the reviewer agent with:
Review this PR for quality, security, and performance. Follow your
built-in review framework (execution multiplier, N+1, injection, secrets).
## PR Under Review
Title: {pr_title}
Description: {pr_description}
## Changed Files
{file_list}
## Full Diff
{diff_content}
## Classification Notes
{classification_signals}
Both agents run in parallel. Wait for both to complete before proceeding.
Synthesize findings
Produce a unified review. Write like a teammate giving feedback in a chat thread, direct, no fluff, no emojis, no decorative formatting:
## PR Review: {pr_title}
### Summary
One paragraph describing what the PR does and overall quality signal.
### CRITICAL
Findings rated CRITICAL or HIGH. Include sub-agent source, file path, and a concrete fix suggestion.
### MEDIUM
Findings rated MEDIUM. Same format.
### LOW
Findings rated LOW or NIT. Brief, not exhaustive.
### Coverage
- Architecture: found N issues
- Quality/Security/Performance: found N issues
Prompt to post
After presenting the review, ask the user:
Post review with inline comments to the PR?
If yes, write each finding as a natural comment like a teammate reviewing code. Do not use emojis or markdown flourishes. Do not open with preambles. Just state the issue and suggestion directly. Then post as a review with inline comments:
HEAD_SHA=$(gh pr view <pr_number> --repo <owner>/<repo> --json commits --jq '.commits[-1].oid')
gh api repos/<owner>/<repo>/pulls/<pr_number>/reviews \
-f commit_id="$HEAD_SHA" \
-f event="COMMENT" \
-f body="<summary_paragraph>" \
-f comments='[
{"path":"<file>","line":<line>,"body":"<human-like comment with fix suggestion>"},
{"path":"<file>","line":<line>,"body":"<human-like comment with fix suggestion>"}
]'
Use event: "REQUEST_CHANGES" if blockers exist, "COMMENT" otherwise.
Each comment references one finding, written conversationally in English.
Guardrails
- Keep findings tied to specific files and line references.
- Do not suggest architectural rewrites unless the PR introduces a clear regression.
- For large PRs, ask the user if they want focused review on specific areas.
- No emojis, no markdown dividers, no decorative formatting anywhere in the review or inline comments.
- Write like a human teammate in a code review thread. Skip preambles and get to the point.
