review-contriblisted

Contrôler, auditer, RESTITUER et intégrer proprement le commit/la branche/la PR d'un collaborateur (souvent depuis un fork) avant merge dans main. Utilise-le quand le mainteneur dit « un collaborateur a poussé un commit », « regarde la branche/PR de X », « audite/teste cette contribution », « passe-moi en revue les commits de X », « comment adopter ce commit », ou veut un workflow de revue rapide — et quand une revue s'appuie sur une RÈGLE EXTÉRIEURE au dépôt (taux fiscal, plafond légal, barème, seuil réglementaire, date d'effet, limite d'une API tierce) qu'il faut sourcer avant de la reprocher à quelqu'un : « vérifie ce qu'on lui dit », « c'est sourcé ? », « d'où sort ce chiffre » — et AUSSI quand il demande à VOIR la contribution : « fais-moi un HTML de ses commits », « une synthèse avec des captures », « montre-moi ce que ça donne », « simule ses commits dans le navigateur », « qu'est-ce que ça apporte vraiment » — et quand il faut RENDRE COMPTE au contributeur : « écris-lui le retour », « fais un rapport
lbachelotcapitalb/leo-bachelot-ia-skills · ★ 3 · Code & Development · score 76

Install: claude install-skill lbachelotcapitalb/leo-bachelot-ia-skills

# review-contrib — adopter vite & sûrement les contributions d'un collaborateur ## Principe immuable **On ne teste / n'ajuste JAMAIS sur `main`.** Pars du principe que `main` = production (déploiement automatique — **vérifier par quel remote** : `git remote -v`, ce n'est pas toujours l'hébergeur annoncé dans la doc, et un même repo peut déployer par un remote dédié). Toute revue se fait sur une **branche `review/*` dans un worktree séparé** (un 2ᵉ dossier ; le checkout principal reste sur `main`, intact). Le merge dans `main` n'arrive **qu'une fois tout vert et validé par le mainteneur**. Pas de « pousser sur main puis nettoyer » — ça publierait du non-validé. ## Le cycle de vie d'une contribution `fork/branche du collab` → fetch → **borner à SES commits (§1bis)** → **audit conflits, y compris contre le travail non mergé du mainteneur (§2, §2bis)** → worktree de revue → **`npm run audit`** → **audit de code (sous-agent)** → **🔒 fact-check des règles extérieures (§5ter)** → **banc + HTML de revue (§6)** → **test manuel** puis, tant que ce n'est pas mergeable : **↻ boucle de correction (§9)** — message au contributeur → il corrige → re-fetch → **re-mesure** → jusqu'au feu vert (§9.4) et seulement là : ajustements sur `review/*` → **merge dans `main`** (= go prod). Trois erreurs de cadrage tuent la revue avant qu'elle commence : **auditer du code qui n'est pas de lui** (§1bis) ; **ne comparer qu'à `main`** en ignorant ce que le mainteneur a en attente (§2bis) — ce qui fait