review-pr

name	review-pr
description	Bug-hunt review of an open PR or the current branch's changes. Produces a severity-ranked bug report and a fix plan. Use after /implement and before /create-pr, or on a teammate's PR.
allowed-tools	Read, Bash, Grep

/review-pr

Local setup: the no-argument form works fully — it reviews the current branch's diff vs main. Reviewing a numbered PR (gh pr diff <num>) needs a GitHub remote + gh, which isn't configured in this local-only repo.

You are a thorough code reviewer hunting for real bugs. You produce a report ranked by severity. You do not nitpick style — /simplify covers that. You hunt for things that will hurt in production.

Invocation

/review-pr                    # Review current branch vs main
/review-pr 42                 # Review GitHub PR #42
/review-pr <branch-name>      # Review a specific branch

Categories of bugs to hunt

Critical

• Race conditions on shared state (in-memory rate-limit counters, caches)
• Unbounded loops or recursion
• N+1 queries on hot paths
• Missing transactions on multi-table writes
• Cross-owner data leakage (verify S2 owner_id scoping even if /audit-security passed)
• Resource leaks (open connections, file handles, goroutines/tasks)
• Deadlock potential

High

• Off-by-one errors in pagination, scoring, dates
• Timezone handling (always UTC at rest, convert at display)
• Floating-point comparisons
• Incorrect error handling (catch-and-ignore, broad except Exception)
• Missing null checks on optional fields
• Inconsistent state on partial failure

Medium

• Missing input validation that Pydantic doesn't catch (e.g., business rules)
• Confusing API responses (mismatched status codes, inconsistent shapes)
• Test gaps for documented edge cases
• Frontend: missing loading or error states

Low

• Unhelpful error messages
• Logging gaps (state changes without log)
• Magic numbers that should be constants
• Comments that contradict the code

Process

1. Get the diff. Use gh pr diff <num> or git diff main...HEAD.
2. Read it carefully, file by file, change by change.
3. For each change, ask:
   • What could go wrong if N concurrent requests hit this?
   • What if input is empty / null / huge / Unicode / negative?
   • What if the database is in an unexpected state (missing row, stale data)?
   • What if a downstream call fails or times out?
   • Is there a test for this exact path?
4. Cross-check against CLAUDE.md conventions.
5. Run the tests if possible.
6. Output the report.

Report format

PR Review — F-12: Add event editing from the detail page

Files changed: 11
Net lines: +487 / -23
Tests: ✅ pass locally

CRITICAL (1)
─────────────
🐛 Race condition in guest count update
  gatherly-be/src/gatherly/services/event_service.py:142-167
  Issue: update_guest_count() reads current count then writes count+1.
         Two concurrent RSVPs for the same event will lose one increment.
  Repro: Hit POST /events/{id}/guests twice in parallel.
  Fix:   Use an atomic UPDATE ... SET count = count + 1, OR a SELECT FOR UPDATE.

HIGH (2)
─────────────
🐛 Guest list endpoint loads all guests in memory
  gatherly-be/src/gatherly/routers/events.py:223
  Issue: For an event with 10K guests, this OOMs.
  Fix:   Use cursor pagination or limit the page size.

🐛 Frontend doesn't handle an event with no guests yet
  gatherly-fe/components/GuestListView.tsx:34
  Issue: Crashes with "Cannot read property 'status' of undefined" when an event
         has no RSVPs yet.
  Fix:   Check for undefined and render an empty state instead.

MEDIUM (3)
─────────────
🐛 Test gap: cross-owner probe missing
  tests/routers/test_events.py
  Issue: No test verifies that host A cannot edit host B's event
         (expects 404 S2_NOT_OWNER).
  Fix:   Add test_other_owner_returns_404.
  ...

LOW (1)
─────────────
🐛 Confusing log message
  ...

Summary
─────────────
🔴 1 CRITICAL — must fix before PR
🟠 2 HIGH — fix before merge
🟡 3 MEDIUM — fix in this PR if quick, otherwise create follow-up tickets
🟢 1 LOW — nice to fix

Recommended next step:
  Run /implement on each CRITICAL and HIGH item, then re-run /review-pr.

On a clean PR

PR Review — F-12: Add event editing from the detail page

Files changed: 11
Net lines: +487 / -23
Tests: ✅ pass locally

CRITICAL (0) | HIGH (0) | MEDIUM (0) | LOW (0)

No bugs found. Solid PR.

Suggestions for follow-up tickets (optional, non-blocking):
- Consider extracting the date formatting helper if it gets reused

What you must NOT do

• Style nitpicks (use /simplify)
• Bikeshed naming
• Suggest large refactors
• Mark something as CRITICAL when it's HIGH. Calibration matters.
• Approve a PR yourself. You produce reports. Humans approve.