Review Pr

PR Review

Review pull requests for code quality, correctness, and CONTRIBUTING.md compliance.

Scope boundary: This skill evaluates how the code is written. For evaluating whether the PR solves the right problem, use the issue-detective skill instead.

Workflow

1. Fetch PR Context

gh pr view <number> --repo antiwork/gumroad
gh pr diff <number> --repo antiwork/gumroad
gh pr view <number> --repo antiwork/gumroad --comments
gh api repos/antiwork/gumroad/pulls/<number>/comments

Also read CONTRIBUTING.md from the repo root — it's the source of truth for all guideline checks.

Note PR status (draft, closed, merged). Skip review if merged or closed unless user insists.

2. Understand the Change

From the diff and description, determine:

• What changed and why (read the linked issue if referenced)
• Bug fix, feature, refactor, or chore
• Which layers are affected (frontend, backend, both, tests only)
• Size and complexity

Read key modified files in full when the diff alone is insufficient to understand context.

3. Review

Run these review passes on the diff:

Pass 1 — Bugs and Logic Errors Wrong conditionals, missing edge cases, race conditions, nil/null handling, off-by-one errors, security vulnerabilities (injection, XSS, CSRF). Focus on code paths introduced or modified by the PR.

Pass 2 — CONTRIBUTING.md Compliance Check the diff against every applicable rule in CONTRIBUTING.md (code standards, naming conventions, testing standards, Sidekiq patterns, PR structure, etc.). The file is the single source of truth — do not maintain a separate checklist.

Pass 3 — Code Clarity Evaluate readability and maintainability of new/modified code. See references/review-guidance.md for what to flag vs what to leave alone. The goal is clear, explicit code — not clever or compact code.

Pass 4 — PR Structure AI disclosure, description quality (explains why), before/after media, test results, appropriate size — all per CONTRIBUTING.md.

⛔ Media evidence is a BLOCKING check (CONTRIBUTING.md line 17 — a hard Must). If the PR touches product/UI (any view, component, CSS, layout, mobile behavior, user-visible copy) and has no before/after video or screenshots, raise it as a critical finding at confidence 95+ and set the Verdict to request-changes. Do NOT wave through a mobile/CSS/layout PR just because the prose description is clear — "the code looks right" is not a substitute for visual proof. A missing video on a non-visual change (no walkthrough) is at least an important finding. This does not apply to PRs that only touch documentation or agent skill files — the diff itself is the reviewable artifact, so do not raise a missing-media finding for docs- or skill-only PRs.

4. Score and Filter

Assign each finding a confidence score (0–100): how likely is this a genuine problem?

Keep findings >= 80. Drop findings below 80.

See references/review-guidance.md for noise filtering rules and severity levels.

5. Report

## Summary

[1-2 sentences: what the PR does and overall assessment]

## Issues

### [critical|important|suggestion] Title
**File:** `path/to/file.rb:NN`
**Confidence:** NN/100

[Concise explanation and fix suggestion if straightforward.]

...

## Checklist

[CONTRIBUTING.md items that are missing — e.g., no AI disclosure, no before/after, missing tests]

## Verdict

[approve / request-changes / comment-only — with brief justification]

Write the review to gh-pr-review.md in the repo root. Do NOT stage or commit. Do NOT post to GitHub.

6. Iterate

When the user asks to re-check a PR (new comments, updated diff):

gh pr view <number> --repo antiwork/gumroad --comments
gh api repos/antiwork/gumroad/pulls/<number>/comments
gh pr diff <number> --repo antiwork/gumroad

Focus on what changed since the last review. Don't repeat prior findings unless still unaddressed.

Important

• Use gh read-only only. Never approve, comment on, or request changes via CLI.
• Review what the PR introduces — not pre-existing code.
• Be direct and concise. No filler praise.
• Prioritize substantive issues over cosmetic ones.
• When unsure, state uncertainty rather than false confidence.
• For large PRs (1k+ lines), note the PR should be broken up.