| name | review-pr |
| description | Review-only GitHub pull request analysis with the gh CLI. Use when asked to review a PR, provide structured feedback, or assess readiness to land. Do not merge, push, or make code changes you intend to keep. |
Review PR
Overview
Perform a thorough review-only PR assessment and return a structured recommendation on readiness for /preparepr.
Inputs
- Ask for PR number or URL.
- If missing, always ask. Never auto-detect from conversation.
- If ambiguous, ask.
Safety
- Never push to
main or origin/main, not during review, not ever.
- Do not run
git push at all during review. Treat review as read only.
Execution Rule
- Execute the workflow. Do not stop after printing the TODO checklist.
- If delegating, require the delegate to run commands and capture outputs, not a plan.
Writing Style for Output
- Write casual and direct.
- Avoid em dashes and en dashes. Use commas or separate sentences.
Completion Criteria
- Run the commands in the worktree and inspect the PR directly.
- Produce the structured review sections A through J.
- Save the full review to
.local/review.md inside the worktree.
First: Create a TODO Checklist
Create a checklist of all review steps, print it, then continue and execute the commands.
Setup: Use a Worktree
Use an isolated worktree for all review work.
git rev-parse --show-toplevel
WORKTREE_DIR=".worktrees/pr-<PR>"
git fetch origin main
if [ -d "$WORKTREE_DIR" ]; then
cd "$WORKTREE_DIR"
git checkout temp/pr-<PR> 2>/dev/null || git checkout -b temp/pr-<PR>
git fetch origin main
git reset --hard origin/main
else
git worktree add "$WORKTREE_DIR" -b temp/pr-<PR> origin/main
cd "$WORKTREE_DIR"
fi
mkdir -p .local
Run all commands inside the worktree directory.
Start on origin/main so you can check for existing implementations before looking at PR code.
Steps
- Identify PR meta and context
gh pr view <PR> --json number,title,state,isDraft,author,baseRefName,headRefName,headRepository,url,body,labels,assignees,reviewRequests,files,additions,deletions --jq '{number,title,url,state,isDraft,author:.author.login,base:.baseRefName,head:.headRefName,headRepo:.headRepository.nameWithOwner,additions,deletions,files:.files|length,body}'
- Check if this already exists in main before looking at the PR branch
- Identify the core feature or fix from the PR title and description.
- Search for existing implementations using keywords from the PR title, changed file paths, and function or component names from the diff.
- Claim the PR
Assign yourself so others know someone is reviewing. Skip if the PR looks like spam or is a draft you plan to recommend closing.
- Read the PR description carefully
Use the body from step 1. Summarize goal, scope, and missing context.
- Read the diff thoroughly
gh pr diff <PR>
- Validate the change is needed and valuable
Be honest. Call out low value AI slop.
- Evaluate implementation quality
Review correctness, design, performance, and ergonomics.
- Perform a security review
Check auth, input validation, secrets, dependencies, tool safety, and privacy.
- Review tests and verification
Identify what exists, what is missing, and what would be a minimal regression test.
- Check docs
Check if the PR touches code with related documentation.
- Check changelog
Check if the PR warrants a changelog entry.
- Answer the key question
Decide if /preparepr can fix issues or the contributor must update the PR.
- Save findings to the worktree
Write the full structured review sections A through J to .local/review.md.
- Output the structured review
A) TL;DR recommendation
B) What changed
C) What is good
D) Security findings
E) Concerns or questions (actionable) - mark each as BLOCKER, IMPORTANT, or NIT
F) Tests
G) Docs status
H) Changelog
I) Follow ups (optional)
J) Suggested PR comment (optional)
Guardrails
- Worktree only.
- Do not delete the worktree after review.
- Review only, do not merge, do not push.