PR Auto Review

PR Auto Review

Automates what a careful human reviewer does on this repo's PRs: read the real diff, judge it on its own merits, and leave a review that is either an approval or a clear, actionable list of problems — never a rubber stamp.

When to use

• User asks to check/review/approve a PR (by number, or "the PR someone opened").
• User asks to run this on all open PRs.
• No PR number given and more than one is open → ask which one, or offer to review all.

Workflow

1. Find the PR(s).

   gh pr list

   If the user named a number, use it. If they said "the PR" and only one is open, use that one. If several are open and unspecified, ask (or, if told to do all, loop over each).

2. Gather full context per PR — do NOT review from the title/description alone:

   gh pr view <N> --json title,body,author,files,additions,deletions,commits
   gh pr diff <N> > /tmp/pr<N>.diff
   gh pr checks <N>          # CI status, ignore "no checks reported" errors

3. Size-gate the review:

   • Diff roughly ≤ 300 lines: read it directly yourself with Read/Bash, no subagent needed.
   • Diff larger: spawn a single Agent (general-purpose, foreground) to do the deep read. Prompt it explicitly to:
     • Diff the actual before/after logic, not just line-count churn — large diffs are often mostly reformatting (indent/quote-style changes); call that out separately from real behavior changes.
     • Check for correctness bugs, security issues (XSS via unescaped user input rendered as HTML/CSS, eval, unsafe innerHTML/dangerouslySetInnerHTML, injection via generated code strings, clipboard misuse).
     • Check whether the PR guts or silently breaks existing functionality (large deletion counts demand this check specifically).
     • Check code quality: dead code/unused state, structural bloat, i18n gaps (hardcoded strings when strings.js/t() keys already exist for that string).
     • Check scope: does the diff actually match what the PR description claims, and is unrelated drive-by work (e.g. a full-file reformat bundled into a feature PR) worth flagging even if harmless?
     • Return a verdict (approve / request changes / reject) with concrete file/line-referenced issues, capped at ~500 words.

4. Decide.

   • Approve when: the diff does what it claims, no security/correctness issues, no silently broken existing behavior, reasonable scope. Minor nitpicks alone don't block approval — use judgment; this repo favors shipping over bikeshedding for genuinely clean fixes.
   • Request changes when: any real correctness/security issue, gutted functionality, or scope so tangled it can't be reviewed responsibly (e.g. unrelated full-file reformat bundled with a feature — ask for a split).

5. Post the review via gh pr review <N> --approve|--request-changes --body "...".

   • Approve body: short, factual, Persian, plain tone — state what was checked and why it's fine. No need for Rick Sanchez flavor on approvals; keep it professional and brief.
   • Request-changes body: written in Persian, in Rick Sanchez's voice (Rick and Morty) — sarcastic, brilliant, impatient, calls the contributor "Morty"/"-y" nicknames, drops signature verbal tics (*بارپ*, Wubba lubba dub dub, اینتردایمنشنال, etc.) but the substance underneath must be a genuinely useful, specific, technically accurate list of issues with file/line references — the jokes are seasoning, not a replacement for real feedback. Always end constructively (what to fix, and that it's mergeable once fixed).
   • Use a heredoc ($(cat <<'EOF' ... EOF)) to avoid shell-quoting problems with Persian text and special characters.

6. Report back to the user in a short summary: which PR(s), verdict, and the top issues (if any) — don't just say "done," name what you found.