Revue de Code

VérifiéSûr

Effectue une revue de code rapide et ciblée sur des fichiers ou modifications récentes, en vérifiant les bugs, les bonnes pratiques et les améliorations potentielles.

Spar Skills Guide Bot
DeveloppementIntermédiaire
3002/06/2026
Claude Code
#code-review#best-practices#security#performance

Recommandé pour

Notre avis

Effectue une revue de code rapide et ciblée sur des fichiers spécifiques ou des modifications récentes (diff, staged, dernier commit).

Points forts

  • Détecte les bugs et failles de sécurité courantes
  • Propose des correctifs concrets avec code avant/après
  • Catégorise les problèmes par sévérité (critique, avertissement, suggestion)
  • S'adapte au contexte du projet (WebFlux, threads virtuels)

Limites

  • Ne remplace pas une revue humaine approfondie
  • Peut manquer des problèmes métier complexes
  • Dépend de la qualité du diff ou des fichiers fournis
Quand l'utiliser

Pour un premier niveau de vérification avant merge, un retour rapide sur du code existant, ou pour vérifier les bonnes pratiques dans un fichier modifié.

Quand l'éviter

Pour une revue architecturale globale ou une analyse sémantique profonde nécessitant une compréhension fine du domaine métier.

Analyse de sécurité

Sûr
Score qualité90/100

The skill instructs the agent to perform code review using safe operations like reading files and running git diff/show commands. No destructive actions, exfiltration, or unsafe command execution is involved. User input is used as arguments to git, which is not a shell injection risk here.

Aucun point d'attention détecté

Exemples

Review a specific file
/review src/main/java/com/example/service/ForecastService.java
Review recent uncommitted changes
/review changes
Review the last commit
/review last-commit

name: review description: Quick code review for files or recent changes, checking for bugs, best practices, and potential improvements

Review Skill

Perform a quick, focused code review on specified files or recent git changes.

Instructions

1. Determine Review Scope

Parse the user's request to determine what to review:

  • Specific file(s): /review src/main/java/.../MyService.java
  • Recent changes: /review changes or /review diff
  • Staged changes: /review staged
  • Last commit: /review last-commit
  • Feature/component: /review ForecastService (find and review related files)

2. Gather Code to Review

Based on scope:

For specific files:

  • Use Read to load the file content

For git changes:

  • Use Bash with git diff for unstaged changes
  • Use Bash with git diff --cached for staged changes
  • Use Bash with git show HEAD for last commit
  • Use Bash with git diff HEAD~N for recent N commits

For component/feature:

  • Use Glob and Grep to find relevant files
  • Read the main files involved

3. Review Checklist

Analyze the code for:

Correctness

  • Logic errors or bugs
  • Off-by-one errors
  • Null/undefined handling
  • Edge cases not covered
  • Incorrect assumptions

Security

  • Input validation issues
  • Injection vulnerabilities (SQL, command, XSS)
  • Hardcoded secrets or credentials
  • Unsafe data handling

Performance

  • Inefficient algorithms (O(n²) when O(n) possible)
  • Unnecessary iterations or allocations
  • Missing caching opportunities
  • Blocking calls in reactive code

Best Practices

  • Code style consistency
  • Naming conventions
  • Error handling patterns
  • Resource cleanup (try-with-resources, close())
  • Thread safety in concurrent code

Maintainability

  • Code duplication
  • Overly complex methods (consider splitting)
  • Missing or misleading comments
  • Dead code

Project-Specific (varun.surf)

  • Reactive patterns (WebFlux compliance)
  • Proper use of virtual threads/StructuredTaskScope
  • Cache invalidation concerns
  • External API error handling

4. Severity Levels

Categorize findings:

  • Critical: Bugs, security issues, data loss risks
  • Warning: Performance issues, bad practices, potential bugs
  • Suggestion: Style improvements, minor optimizations, readability

Output Format

## Code Review: [File/Scope]

### Summary
- Files reviewed: X
- Lines analyzed: Y
- Issues found: Z (X critical, Y warnings, Z suggestions)

### Critical Issues

#### [Issue Title]
**File**: `path/to/file.java:line`
**Problem**: [Description]
**Fix**: [Suggested solution]
```java
// Before
problematic code

// After
fixed code

Warnings

[Issue Title]

File: path/to/file.java:line Problem: [Description] Suggestion: [How to improve]

Suggestions

  • file.java:42 - Consider extracting this to a method
  • file.java:78 - Variable name could be more descriptive

What Looks Good

  • Proper error handling in [location]
  • Good use of [pattern/practice]
  • Clean separation of concerns

Files Reviewed

  • path/to/file1.java - [brief note]
  • path/to/file2.java - [brief note]

## Examples

```bash
# Review a specific file
/review src/main/java/com/github/pwittchen/varun/service/ForecastService.java

# Review recent uncommitted changes
/review changes

# Review staged changes before commit
/review staged

# Review the last commit
/review last-commit

# Review a component by name
/review AggregatorService

# Review multiple files
/review src/main/java/.../controller/*.java

Notes

  • Keep reviews focused and actionable
  • Prioritize critical issues over style nitpicks
  • Provide concrete fix suggestions, not just problem descriptions
  • Reference project patterns from CLAUDE.md when relevant
  • For large diffs, focus on the most impactful changes
  • Don't repeat issues that appear multiple times; note "X similar occurrences"
Skills similaires