pr-reviewer git:20261020.f79b691A

Immutable. This exact content never changes and is served at /api/v1/blob/71cb6e6a7000280f.

---
name: pr-reviewer
description: Performs comprehensive code review on Pull Requests in the target repository. Analyzes code quality, security, performance, and best practices. Posts structured review comments via GitHub CLI. Use when reviewing PRs for quality assurance, before merging, or as part of the pr-manager workflow. Triggers on requests like "review PR", "code review", "PR quality check", or when pr-manager requests reviews.
---
# PR Reviewer

Performs automated and manual code reviews on Pull Requests with structured feedback.

## Workflow

### Step 1: Fetch PR Details

```bash
# Get PR metadata
gh pr view <pr-number> --json number,title,headRefName,baseRefName,author,body,files

# Get changed files with patch
gh pr view <pr-number> --json files --jq '.files[] | {path: .path, additions: .additions, deletions: .deletions}'
```

### Step 2: Analyze Code Changes

For each file changed:

```bash
# Get the full PR diff (patch format)
gh pr diff <pr-number> --patch

# Or get per-file patches via the API (gh only expands {owner}/{repo}/{branch})
gh api "repos/{owner}/{repo}/pulls/<pr-number>/files" \
  --jq '.[] | {filename, additions, deletions, patch}'
```

**Analysis dimensions:**

Only apply framework-specific checks when the repo uses that stack (e.g. skip the React items in a Python repo).

1. **Code Quality**
  - Type safety and proper usage of the repo's language (e.g. TypeScript)
  - Error handling coverage
  - Test coverage for new code
  - Code duplication
  - Complexity and maintainability
2. **Security**
  - No secrets or credentials in code
  - Proper input validation
  - SQL injection prevention
  - XSS prevention
  - Authentication/authorization checks
3. **Performance**
  - Database query efficiency
  - N+1 query detection
  - Unnecessary re-renders (React)
  - Memory leaks
  - Bundle size impact
4. **Best Practices**
  - Follows project conventions
  - Proper documentation
  - Consistent naming
  - Clean architecture patterns

### Step 3: Generate Review Comments

**Comment format:**

```markdown
**[Severity: HIGH/MEDIUM/LOW] [Category: Security/Quality/Performance/Testing/Documentation/Architecture/Maintainability/Compatibility]**

**Issue:** Brief description of the problem

**Location:** `file.ts:line-number`

**Current code:**
```typescript
// problematic code snippet
```

**Suggested fix:**

```typescript
// improved code snippet
```

**Reasoning:** Why this matters and the impact

```

**Category taxonomy (shared with pr-commenter)**: `Security, Quality, Performance, Testing, Documentation, Architecture, Maintainability, Compatibility`

### Step 4: Post Review

`--comment`, `--approve` and `--request-changes` are mutually exclusive; pick exactly one to match the assessment.

```bash
# Choose the flag from the assessment (exactly one):
#   APPROVE         -> gh pr review <pr-number> --approve --body "…"
#   REQUEST CHANGES -> gh pr review <pr-number> --request-changes --body "…"
#   COMMENT         -> gh pr review <pr-number> --comment --body "…"
gh pr review <pr-number> --request-changes --body "$(cat <<'EOF'
## Code Review Summary

**Overall assessment:** [APPROVED / CHANGES_REQUESTED / COMMENTED]

**Key findings:**
- <N> security issues
- <N> quality improvements
- <N> performance optimizations
- <N> best practice suggestions

### Detailed Comments

<individual comments from Step 3>

### Action Items

**Must fix (blocking):**
- [ ] Issue 1
- [ ] Issue 2

**Should fix (non-blocking):**
- [ ] Suggestion 1
- [ ] Suggestion 2

**Consider (optional):**
- Idea 1
- Idea 2
EOF
)"
```

### Step 5: Report to PR Manager

Return structured result:

```yaml
Review Complete:
  PR: <number>
  Status: <APPROVED / CHANGES_REQUESTED / COMMENTED>
  Severity Count:
    HIGH: <N>
    MEDIUM: <N>
    LOW: <N>
  Categories:
    Security: <N>
    Quality: <N>
    Performance: <N>
    Testing: <N>
    Documentation: <N>
    Architecture: <N>
    Maintainability: <N>
    Compatibility: <N>
  Blocking Issues: <N>
  Non-Blocking: <N>
  Action: <proceed / fix_required / needs_discussion>
```

## Review Checklist

### Security (Always check)

- [ ] No hardcoded secrets, API keys, passwords
- [ ] Input validation on all user inputs
- [ ] SQL queries use parameterized statements
- [ ] No eval() or dangerous dynamic code
- [ ] Proper authorization checks

### Type Safety

- [ ] All functions have proper types
- [ ] No `any` types without justification
- [ ] Return types defined
- [ ] Edge cases handled

### Testing

- [ ] New code has unit tests
- [ ] Tests cover edge cases
- [ ] No test coverage regression
- [ ] Integration tests where appropriate

### Performance

- [ ] Database queries efficient
- [ ] No N+1 queries
- [ ] Proper React memoization
- [ ] No unnecessary API calls

### Documentation

- [ ] Complex functions documented
- [ ] API changes documented
- [ ] README updated if needed
- [ ] Breaking changes noted

## Severity Levels

**HIGH (Blocking)**

- Security vulnerabilities
- Breaking changes without migration
- Critical bugs
- Missing required tests

**MEDIUM (Should fix)**

- Type safety issues
- Performance problems
- Code duplication
- Error handling gaps

**LOW (Nice to have)**

- Naming improvements
- Style consistency
- Documentation additions
- Refactoring suggestions

## Integration

**Called by:**

- pr-manager (as part of review queue)
- User for individual PR review
- Automated review on PR open

**Calls to:**

- pr-commenter (posts line-level comments via the GitHub REST API — see pr-commenter)
- GitHub CLI for review submission

**Reports to:**

- pr-manager for queue management
- User for immediate feedback

## Example Commands

```
# Review a single PR
Review PR #277

# Review with a specific focus
Review PR #278, focusing on security issues

# Batch review
Review all open PRs
```

## Automated Review Patterns

### Pattern 1: Security Scan

```bash
gh pr diff <pr-number> --patch > /tmp/pr.diff
grep -inE "(password|secret|api[_-]?key|token)\s*[:=]\s*['\"][^'\"]{8,}" /tmp/pr.diff
```

### Pattern 2: Type Safety Check

```bash
# Worktree path convention (owned by pr-worktree):
WORKTREE_PATH=".worktrees/fix-issue-432-button-rendering"
cd "${WORKTREE_PATH}" && npx tsc --noEmit

# Report type errors as review comments
```

### Pattern 3: Test Coverage

```bash
# Run tests with coverage
WORKTREE_PATH=".worktrees/fix-issue-432-button-rendering"
cd "${WORKTREE_PATH}" && npm test -- --coverage

# Flag files with <80% coverage
```

## References

- [Acceptance Criteria](references/acceptance-criteria.md) — Required output format and validation scenarios
- [Best Practices](references/best-practices.md) — Review mindset, comment guidelines, severity assignment