review-branch

Perform a comprehensive read-only review of code changes.

**Scope:** By default, review the current git branch changes using the command below. However, if the user specifies a different scope (e.g., specific files, a directory, a PR, or a commit range), respect that and adjust your review accordingly.

**CRITICAL: This is a READ-ONLY review. Do NOT:**
- Make any code changes
- Create or modify files
- Run git commands (commit, push, merge, etc.)
- Only exception: You may run git commands to READ information (diff, log, status, show)

**Steps:**

1. **Gather changes** - For default branch review, run this command:
```bash
MAIN_WORKTREE=$(git worktree list | head -1 | awk '{print $1}'); CURRENT_DIR=$(git rev-parse --show-toplevel); if [ "$MAIN_WORKTREE" != "$CURRENT_DIR" ]; then BASE=$(git -C "$MAIN_WORKTREE" branch --show-current); else BASE="main"; fi; echo "=== Base branch: $BASE ===" && echo "" && echo "=== STATUS ===" && git status && echo "" && echo "=== COMMIT LOG ===" && git log $BASE..HEAD --oneline && echo "" && echo "=== COMMITTED CHANGES ===" && git diff $BASE...HEAD && echo "" && echo "=== UNCOMMITTED CHANGES ===" && git diff HEAD
```
  - If in a worktree, this uses the repo root's current branch as the base (not main)
  - If not in a worktree, uses `main` as the base branch (unless the user specifies otherwise)
  - **IMPORTANT**: This includes BOTH committed changes (vs base branch) AND uncommitted/unstaged changes

2. **Parallel Analysis** - After gathering the diff, launch sub-agents IN PARALLEL using the Task tool to analyze each area concurrently:
  - Sub-agent 1: Security Issues analysis
  - Sub-agent 2: Performance Concerns analysis
  - Sub-agent 3: Cross-Platform Compatibility analysis
  - Sub-agent 4: Type Safety and DRY Violations analysis
  - Sub-agent 5: Potential Bugs and Cleanup analysis
  - Sub-agent 6: Analytics Events and CLAUDE.md Documentation analysis
  - Sub-agent 7: Jotai Patterns Compliance analysis (see docs/JOTAI.md for patterns)

   Each sub-agent should receive the diff content and return findings for its specific area. Wait for all sub-agents to complete, then synthesize their findings into the final report.

**Analysis Required:**

Provide your review in the following format:

## Branch Summary
[Brief 2-3 sentence description of what this branch does]

## Detailed Findings

### Database Changes
[List any schema changes, migrations, new tables/columns, or note "None"]

### Security Issues
[List potential security vulnerabilities:]
- XSS vulnerabilities
- SQL injection risks
- Exposed secrets/API keys
- Authentication/authorization gaps
- Unsafe deserialization
- Missing input validation
[Note "None found" if clean]

### Performance Concerns
[List potential performance issues:]
- N+1 queries
- Inefficient loops or algorithms
- Memory leaks
- Missing database indexes
- Large payload sizes
- Unnecessary re-renders
[Note "None found" if clean]

### Cross-Platform Compatibility (OSX/Windows/Linux)
[Check for platform-specific issues that could break functionality on different operating systems:]
- **File paths**: Hardcoded separators (/ vs \) instead of path.join() or path.resolve()
- **Keyboard shortcuts**: Hardcoded 'Meta' or 'Cmd' instead of platform-aware shortcuts (should use 'CmdOrCtrl' or detect platform)
- **Environment variables**: Platform-specific env vars (e.g., HOME vs USERPROFILE)
- **System commands**: Bash/shell commands that don't work on Windows (should use cross-platform alternatives)
- **File system case sensitivity**: Code assuming case-insensitive file systems (macOS/Windows) that will break on Linux
- **Line endings**: Missing .gitattributes or code that assumes LF vs CRLF
- **Native dependencies**: Binaries or node modules that need platform-specific builds
- **Process handling**: Platform-specific process spawning or signal handling
- **File permissions**: Unix-style chmod/permissions that don't translate to Windows
- **Path length limits**: Windows MAX_PATH (260 char) limitations not accounted for
[Note "Fully compatible" or "Not applicable" if clean]

### Dependencies
[Check package.json, package-lock.json for changes:]
- New packages added: [name@version - purpose]
- Version updates: [name: old → new]
- Removed packages: [name]
[Note "No changes" if none]

### Logging Assessment
[Evaluate if logging is appropriate, too verbose, or missing. Note any console.log that should be removed]

### Type Safety Issues
[List any `any` types, missing type definitions, or type assertions that should be reviewed]

### DRY (Don't Repeat Yourself) Violations
[Identify duplicated code that should be extracted into shared utilities, functions, or components:]
- Repeated logic blocks across files
- Copy-pasted code with minor variations
- Similar patterns that could be abstracted
- Missed opportunities to use existing utilities
[Note "None found" if clean]

### Potential Bugs
[List specific scenarios that should be tested, edge cases not handled, null checks missing, etc.]
- Bug 1: [description]
- Bug 2: [description]

### Cleanup Needed
[List commented code, debug statements, unused imports, TODOs, etc.]
- Item 1: [description + file:line]
- Item 2: [description + file:line]

### Other Concerns
[Any additional issues not covered above:]
- Breaking changes to APIs or interfaces
- Missing error handling
- Accessibility issues
- Missing documentation
- Test coverage gaps

### Analytics Events
[Evaluate whether PostHog analytics events should be added for this feature/change. See docs/ANALYTICS_GUIDE.md for implementation details.]

Consider adding analytics for:
- New user-facing features (track adoption/usage)
- New UI interactions (buttons, dialogs, workflows)
- Feature settings or preferences changes
- Error scenarios that would help diagnose issues
- Performance-sensitive operations (with timing categories)

Do NOT add analytics for:
- Internal refactors with no user-visible changes
- Bug fixes (unless tracking the bug occurrence is valuable)