Review

---
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

1. Read the review prompt from `docs/REVIEW_PROMPT.md` for all criteria
2. Fetch PR details: `gh pr view {PR_NUMBER} --json title,body,files,additions,deletions,author`
3. Fetch PR diff: `gh pr diff {PR_NUMBER}`
4. If files changed > 15, flag for potential split before deep review
5. **Check for previous reviews** (see Re-review Protocol below)

## Re-review Protocol

Before reviewing, check if this PR has been previously reviewed:

1. **Fetch previous reviews and comments:**

   ```bash
   gh pr view {PR_NUMBER} --json reviews,comments
   ```

2. **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:

1. **Critical**: Security, error handling, rendering strategy, correctness, breaking changes
2. **Standard**: TypeScript, React patterns, localization/RTL, performance, accessibility
3. **Clean Code**: DRY, KISS, single responsibility, separation of concerns, SOLID
4. **Polish**: Function size, comments, dead code, console.log, naming
5. **Watch Out For**: Common bug patterns
6. **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)
7. **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:

1. Review each PR individually following all steps above
2. After each review, ask whether to:
   - Post review to GitHub
   - Make adjustments
   - Continue to next PR
3. 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.