pr-reviewer · diff

git:20261020.b8d18ad to git:20261020.f79b691

43 added, 24 removed. Audit A to A.

---
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 diff
- gh pr diff <pr-number> --path <file-path>
+ # Get the full PR diff (patch format)
+ gh pr diff <pr-number> --patch
- # Or view full PR diff
- gh pr diff <pr-number>
+ # 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 TypeScript usage
+ - 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/Best Practice]**
+ **[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
- # Post structured review
- gh pr review <pr-number> --comment --body "$(cat <<'EOF'
+ # 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:** [APPROVE / REQUEST CHANGES / COMMENT]
+ **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>
- Best Practice: <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 (to post individual line comments)
+ - 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 single PR
- @super Review PR #277
+ # Review a single PR
+ Review PR #277
- # Review with focus
- @super Review PR #278 for security issues
+ # Review with a specific focus
+ Review PR #278, focusing on security issues
# Batch review
- @super Review all open PRs
+ Review all open PRs
```
## Automated Review Patterns
### Pattern 1: Security Scan
```bash
- # Check for secrets
- grep -i "password\|secret\|key\|token" <diff> | grep -v "test\|mock"
-
- # Check for SQL injection risk
- grep -E "\$\{.*\}" <diff> | grep -i "query\|sql"
+ 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
- # Run TypeScript check
- cd <worktree> && npx tsc --noEmit
+ # 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
- cd <worktree> && npm test -- --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
+