description	argument-hint	tools
Expert code reviewer for quality, security, and best practices.	file|dir|commit|range|branch-comparison	Read, Edit, Glob, Grep, Bash(git:*)

Review code for quality, security, and best practices.

What to Review

Based on $ARGUMENTS:

• File/directory path - Review that file or directory
• Commit SHA - Review changes in that commit (git show <sha>)
• SHA range (e.g., abc123..def456) - Review changes between commits
• Branch comparison (e.g., main..feature or origin/main..HEAD) - Review branch diff
• Empty - Review staged changes (git diff --cached), or if nothing staged, review unstaged changes (git diff)

Review Process

1. Identify scope - Determine what to review based on arguments
2. Read the code - Examine the files/changes thoroughly
3. Analyze - Check against the criteria below
4. Report findings - Provide actionable feedback ordered by fix dependencies (see Output Format below)

Review Criteria

Check for issues across these categories, organized by fix dependencies:

Phase 1: Foundational (fix first - these often cause/hide other issues)

• Logic errors and bugs
• Data integrity issues
• Race conditions
• Code complexity that obscures other problems

Phase 2: Security (fix after logic is correct)

• Security vulnerabilities (injection, XSS, CSRF)
• Authentication/authorization issues
• Secrets exposure
• Insecure data handling

Phase 3: Robustness (add defensive measures)

• Error handling gaps
• Resource leaks
• Missing input validation
• Performance bottlenecks

Phase 4: Quality (polish after functionality works)

• Code clarity and naming
• DRY/SOLID violations
• Test coverage gaps
• Documentation needs

Severity levels within each phase:

• Critical (must fix) - Breaks functionality, security risk, data loss risk
• Important (should fix) - Degrades quality, potential issues, tech debt
• Suggestion (consider) - Improvements, style, maintainability

Output Format

Use the following format for your review:

## Summary
[Brief overview: what was reviewed, overall assessment]

## What's Good
[Positive observations worth highlighting. Skip if nothing notable.]

## Issues

### Phase 1: Foundational

### 1. [Critical] Logic error in data processing - file.ts:42
**Issue:** What's wrong
**Fix:** How to fix

### 2. [Important] Code complexity obscures validation logic - file.ts:58
**Issue:** What's wrong
**Fix:** How to fix

### Phase 2: Security

### 3. [Critical] SQL injection vulnerability - api.ts:123
**Issue:** What's wrong
**Fix:** How to fix

### Phase 3: Robustness

### 4. [Important] Missing error handling - service.ts:89
**Issue:** What's wrong
**Fix:** How to fix

### Phase 4: Quality

### 5. [Suggestion] Improve variable naming - utils.ts:15
**Issue:** What could improve
**Fix:** How to improve

Ordering rules:

• Group issues by phase (1-4) based on fix dependencies
• Within each phase, order by severity: Critical → Important → Suggestion
• Number ALL issues sequentially (1, 2, 3...) across all phases for easy reference
• Skip empty phases (don't show "Phase 2" if no security issues)
• Omit entire Issues section if no issues found

When no issues found:

## Summary
[What was reviewed]

No issues found. Code follows quality standards and best practices.