Claude Code Small PR Proof Pack : rendre les petits changements reviewables

Un changement Claude Code n’est pas reviewable simplement parce que le diff est petit. Le reviewer doit connaître le but, les fichiers touchés, les commandes exécutées, l’URL publique vérifiée, le chemin CTA et la manière de revenir en arrière.

J’appelle cet ensemble Small PR Proof Pack. C’est le reçu de vérification d’un petit PR assisté par IA.

À lire aussi : review gate before commit, team handoff rules et build error triage loop. Références externes : Claude Code documentation, GitHub pull request docs, GitHub Actions docs.

Le pack minimum

small_pr_proof_pack:
  owner: "Masa"
  goal: "clarifier le CTA de l'article"
  changed_files:
    - "site/src/content/blog/example.mdx"
  verification:
    - command: "npm run build"
      result: "passed"
    - command: "node scripts/check-code-fences.mjs"
      result: "passed"
  public_checks:
    - url: "https://claudecode-lab.com/fr/blog/example/"
      checked:
        - "h1 correct"
        - "pas de scroll horizontal mobile"
        - "CTA vers le bon produit"
  rollback:
    command: "revert this PR"
    risk: "changement de contenu uniquement"

Les champs importants sont le but, le périmètre, les preuves, l’URL publique, la route business et le rollback.

Modèle de PR

## Goal
-

## Scope
- Changed:
- Not changed:

## Proof
- Command:
- Result:

## Public URL Check
- URL:
- H1:
- Mobile:
- Code block:
- CTA:

## Revenue Path Check
- Free PDF:
- Gumroad:
- Training/contact:

## Rollback
-

La ligne “Not changed” est essentielle avec Claude Code. Elle montre que le périmètre n’a pas glissé vers des scripts, produits ou réglages externes sans raison.

Trois cas utiles

Premier cas : un CTA d’article. Il faut vérifier le texte, le lien PDF gratuit, Gumroad, Products et la page de consultation.

Deuxième cas : un correctif de code block mobile. Un build peut passer alors qu’une longue ligne déborde sur un téléphone.

Troisième cas : un article multilingue. La version japonaise peut être solide alors que zh ou ko restent trop minces. Le pack doit indiquer les langues couvertes, les code fences et au moins une vérification visuelle représentative.

Gate simple

const proof = {
  filesChanged: 2,
  commands: ["npm run build"],
  publicUrlChecked: true,
  mobileChecked: true,
  revenuePathChecked: true,
  rollbackWritten: true,
};

export function isReadyToCommit(receipt) {
  return receipt.filesChanged <= 5 &&
    receipt.commands.length > 0 &&
    receipt.publicUrlChecked &&
    receipt.mobileChecked &&
    receipt.revenuePathChecked &&
    receipt.rollbackWritten;
}

Ce gate ne remplace pas la revue humaine. Il rend explicite le minimum à produire avant de demander une validation.

Pièges fréquents

Le pire PR dit seulement “fixed with Claude Code”. Le reviewer doit alors tout reconstruire. Autre piège : considérer le build comme preuve complète. Le build ne valide pas le H1, canonical, hero image, CTA, Gumroad ou layout mobile.

Le rollback est aussi souvent absent. Pour du contenu, revert peut suffire. Pour des liens produit, emails, variables Cloudflare ou réglages externes, il faut des étapes concrètes.

Un piège plus discret consiste à rendre le Proof Pack plus gros que le changement. Si le pack demande une longue explication, le PR mélange probablement copy, layout, tracking et liens produit. Il vaut mieux séparer. Claude Code peut traverser ces couches vite, mais le reviewer a besoin d’une histoire claire.

Chemin de monétisation

ClaudeCodeLab n’est pas seulement une base d’articles. Le site transforme le trafic en inscription, achat ou consultation. Les débutants peuvent aller vers le free cheatsheet, les utilisateurs réguliers vers 50 Prompt Templates, et les équipes vers le Setup Guide ou la consultation training.

Un PR de contenu doit donc vérifier le chemin de revenu dès qu’il touche au copy, aux CTA, aux cartes produit ou à la navigation.

La preuve doit rester précise. “CTA vérifié” est trop vague. Préfère : “le CTA final ouvre le free cheatsheet, la carte produit ouvre Prompt Templates, et le lien training ouvre la page française”. Si le trafic monte demain sans inscription, l’équipe saura tester l’angle de l’article, le texte du CTA, l’offre ou la mise en page.

Après publication

Le Proof Pack garde de la valeur après le merge. Note l’URL vérifiée, le CTA choisi et le risque restant dans le journal d’exploitation. Le lendemain, compare impressions, pages vues, inscriptions PDF, clics Gumroad et visites consultation.

Si un PR de CTA augmente les vues mais pas les inscriptions, ne duplique pas ce modèle partout. Vérifie d’abord si l’offre correspond au niveau du lecteur. Un guide débutant doit mener vers le PDF gratuit. Un article d’adoption en équipe doit rendre visibles le Setup Guide et la consultation.