next-friday/next-friday-skills

Rebut

Trier les commentaires de revue de code IA sur une pull request et y répondre avec rigueur. Vérifier chaque constatation par rapport au code réel, corriger les vrais bugs, réfuter les faux positifs avec des preuves, et répondre dans chaque fil, marqué comme tri automatisé. L'humain clique toujours sur Résoudre.

C'est le pendant de la revue humaine, pas une copie. Les réviseurs IA comme CodeRabbit ou Gemini Code Assist publient beaucoup plus de constatations, mélangent de vrais bugs avec des faux positifs et sont aveugles au dépôt. Ils ne connaissent pas la configuration locale, les conventions ou les outils de votre dépôt, donc ils signalent comme des bugs des motifs corrects pour votre dépôt, avec confiance. La sévérité d'un bot n'est pas son exactitude : un CRITICAL peut être un faux positif, et un nit peut cacher un vrai bug.

Pourquoi les réviseurs IA ont leur propre tri

• Aveugle au dépôt. Le bot ne charge pas la configuration locale de votre dépôt — un config de linter, de formateur ou de vérificateur de type, selon votre stack — ni vos règles maison. Il signalera un motif que vos PROPRES outils EXIGENT. Exemple réel (dépôt ESLint) : un réviseur a marqué meta.defaultOptions comme CRITICAL « erroné », mais la règle lint require-meta-default-options du dépôt l'impose. Appliquer la suggestion aurait cassé cette build. Appliquer à l'aveugle est aussi dangereux que rejeter à l'aveugle.
• Taux de faux positifs élevé. De nombreuses constatations sont spéculatives ou uniquement stylistiques. Certaines sont de vrais bugs que l'humain a manqués. Le travail est de les séparer avec des preuves, pas des impressions.
• Erreur avec confiance. Les étiquettes de sévérité sont heuristiques. Vérifiez un CRITICAL comme un nit.

Quand le réviseur est un humain

Le pipeline est le même pour tout réviseur, bot ou humain : vérifier par rapport au code actuel → corriger ou répondre avec des preuves → répondre dans le fil sous la ligne d'attribution → prouver la couverture. Un contributeur ou réviseur humain fait aussi partie de la boucle de tri : quand une personne demande une modification, corrigez-la et répondez, avec la même rigueur et la même piste d'audit que la porte humaine lit lors de la fusion. Seul le ton change, car un humain connaît le dépôt, publie moins de constatations et de meilleure qualité, et a un visage qu'une réfutation brutale peut menacer. Donc quand le réviseur est humain :

• Abandonnez le cadrage de bot. Ne traitez pas sa revue comme un bruit aveugle au dépôt et à haut taux de faux positifs ; ce n'est généralement pas le cas.
• Collaborez, ne réfutez pas sèchement. Vérifiez, puis corrigez ce qui est juste et repoussez ce qui est faux avec un raisonnement technique. Jamais d'accord de façade, jamais un « faux positif » sec adressé à un collègue ; énoncez la raison dans un ton non sec et techniquement raisonné.
• Publiez la réponse vous-même, avec la ligne d'attribution. Vous triez les fils humains de manière autonome, comme les fils de bot : publiez via le compte de tri, ouvert avec la ligne d'attribution afin que le lecteur voie un tri automatisé et non la propre revue par les pairs du mainteneur. La ligne qui déconnecte le commentaire du mainteneur est exactement ce qui rend la publication automatique dans un fil humain sûre. La couverture compte aussi les fils humains (Étape 5.5), donc une constatation humaine laissée sans réponse maintient le tour ouvert.

Les étapes ci-dessous s'appliquent aux bots comme aux humains ; le marqueur d'attribution et la réponse automatique sont utilisés pour les deux. La seule adaptation par réviseur est le ton ci-dessus.

Pré-vol

"${CLAUDE_SKILL_DIR}/scripts/preflight.sh"

preflight.sh confirme que gh est authentifié et que le dépôt a un remote GitHub. En cas de prérequis manquant, il imprime la correction sur stderr et sort avec un code non nul ; relayez cela et arrêtez-vous. Identifiez la PR : l'argument [pr-number], sinon la PR pour la branche actuelle (gh pr view --json number).

Étape 1 : Rassembler chaque constatation

"${CLAUDE_SKILL_DIR}/scripts/gather-review.sh" <pr>

gather-review.sh imprime un bloc REVIEWS contenant l'auteur, l'état et le corps de chaque revue, et un bloc COMMENTS contenant l'auteur, path:line, id=<id> et le corps de chaque commentaire en ligne, via le --jq intégré de gh, donc rien n'est inventé ou omis. Listez chaque constatation avec son auteur, path:line, id du commentaire nécessaire pour répondre, et son corps. Incluez les résumés de revue de haut niveau et chaque commentaire en ligne. N'en manquez aucun. Marquez l'auteur de chaque fil comme un bot, reconnaissable par le suffixe de connexion [bot] montré dans la sortie rassemblée, ou un humain : les deux suivent les étapes 4-6, et un fil humain prend en plus l'ajustement de ton dans « Quand le réviseur est un humain » ci-dessus.

