# Code Review

> Guide structuré de code review utilisant repo_consistency_check, impact_analysis et code_refactoring. Utilise cette skill quand l'utilisateur demande une revue de code, un review de PR, ou veut améliorer la qualité d'un codebase. Use when this capability is needed.

- Skill: `tomevault-io/code-review-111` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add tomevault-io/code-review-111`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/code-review-111/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: tomevault-io (https://skillmd.com/u/tomevault-io)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/tomevault-io/code-review-111

---


# Code Review — Workflow Collègue

Tu réalises un code review structuré en 5 dimensions. Pour chaque dimension, utilise les outils MCP Collègue appropriés.

## Étape 1 : Analyse de cohérence automatique

Appelle `repo_consistency_check` sur les fichiers modifiés.

**Paramètres :**
- `files` : liste des fichiers modifiés `{path, content}`
- `checks` : tous (`['unused_imports', 'unused_vars', 'dead_code', 'duplication', 'signature_mismatch', 'unresolved_symbol']`)
- `mode` : `'deep'` pour un review complet

**Attention particulière :**
- **Imports inutilisés** → le développeur a peut-être oublié de nettoyer après refactoring
- **Variables non utilisées** → possible code incomplet ou copié-collé
- **Code mort** → fonctions jamais appelées, branches mortes
- **Duplication** → opportunité d'extraction de fonctions utilitaires
- **Symboles non résolus** → imports manquants, fautes de frappe

## Étape 2 : Analyse d'impact

Appelle `impact_analysis` pour comprendre la portée du changement.

**Paramètres :**
- `change_intent` : description du changement (extraire du titre de PR ou du commit message)
- `files` : tous les fichiers du contexte (pas seulement les modifiés)
- `analysis_depth` : `'deep'`

**Questions à poser :**
- Quels fichiers non modifiés pourraient être affectés ?
- Y a-t-il des breaking changes potentiels ?
- Les tests existants couvrent-ils les fichiers impactés ?
- Y a-t-il des risques de régression ?

## Étape 3 : Review des 5 dimensions

Pour chaque dimension, évalue le code sur une échelle de 1-5 :

### 3.1 Correctness (Exactitude)
- Le code fait-il ce qu'il est censé faire ?
- Les edge cases sont-ils gérés ?
- Les erreurs sont-elles correctement propagées ?
- Les types sont-ils corrects (TypeScript strict, Python type hints) ?

### 3.2 Security (Sécurité)
- Y a-t-il des inputs non validés ?
- Les données sensibles sont-elles protégées ?
- Les requêtes SQL sont-elles paramétrées ?
- Les permissions sont-elles vérifiées ?
- Appeler `secret_scan` si des fichiers de config sont modifiés

### 3.3 Performance
- Y a-t-il des boucles O(n²) évitables ?
- Les requêtes DB sont-elles optimisées (N+1, SELECT *) ?
- Le caching est-il utilisé quand approprié ?
- Les opérations I/O sont-elles asynchrones quand possible ?

### 3.4 Maintainability (Maintenabilité)
- Le code est-il lisible et bien nommé ?
- Les fonctions font-elles une seule chose (SRP) ?
- Les abstractions sont-elles au bon niveau ?
- La documentation est-elle suffisante ?

### 3.5 Testing
- Les nouveaux chemins de code sont-ils testés ?
- Les edge cases ont-ils des tests ?
- Les mocks sont-ils appropriés (pas trop, pas trop peu) ?
- Appeler `test_generation` si la couverture semble insuffisante

## Étape 4 : Propositions de refactoring

Si des problèmes de maintenabilité sont détectés, appelle `code_refactoring` :

**Types de refactoring par situation :**
| Problème détecté | Type de refactoring |
|-----------------|-------------------|
| Fonction trop longue (>50 lignes) | `extract` |
| Nommage confus | `rename` |
| Logique trop complexe (cyclomatic > 10) | `simplify` |
| Boucles inefficaces | `optimize` |
| Code legacy / patterns obsolètes | `modernize` |
| Imports inutilisés, code mort | `clean` |

## Étape 5 : Rapport de review

Structure ton feedback ainsi :

```markdown
# Code Review — [PR/fichier]

## Score global : X/5

| Dimension | Score | Détail |
|-----------|-------|--------|
| Correctness | X/5 | ... |
| Security | X/5 | ... |
| Performance | X/5 | ... |
| Maintainability | X/5 | ... |
| Testing | X/5 | ... |

## Blockers (à corriger avant merge)
- [ ] [problème critique]

## Suggestions (améliorations recommandées)
- [ ] [suggestion]

## Nits (cosmétique, non-bloquant)
- [ ] [détail mineur]

## Points positifs
- [ce qui est bien fait]
```

## Patterns et anti-patterns

Pour le catalogue complet des design patterns et anti-patterns, consulte [patterns.md](patterns.md).

---
> Converted and distributed by [TomeVault](https://tomevault.io/claim/vynodepal) — claim your Tome and manage your conversions.
<!-- tomevault:4.0:skill_md:2026-04-13 -->