Claude Code First PR Review Rubric : trouver le vrai risque avant le style

Sans grille, Claude Code peut placer une régression production et une remarque de nommage au même niveau. Cela paraît actif, mais n’aide pas à savoir ce qui bloque le merge.

Ce guide construit une première grille de revue PR. Définissez P0 à P3, preuves, format de commentaire et règles de reprise avant de lire le diff.

À lire aussi: claude-code-code-review-checklist, claude-code-prompt-library-maintenance, claude-code-pull-request-quality. Base de documentation officielle: Anthropic Claude Code docs.

Pourquoi décider avant la première commande

trouver régressions, risques de permissions, perte de données et tests manquants avant le style

Le point important est de garder la première demande petite. Définissez le périmètre de lecture, les zones protégées, la première action et la preuve avant toute édition.

développeurs qui utilisent Claude Code en revue et veulent des constats plus nets

Flux de travail pratique

1. Coller objectif et fichiers modifiés avant le diff
2. Définir P0 à P3 avant la revue
3. Interdire les commentaires sans preuve
4. Exiger test, build ou reproduction
5. Garder les remarques P3 de style pour la fin

Situation	Ce que Claude Code fait	Preuve vérifiée par l’humain
PR auth	Traiter tokens et limites de permission en P0	build, diff, URL
Correctif UI	Vérifier clics cassés et mobile en P1	build, diff, URL
Refactor	Séparer preuve de comportement et manque de tests en P2	build, diff, URL

Avec cette preuve, Claude Code est évalué sur un travail observable plutôt que sur une note de fin convaincante.

Prompt et code à copier

Relis ce diff PR avec sévérité P0/P1/P2/P3. P0 signifie sécurité, perte de données, paiement, auth ou panne production. Chaque constat contient ligne, scénario d'échec, preuve nécessaire et correctif. Mets le style à la fin.

const reviewRubric = {
  P0: "security, data loss, payment, auth, production outage",
  P1: "user-visible regression or broken release path",
  P2: "test gap, unclear edge case, maintainability risk",
  P3: "style, naming, or optional cleanup"
};

function classifyReviewFinding(finding) {
  const text = finding.toLowerCase();
  if (/auth|token|payment|delete|secret|production/.test(text)) return "P0";
  if (/regression|broken|crash|deploy/.test(text)) return "P1";
  if (/missing test|edge case|unclear/.test(text)) return "P2";
  return "P3";
}

console.log(classifyReviewFinding("missing test for failed payment retry"));

Exemples réels et erreurs

Situation	Ce que Claude Code fait	Preuve vérifiée par l’humain
PR auth	Traiter tokens et limites de permission en P0	build, diff, URL
Correctif UI	Vérifier clics cassés et mobile en P1	build, diff, URL
Refactor	Séparer preuve de comportement et manque de tests en P2	build, diff, URL

• Si nommage et format arrivent d’abord, Claude Code remplit la revue de notes faibles.
• Sans sévérité, bug paiement et ponctuation se mélangent.
• Sans preuve demandée, les commentaires plausibles mais non testés augmentent.

Le point important est de garder la première demande petite. Définissez le périmètre de lecture, les zones protégées, la première action et la preuve avant toute édition.

Ce qu’il faut garder comme preuve

trouver régressions, risques de permissions, perte de données et tests manquants avant le style devient plus utile quand il reste sous forme de paquet de preuves plutôt que comme un chat isolé. Gardez la demande initiale, les fichiers lus par Claude Code, les zones non touchées, les commandes lancées, l’URL publique ou le screenshot, et la décision encore incertaine. La session suivante peut reprendre le même jugement sans reconstruire le contexte.

Pour développeurs qui utilisent Claude Code en revue et veulent des constats plus nets, le but n’est pas d’écrire un manuel lourd dès le premier jour. Testez le modèle sur une PR, une note ou un déploiement. En cas d’échec, ajoutez l’échec à la checklist et relancez une version plus petite. Élargissez l’accès Claude Code seulement quand build, diff, URL, CTA et rollback sont visibles. Ouvrir les permissions avant les preuves semble rapide, mais transfère le coût de vérification à la prochaine revue humaine.

Le parcours revenu suit la même logique. Si le lecteur bloque encore sur les commandes de base, le PDF gratuit est la bonne étape. S’il répète le même prompt chaque semaine, Gumroad devient utile. S’il prend des décisions d’équipe ou de production, la consultation est plus adaptée. L’article ne doit pas pousser tout le monde à acheter; il doit envoyer vers le guide payant seulement les lecteurs qui ont besoin de prompts de revue PR et grilles réutilisables, et renvoyer les autres vers le PDF gratuit ou les articles liés.

Relier PDF gratuit, Gumroad et consultation

Si les commandes de base restent floues, commencez par la fiche gratuite. Pour approfondir prompts de revue PR et grilles réutilisables, utilisez le guide Gumroad. Si le travail implique adoption d’équipe, règles de revue ou parcours revenus, passez à la consultation. La comparaison des produits commence sur products.

Le CTA ne doit pas rester seulement en bas. Au début, le PDF gratuit réduit la friction. Après l’exemple pratique, Gumroad est logique. Quand le sujet touche l’équipe ou la production, la consultation devient naturelle.

Chiffres à suivre après publication

Après publication, suivre les clics vers Prompt Templates, le futur Code Review System et consultation.

Ne jugez pas seulement avec les PV. Séparez lecture du début, clics internes, inscriptions au PDF gratuit, clics Gumroad et visites consultation. HTTP 200, h1, canonical, heroImage, CTA et corps localisé doivent viser le même slug.