Laissez le tour se stabiliser avant de trier. Les réviseurs déclenchent de manière asynchrone : un second bot atterrit souvent sa vague minutes après le premier, donc une collecte instantanée à la mise à jour de la PR ne capture que les réviseurs qui ont publié jusqu'à présent. Après la première collecte, laissez le tour se stabiliser avec gh pr checks <pr> --watch || true : il bloque jusqu'à ce que les checks de la PR se terminent et se comporte de la même manière en interactif et en non interactif, et c'est la fenêtre dans laquelle les réviseurs asynchrones publient (le || true empêche la sortie non nulle d'une PR sans check d'être lue comme un échec). Ensuite, relancez gather-review.sh ; si de nouvelles constatations apparaissent, le tour arrive encore, donc surveillez et recollectez à nouveau. (Si la PR n'a pas de checks, --watch revient immédiatement ; et un bot de revue uniquement peut ne pas enregistrer de check run du tout, donc dans les deux cas, faites une brève pause et recollectez indépendamment de l'état des checks. L'automatisation entre tours ci-dessous est le véritable filet de sécurité pour un réviseur qui publie après cette stabilisation.) Commencez le tri seulement une fois qu'une re-collecte n'ajoute rien de nouveau. Cela traite un tour multi-réviseur comme UN seul passage de tri au lieu de commencer sur les constatations du réviseur A pendant que le réviseur B est encore en train de publier, ce qui force un second passage complet. La limite empêche d'attendre indéfiniment ; l'automatisation entre tours dans la dernière section est la réponse durable pour les réviseurs qui publient après la sortie de la compétence.

Étape 2 : Vérifier chaque constatation (le cœur de cette compétence)

Pour chaque constatation, répondez à deux questions par rapport au code actuel, pas au cadrage du bot :

1. Le problème se reproduit-il ? Reproduisez-le comme ${CLAUDE_SKILL_DIR}/references/debugging.md le décrit : ouvrez le fichier à la ligne, tracez la logique, construisez l'entrée que le bot décrit, et vérifiez le comportement réel. S'il s'agit d'un bug, il doit être démontrable.
2. La suggestion est-elle correcte pour CE dépôt ? Exécutez la porte pertinente que le dépôt définit (son linter, vérificateur de type ou tests, selon ce qui existe). Vérifiez la convention documentée. Une correction qui passe le bot mais échoue une porte du dépôt est erronée ici.

Modifiez une chose à la fois et re-vérifiez. Ne faites pas de lot.

Étape 3 : Classifier

Verdict	Signification	Action
FIX	Réel, se reproduit	Corrigez (Étape 4)
REFUTE	Faux positif pour ce dépôt	Répondez avec la preuve qui le réfute
INTENTIONAL	Choix délibéré que le bot ne peut pas voir	Répondez en expliquant l'intention
MINOR	Cosmétique, non bloquant	Notez-le ; corrigez ou ignorez selon la barre du mainteneur

Étape 4 : Corriger les valides

