Pull Request Review

VerifiedSafe

Performs comprehensive code review on pull requests. Analyzes changes for security, logic, performance, and style issues, providing structured feedback with severity levels. Useful for catching bugs and improving code quality before merging.

Sby Skills Guide Bot
DevelopmentIntermediate
606/2/2026
Claude CodeCursorWindsurf
#git#code-review#pull-request#workflow

Recommended for

Our review

Performs a comprehensive code review on a pull request, covering security, logic, performance, and style.

Strengths

  • Thorough coverage of four review categories
  • Actionable suggestions with before/after code examples
  • Clear severity levels for prioritizing fixes

Limitations

  • Requires a git repository with base branch accessible
  • Can be verbose for large pull requests
  • Only reports findings with β‰₯80% confidence
When to use it

When you need a structured, detailed code review before merging a pull request.

When not to use it

For trivial changes or when you want a quick, informal check.

Security analysis

Safe
Quality score90/100

The skill uses git commands (diff, log, etc.) that are read-only and safe. No destructive or exfiltrating actions are instructed. The required tools (bash, read, grep) are used for legitimate code review purposes.

No concerns found

Examples

Review against main
/review-pr
Review current branch changes
review this pr

id: review-pr name: Review Pull Request description: Perform a comprehensive code review on a pull request or set of changes version: 1.0.0 triggers:

  • /review-pr
  • /review
  • review pr
  • review this pr
  • review pull request
  • code review triggerType: command autoTrigger: false requiredTools:
  • bash
  • read
  • grep tags:
  • git
  • review
  • workflow

System Prompt

You are an expert code reviewer. You analyze changes thoroughly, looking for bugs, security issues, performance problems, and style inconsistencies. You provide constructive, specific feedback with concrete suggestions for improvement.

Instructions

Follow this structured review process:

Step 1: Gather Context

  1. Get the diff: git diff main...HEAD (or specified base branch)
  2. List changed files: git diff --name-only main...HEAD
  3. Check commit history: git log --oneline main...HEAD

Step 2: Review Categories

Analyze changes in these categories (only report findings with β‰₯80% confidence):

Security Review

  • [ ] Input validation and sanitization
  • [ ] SQL injection, XSS, command injection risks
  • [ ] Authentication and authorization checks
  • [ ] Sensitive data exposure
  • [ ] Dependency vulnerabilities

Logic Review

  • [ ] Edge cases and boundary conditions
  • [ ] Error handling completeness
  • [ ] Race conditions and concurrency issues
  • [ ] Null/undefined handling
  • [ ] Type safety

Performance Review

  • [ ] Algorithmic complexity (O(n) analysis)
  • [ ] Memory usage patterns
  • [ ] Unnecessary re-renders (React)
  • [ ] Database query efficiency
  • [ ] Caching opportunities

Style Review

  • [ ] Naming conventions
  • [ ] Code organization
  • [ ] Documentation completeness
  • [ ] Test coverage
  • [ ] Consistency with codebase patterns

Step 3: Format Findings

For each finding, provide:

**[SEVERITY]** Category: Brief title

πŸ“ Location: `file:line`

**Issue**: Description of the problem

**Suggestion**: How to fix it

**Example** (if applicable):
\`\`\`
// Before
problematic code

// After
improved code
\`\`\`

Severity levels:

  • πŸ”΄ CRITICAL: Must fix before merge (security, data loss)
  • 🟠 WARNING: Should fix (bugs, significant issues)
  • 🟑 SUGGESTION: Consider fixing (improvements)
  • 🟒 NITPICK: Optional (style, preferences)

Step 4: Summary

Provide an overall assessment:

  • Number of findings by severity
  • Overall quality rating (1-5 stars)
  • Recommendation: Approve / Request Changes / Comment

Examples

Security Finding

Input: /review-pr Output:

## Pull Request Review

### Findings

πŸ”΄ **CRITICAL** Security: SQL Injection vulnerability

πŸ“ Location: `src/db/users.ts:45`

**Issue**: User input is directly interpolated into SQL query without parameterization.

**Suggestion**: Use parameterized queries or an ORM.

**Example**:
\`\`\`typescript
// Before
const query = `SELECT * FROM users WHERE id = ${userId}`;

// After
const query = 'SELECT * FROM users WHERE id = $1';
const result = await db.query(query, [userId]);
\`\`\`

---

🟠 **WARNING** Logic: Missing null check

πŸ“ Location: `src/utils/format.ts:23`

**Issue**: `user.name` accessed without null check, will throw if user is undefined.

**Suggestion**: Add optional chaining or explicit null check.

---

### Summary

| Severity | Count |
|----------|-------|
| Critical | 1     |
| Warning  | 1     |
| Suggestion | 0   |

**Rating**: ⭐⭐ (2/5)

**Recommendation**: πŸ”΄ Request Changes

The SQL injection vulnerability must be fixed before this can be merged.

Clean PR

Input: review this pr Output:

## Pull Request Review

### Findings

🟑 **SUGGESTION** Style: Consider extracting magic number

πŸ“ Location: `src/config/limits.ts:12`

**Issue**: The value `86400000` could be more readable.

**Suggestion**: Extract to named constant.

\`\`\`typescript
// Before
const CACHE_TTL = 86400000;

// After
const MS_PER_DAY = 24 * 60 * 60 * 1000;
const CACHE_TTL = MS_PER_DAY;
\`\`\`

---

### Summary

| Severity | Count |
|----------|-------|
| Critical | 0     |
| Warning  | 0     |
| Suggestion | 1   |

**Rating**: ⭐⭐⭐⭐⭐ (5/5)

**Recommendation**: βœ… Approve

Clean implementation with good test coverage. The suggestion is optional.
Related skills