Code review de PR pragmatique

---
name: code-review-pr-pragmatique
description: "Review structurée d'une pull request sans nitpicking. Tableau Markdown classé Bloquant / Suggestion / Nit, avec fichier:ligne, description précise, snippet de fix proposé, et verdict final approuver / demander changements / discuter. À utiliser quand un dev (tech lead, staff engineer, freelance senior) doit relire une PR GitHub, GitLab ou Bitbucket avant merge sans transformer la review en fleuve de commentaires de style."
metadata:
  iaskills_title: "Code review de PR pragmatique"
  metier_slug: dev
  metiers:
    - Devs et tech leads
  secteur: "Tech & DSI"
  tier: free
  compatible:
    - claude-code
    - cowork
    - cursor
    - codex
  version: "1.0.0"
  author: "iaskills"
  editorial:
    pitch: "Review de PR structurée sans nitpicking. Tableau Bloquant / Suggestion / Nit, fichier:ligne, snippet de fix, verdict clair. 15 min au lieu d'une heure."
    long_description: "Code review de pull request calibrée pour tech leads et staff engineers qui veulent une review utile, pas un fleuve de commentaires de style. Lit le diff et produit un tableau Markdown structuré : Bloquant (sécurité, bug, casse prod), Suggestion (clarté, maintenabilité, perf), Nit (style, naming, doc). Chaque ligne contient le fichier:ligne, la description du point, et un snippet de fix proposé. Termine par un verdict explicite : approuver, demander changements, ou discuter en synchrone. Couvre les 4 angles d'une review pragmatique : sécurité (OWASP, secrets, injection), bugs (edge cases, null, race), maintenabilité (nommage, duplication, dette), tests (présence, couverture, edge cases). Pas de commentaire sur le style si un linter le couvre déjà. Format prêt à coller dans GitHub PR review, GitLab MR review ou Bitbucket."
    bullets:
      - "Tableau Markdown Bloquant / Suggestion / Nit"
      - "Fichier:ligne et snippet de fix par point"
      - "4 angles couverts : sécurité, bug, maintenabilité, tests"
      - "Verdict explicite : approuver / changements / discuter"
      - "Pas de nitpicking si linter couvre déjà"
    exemple_avant: "Vous lisez 600 lignes de diff sur une PR critique, vous laissez 27 commentaires en 1h, dont 18 sur le style. L'auteur soupire, vous oubliez 2 problèmes de sécurité. Le merge prend 3 jours."
    exemple_apres: "Review en 15 min : tableau de 8 points dont 2 bloquants sécurité, 4 suggestions architecture, 2 nits. Auteur fixe les bloquants en 30 min, merge sous 24h. Plus de friction inutile."
    recommended_metiers: []
    secteurs:
      - tech-dsi
      - startup-vc
    metiers_individuels:
      - dev-backend
      - dev-frontend
      - cto
      - chef-de-projet-it
      - architecte-si
      - qa-engineer
      - devops
      - rssi-cybersecurite
---

# Review de pull request pragmatique

## Quand utiliser ce skill

Déclencher quand un dev (tech lead, staff engineer, freelance senior, dev backend ou frontend) doit reviewer une pull request sur GitHub, GitLab ou Bitbucket avant merge.

À utiliser pour :
- Review de PR feature (nouvelle fonctionnalité produit)
- Review de PR refacto (extract function, rename, déduplication)
- Review de PR bugfix (correction prod ou hotfix)
- Review de PR migration (Next 14 → 15, Python 3.10 → 3.12, lib version)
- Review de PR sécurité (CVE, dependabot, secrets rotation)

Ne pas utiliser pour :
- Review d'architecture globale (utiliser un skill ADR à la place)
- Review de design / UX (hors périmètre code)
- Review de doc seule (ne mérite pas le format tableau)

## Ce que tu dois faire

### Étape 1, collecter le contexte

Demander à l'utilisateur (ou lire dans la PR) :

1. **URL de la PR** ou diff brut collé
2. **Type de PR** : feature, refacto, bugfix, migration, sécurité
3. **Stack** : langage principal, framework (Next.js, Django, FastAPI, Spring, Rails)
4. **Sensibilité** : prod critique (paiement, auth, données santé), produit standard, interne / outil
5. **Conventions du projet** : style guide existant (Prettier, ESLint, Black, gofmt), tests obligatoires, ADR à respecter
6. **Niveau de l'auteur** : junior (pédagogique), confirmé (efficace), senior (peer review)

### Étape 2, lire le diff

Parcourir fichier par fichier dans cet ordre de priorité :

1. **Fichiers de config et secrets** : `.env*`, `config/`, `secrets/`, `terraform/`, `kubernetes/`. Risque sécurité élevé.
2. **Fichiers d'auth et de paiement** : middleware d'auth, routes de paiement, webhooks Stripe.
3. **Fichiers de modèle de données** : migrations Prisma, Drizzle, Alembic, Active Record. Risque casse prod.
4. **Fichiers de logique métier** : services, use cases, controllers.
5. **Fichiers de présentation** : components, pages, templates.
6. **Tests** : présence, couverture, edge cases.

### Étape 3, classifier chaque point

Pour chaque problème détecté, classer dans une des trois catégories :

**Bloquant** (must-fix avant merge) :
- Vulnérabilité de sécurité OWASP Top 10 (SQL injection, XSS, IDOR, SSRF, CSRF)
- Secret hardcodé (clé API, password, token)
- Bug fonctionnel évident (null deref, race condition, regression)
- Casse de contrat API public (breaking change non versionné)
- Test obligatoire absent sur logique critique

**Suggestion** (à discuter, pas bloquant) :
- Architecture améliorable (extract function, séparation responsabilités)
- Performance sub-optimale mais acceptable (N+1, cache manquant)
- Dette technique introduite (TODO non traqué, couplage)
- Nommage ambigu sur API publique
- Test partiel (covers happy path mais pas edge cases)

**Nit** (préférence personnelle, mergeable) :
- Style si pas couvert par linter
- Variable peu parlante en interne
- Commentaire utile à ajouter
- Réordonnancement de paramètres

Si un linter ou formatter existe (Prettier, Black, gofmt, rustfmt), ne pas commenter le style. Le linter le fera.

### Étape 4, formuler le tableau

Structure exacte :

```markdown