PR Review Assistant

Purpose: Generate a comprehensive pull request description and perform automated review when creating or reviewing PRs.

Invocation

/pr-review [pr_number]       # Review existing PR
/pr-create                    # Generate PR description for current branch

PR Description Generation

Step 1: Analyze the Branch

git log main..HEAD --oneline    # All commits
git diff main...HEAD --stat     # Files changed
git diff main...HEAD            # Full diff

Step 2: Generate Description

## Summary
[2-3 bullet points explaining WHY these changes were made]

## Changes
- [Grouped by area: API, UI, Database, Config, Tests]

## Testing
- [ ] Unit tests added/updated
- [ ] Manual testing completed
- [ ] Edge cases verified

## Screenshots
[If UI changes, describe what changed visually]

Review Checklist

When reviewing a PR, check:

Architecture

• Changes follow existing patterns in the codebase
• No unnecessary abstractions or premature optimization
• Module boundaries respected (no circular dependencies)
• Database queries use proper indexes

Safety

• No secrets or credentials in code
• User input is validated at boundaries
• Error handling doesn't leak internal details
• Auth checks present on new endpoints

Quality

• Tests cover the happy path and key edge cases
• No console.log / print debugging left in
• Naming is clear and consistent
• Comments explain WHY, not WHAT

Operations

• Database migrations are reversible
• No breaking API changes without version bump
• Feature flags for risky changes
• Monitoring/logging added for new failure modes

Review Comment Format

**[MUST FIX]** src/api/route.ts:42
Missing auth middleware on this endpoint. Any unauthenticated user can access user data.

**[SUGGESTION]** src/utils/format.ts:15
Consider using Intl.NumberFormat instead of manual formatting — handles locale differences.

**[QUESTION]** src/hooks/useData.ts:28
Why was the cache timeout changed from 5min to 30min? Could this cause stale data issues?

**[PRAISE]** src/lib/validation.ts:50
Nice use of discriminated unions here — makes the error handling much cleaner.

Rules

• Always read the full diff before commenting
• One MUST FIX blocks the PR; everything else is advisory
• Praise good code — reviews shouldn't be only negative
• If unsure about a pattern, ask with QUESTION rather than demanding a change