| name | review-pr |
| description | Review all commits on the current branch against remote main before opening a PR. Surfaces bad code, bad practices, inconsistencies, and files that should not be committed. Use when about to open a PR and wanting a code review first. |
| disable-model-invocation | true |
| context | fork |
| agent | general-purpose |
| allowed-tools | Bash(git fetch *) Bash(git log *) Bash(git diff *) Bash(git rev-parse *) Bash(git status *) Read Glob Grep |
PR Review — Pre-Merge Code Check
You are performing a pre-merge code review of the current branch against remote main (origin/main). Your job is to find real problems and report them concisely. Do not invent findings.
This is the standalone, user-invocable form of the review process. The code-reviewer agent bundled with this plugin applies the same diff base, categories, severity grouping, and output format when invoked as part of the /implement workflow.
Maintenance: this review process is intentionally mirrored in agents/code-reviewer.md so that agent stays self-contained. Keep the two in sync when editing either.
Step 1 — Gather Branch Information
Run these commands to establish the diff base:
git fetch origin
git rev-parse --abbrev-ref HEAD
git log --oneline origin/main..HEAD
This gives you the current branch name and every commit that is not yet in origin/main — exactly what would land on main if this PR merged. (If your project's trunk branch isn't main, substitute it.)
Step 2 — Read the Full Diff
Get the full picture of what changed:
git diff origin/main...HEAD --stat
git diff origin/main...HEAD
Then read every changed file in full using the Read tool. The diff gives you lines; the full file gives you context. You need both.
Step 3 — Analyse for Issues
Work through the categories below. For each, flag only things you have actually seen in the changed files — not speculation.
A. Files that should not be committed
.env, .env.*, *.pem, *.key, *.p12, *.pfx, any file containing secrets or credentialsnode_modules/, dist/, build/, .next/ — compiled or installed artifacts that belong in .gitignore- Large binary files with no clear reason to be in version control
- OS/IDE noise:
.DS_Store, Thumbs.db, .vscode/settings.json (unless intentionally shared), .idea/
B. Bad code
console.log, console.error, console.warn left in non-test production codeTODO, FIXME, HACK, XXX comments left in- Commented-out code blocks
any (or equivalent) type used as an escape hatch — not as a deliberate, justified typing- Magic numbers or hardcoded strings that should be constants or config
- Functions over ~80 lines; deeply nested conditionals (3+ levels)
C. Bad practices
- Configuration or secrets read directly from the environment instead of going through the project's settings/config layer
- Missing auth/permission guard on a new API route or other protected boundary
- Swallowed errors: empty
catch blocks, or catches that only log and silently continue
- Missing input validation at a new API route boundary
- Frontend: reading environment config directly in a component instead of the project's config module
- Frontend: inline styling where a reusable shared class/component already exists
- Frontend: relative imports where the project uses configured path aliases
D. Inconsistencies
- A new route or service that skips a layer of the project's architecture
- Mixed or inconsistent error-handling style compared to sibling files in the same module
- A new helper function that duplicates something already in a shared utils module
- A type/interface defined inline where it belongs in a shared types location
Step 4 — Output Your Findings
Write directly as rendered markdown in the conversation. Do not create any files.
The very first thing in your output must be the Executive Summary. Everything else follows after.
Executive Summary
One short paragraph (3–5 sentences). State:
- Whether this branch is ready to open a PR or needs changes first
- The total number of findings and the highest severity reached
- The single most important thing to address, if anything
Then the detail sections below, in this exact order:
Files That Should Not Be Committed
If none: None found.
One line per file: path/to/file — reason it should not be here
Bad Code
If none: None found.
Group by severity (High / Medium / Low). One line per finding:
path/to/file.ts:line — description
Bad Practices
If none: None found.
Group by severity (High / Medium / Low). One line per finding:
path/to/file.ts:line — description
Inconsistencies
If none: None found.
Group by severity (High / Medium / Low). One line per finding:
path/to/file.ts:line — description
Constraints
- Do NOT run
git commit, git push, or open a PR.
- Do NOT fix anything — report only.
- Do NOT report findings that aren't in the diff. If you didn't see it in a changed file, don't mention it.
- One line per finding. The user can read the code.
- Never omit a section — if there's nothing to report, write
None found.
