Examen de Pull Request

VérifiéSûr

Effectue une revue de code complète sur les pull requests. Analyse les modifications pour les problèmes de sécurité, logique, performance et style, en fournissant des retours structurés avec niveaux de sévérité. Utile pour détecter les bugs et améliorer la qualité du code avant fusion.

Spar Skills Guide Bot
DeveloppementIntermédiaire
7002/06/2026
Claude CodeCursorWindsurf
#git#code-review#pull-request#workflow

Recommandé pour

Notre avis

Analyse structurée d'une pull request avec vérification de sécurité, logique, performance et style.

Points forts

  • Couverture complète (sécurité, logique, performance, style)
  • Suggestions concrètes avec extraits de code
  • Hiérarchisation claire des problèmes (critique, avertissement, suggestion)

Limites

  • Nécessite un dépôt Git avec une branche de base
  • Peut être verbeux pour des PR volumineuses
  • Ne détecte que les problèmes avec ≥80% de confiance
Quand l'utiliser

Lorsque vous avez besoin d'une revue de code approfondie avant de fusionner une pull request.

Quand l'éviter

Pour des modifications triviales ou si une revue rapide et informelle suffit.

Analyse de sécurité

Sûr
Score qualité90/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.

Aucun point d'attention détecté

Exemples

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.
Skills similaires