• Changement minimal limité à la constatation. Pour un bug, écrivez d'abord le test échouant, regardez-le échouer, corrigez, regardez-le passer.
• Exécutez toutes les portes du dépôt. Une porte rouge bloque la correction.
• Livrez tout le tour dans UN commit et poussez, jamais un par constatation. Vérifiez et corrigez chaque constatation une par une comme à l'Étape 2, mais préparez toutes les corrections et committez-les ensemble, puis poussez une fois, sous le compte du mainteneur, le même compte qui possède la PR et publie les réponses. Un push par constatation transforme un cycle de revue en plusieurs : chaque push relance le CI et re-déclenche chaque bot, donc cinq corrections deviennent cinq exécutions CI et cinq vagues de re-revue. Un commit par tour est une exécution CI et une vague de re-revue. Capturez ce SHA unique ; chaque réponse de correction à l'Étape 5 le cite. Si ce push est rejeté comme non fast-forward parce que la branche distante a évolué (un bump d'un bot de release ou un commit de fusion « Update branch » de la PR ajouté pendant le tour), récupérez, ne vous arrêtez pas : git fetch puis git rebase origin/<branch>, relancez les portes, et poussez à nouveau, jamais --force ; le rebase réécrit le commit, donc re-capturez le nouveau SHA et citez celui-ci dans les réponses de l'Étape 5, pas l'ancien SHA pré-rebase.

Étape 5 : Répondre dans chaque fil

Répondez au commentaire original pour qu'il soit en fil de discussion, jamais un commentaire de PR de haut niveau.

Ouvrez chaque réponse avec la même ligne d'attribution, sur chaque fil, sans exception. Vous publiez via le jeton gh du mainteneur, donc GitHub montre son avatar et un lecteur suppose qu'il l'a écrit. La ligne d'attribution nomme l'agent et déconnecte le commentaire du mainteneur, de sorte que le tri automatisé ne soit jamais confondu avec la propre revue du mainteneur :

🤖 Tri automatisé par Claude Code, publié via le compte du mainteneur, pas une revue personnelle.

Quand le dépôt a un bot ou un compte machine, publiez sous cette identité à la place pour que l'auteur lui-même soit non personnel ; la ligne d'attribution est le recours pour un jeton personnel.

Écrivez le corps dans un fichier. La ligne d'attribution rend le corps multi-ligne, ce qui casse le quoting en ligne -f body="...". Une réponse de correction :

> 🤖 Tri automatisé par Claude Code, publié via le compte du mainteneur, pas une revue personnelle.

**rebut** corrigé dans <sha> : <une ligne sur le changement>.

Une réfutation énonce la preuve :

> 🤖 Tri automatisé par Claude Code, publié via le compte du mainteneur, pas une revue personnelle.

**rebut** ne change pas ceci : <raison concrète, par ex. une règle lint du dépôt l'exige ; la porte passe>.

Publiez chaque réponse avec post-reply.sh, une constatation à la fois :

"${CLAUDE_SKILL_DIR}/scripts/post-reply.sh" <pr> <comment_id> /tmp/reply.md

post-reply.sh espace la publication sous la limite de débit secondaire de GitHub, puis confirme qu'elle a persisté en lisant l'ID de réponse créé à partir de la réponse de l'API, en réessayant avec backoff quand une publication est trottlée. Il imprime l'ID de réponse et sort 0 en cas de succès ; la sortie 1 signifie que la réponse n'a pas été publiée (ne passez pas à autre chose, corrigez et relancez), la sortie 2 est un mauvais argument. Ne faites pas vous-même l'appel brut gh api .../replies dans une boucle : les publications dos à dos déclenchent la limite de débit et disparaissent, exactement l'échec que ce script existe pour éviter. Une constatation, un appel post-reply.sh, en séquence.

Réponse seulement, jamais Résoudre. Publiez les réponses via l'API ; ne cliquez jamais sur « Résoudre la conversation ». Le bouton vert Résoudre est celui du réviseur humain, et c'est ainsi qu'il vérifie le travail de cette compétence : il lit chaque fil, confirme qu'une réponse est présente, confirme que le commentaire de résumé existe, et seulement alors résout. Si la compétence résout, l'humain ne peut pas dire si lui ou l'agent a fermé le fil, exactement la confusion qui l'amène à revérifier ou relancer le tri. L'ensemble de la sortie de cette compétence est les réponses plus un commentaire de résumé ; le bouton Résoudre reste le leur.

Ne laissez aucun fil vide. Chaque constatation rassemblée à l'Étape 1 reçoit une réponse : un FIX avec son SHA, ou un REFUTE / INTENTIONAL / MINOR avec sa raison. Une constatation sans réponse, d'un bot ou d'un humain, est impossible à distinguer d'un travail non trié : un réviseur ne peut pas dire si la compétence a été exécutée, donc il la relance et le tour boucle en boucle. Le silence n'est jamais un verdict. Être en désaccord avec une constatation nécessite toujours une raison énoncée, jamais un fil vide.

Étape 5.5 : Affirmer la couverture, revérifier le CI, puis attraper le tour que votre correction-push a provoqué

Avant de résumer :

• Affirmez la couverture (toujours). Après avoir publié, re-interrogez la PR et confirmez que chaque constatation, bot ou humain, a reçu une réponse du compte de tri :

  "${CLAUDE_SKILL_DIR}/scripts/verify-coverage.sh" <pr>
  

  Il imprime une ligne par constatation (answered / MISSING) puis answered N / M. La sortie 0 signifie que chaque constatation a une réponse (le tour est couvert) ; la sortie 1 liste chaque constatation MISSING, donc republiez-les avec post-reply.sh et relancez jusqu'à ce qu'il rapporte answered N / N ; la sortie 2 est une erreur de lecture/d'argument, ce qui n'est pas une couverture, donc affichez-la. Cela s'exécute quels que soient les verdicts, y compris un tour tout-REFUTE où aucune correction n'a été poussée : une réponse de réfutation manquée est aussi invisible qu'une réponse de correction manquée. Ne passez jamais à l'Étape 6 tant qu'une constatation est MISSING.

• Revérifiez le CI. Quand les checks sont encore en cours, attendez avec gh pr checks <pr> --watch, puis classez avec "${CLAUDE_SKILL_DIR}/scripts/ci-status.sh" <pr> : ci: green (sortie 0) est clair ; ci: failing (sortie 1) bloque, donc déboguez ; ci: none (sortie 3) signifie pas de CI configuré, ce qui n'est PAS un échec, donc notez-le et passez à autre chose, exactement comme la compétence implement le gère ; ci: pending (sortie 4) signifie relancez --watch, puis re-sondez ; une erreur de lecture (sortie 2) n'est pas « vert », donc affichez-la. Confirmez vert de vos propres yeux ; ne l'affirmez jamais sans la preuve du script. Si l'Étape 4 n'a rien changé parce que chaque constatation était REFUTE ou INTENTIONAL, il n'y a pas de nouveau push, donc cette revérification du CI et la capture du tour ci-dessous n'ont rien à re-déclencher ; l'affirmation de couverture ci-dessus s'exécute toujours.

• Attrapez le nouveau tour. Le push de correction

…

[tronqué pour la traduction]