| name | review |
| description | Reviews PR(s) using comprehensive review guidelines including security, correctness, clean code, TypeScript, React patterns, i18n/RTL, performance, and accessibility. Use when reviewing pull requests or code changes. |
Review PR(s)
Review PR(s) using the comprehensive review guidelines.
Arguments
$ARGUMENTS can be:
- Single PR:
2732
- Multiple PRs:
2732 2700 2699 (space-separated)
- Multiple PRs:
2732,2700,2699 (comma-separated)
Steps
For Each PR
- Read the review prompt from
docs/REVIEW_PROMPT.md for all criteria
- Fetch PR details:
gh pr view {PR_NUMBER} --json title,body,files,additions,deletions,author
- Fetch PR diff:
gh pr diff {PR_NUMBER}
- If files changed > 15, flag for potential split before deep review
- Check for previous reviews (see Re-review Protocol below)
Re-review Protocol
Before reviewing, check if this PR has been previously reviewed:
-
Fetch previous reviews and comments:
gh pr view {PR_NUMBER} --json reviews,comments
-
If previous reviews exist:
- Summarize previous review status (APPROVED, CHANGES_REQUESTED, COMMENTED)
- List key issues raised in previous reviews
- Check commits since last review:
gh pr view {PR_NUMBER} --json commits
- Focus on:
- Whether previous feedback was addressed
- New changes introduced since last review
- Any regressions caused while fixing previous issues
- In the review output, add a "📋 Previous Review Status" section
Review Criteria
Apply all sections from the review prompt:
- Critical: Security, error handling, rendering strategy, correctness, breaking changes
- Standard: TypeScript, React patterns, localization/RTL, performance, accessibility
- Clean Code: DRY, KISS, single responsibility, separation of concerns, SOLID
- Polish: Function size, comments, dead code, console.log, naming
- Watch Out For: Common bug patterns
- Testing & Validation:
- Tests pass (
yarn test)
- Linting passes (
yarn lint)
- Build succeeds (
yarn build)
- Edge cases: loading, error, empty states, logged-in vs guest (if auth-related)
- Bugs & Regressions:
- Existing functionality still works
- Side effects on shared code/styles/state
- Runtime issues (race conditions, memory leaks)
- Testing verification based on what the PR changes (variants, themes, RTL, responsive, states,
user flows)
Issue Categories
Use these labels when categorizing issues:
| Category | Covers |
|---|
[Security] | Secrets, XSS, input validation |
[Correctness] | Logic bugs, wrong behavior, missing requirements |
[Regression] | Breaking existing functionality |
[Performance] | Re-renders, bundle size, memoization |
[Theming] | Colors, dark/light/sepia mode |
[RTL] | Logical properties, layout direction |
[i18n] | Hardcoded strings, localization |
[A11y] | Accessibility issues |
[Testing] | Missing tests, untested scenarios |
[TypeScript] | Types, any usage, interfaces |
[React] | Patterns, hooks, state management |
[Clean Code] | DRY, KISS, SOLID violations |
[Polish] | Naming, formatting, comments, EOF |
Output Format
Use the format from docs/REVIEW_PROMPT.md:
- Summary (brief, note if part of PR chain)
- 📋 Previous Review Status (only for re-reviews: what was raised, what's addressed)
- 🔴 Critical Issues - Use
[Category] in title (e.g.,
#### 1. [Regression] Theme Settings Removed)
- 🟠 Medium Issues - Use
[Category] in title
- 🟡 Low Issues - Use
[Category] in title
- ✅ What's Done Well
- 🎯 Verdict (conversational conclusion)
Multi-PR Workflow
When reviewing multiple PRs:
- Review each PR individually following all steps above
- After each review, ask whether to:
- Post review to GitHub
- Make adjustments
- Continue to next PR
- After all PRs are reviewed, provide a brief summary of all reviews
Final Step
Ask me whether to post the review or make adjustments before posting to GitHub.
