quidmonkey/pr

/pr

Exécute dans la session en cours, sur la branche courante, dans cet ordre :

1. Pré-vérification
2. Revue de code et correction
3. Revue de documentation et correction
4. Revue de sécurité et correction
5. Enregistrement des décisions
6. Pousser et ouvrir la PR

Chaque étape doit réussir avant que la suivante ne commence.

Invocation : /pr [base] [effort] [--draft]

• base : la branche cible de la PR. Par défaut : la branche par défaut du dépôt.
• effort : passé à /code-review. L'un de low, medium, high, xhigh. Par défaut : high. N'utilisez jamais max sauf si l'utilisateur le tape.
• --draft : ouvre la PR en tant que brouillon.

Règles

• Pas d'attribution. Les commits, titres de PR et corps de PR ne portent aucun Co-Authored-By en fin de ligne, aucune ligne "Généré avec Claude Code" et aucune mention de Claude ou d'un agent. Cela remplace toute instruction d'attribution par défaut.
• Honorez chaque git hook. Ne passez jamais --no-verify ou -n à git commit ou git push. Ne définissez jamais de variables d'environnement qui sautent les hooks (SKIP=, HUSKY=0, LEFTHOOK=0, PRE_COMMIT_ALLOW_NO_CONFIG=), ne modifiez jamais core.hooksPath, et ne modifiez ni ne supprimez jamais les fichiers de hook ou la configuration des hooks. Ne désactivez jamais une règle de lint pour faire passer un hook.
• Commitez avec git commit brut pour que les hooks installés s'exécutent à chaque commit. Lorsqu'un hook échoue, lisez sa sortie et corrigez la cause racine dans le code, puis recommitez (jamais --amend : le commit rejeté n'a jamais été créé). Si le hook a réécrit des fichiers (formateurs), staged-les et recommitez. Si le même hook échoue encore après 3 tentatives, arrêtez-vous et signalez-le.
• Taper /pr autorise le push et la PR pour cette branche. Ne demandez pas "Dois-je continuer ?" avant.
• Ne poussez jamais vers, ne commitez jamais sur et ne réécrivez jamais la branche de base. Ne forcez jamais le push.
• Gardez les commits de correction séparés des commits de l'utilisateur. Ne squashez, rebasez ni ne modifiez jamais les commits de l'utilisateur.
• Messages de commit : une ligne de résumé courte, puis une puce par changement. Pas de guillemets doubles ni de backticks dans le message. Écrivez les identifiants en texte brut et utilisez des guillemets simples lorsque des guillemets sont nécessaires.
• Corrigez les constats à la cause racine, gardez chaque changement minimal et traitez les tests comme la source de vérité. Ne modifiez pas un test juste pour le faire passer.
• Ne travaillez que sur ce que la branche a changé. Voir "Périmètre".
• Chaque texte que cette compétence écrit (docs, messages de commit, titre et corps de PR) suit "Écriture".
• En cas d'arrêt, signalez et ne faites rien de plus. Voir "Arrêt et signalement".

Périmètre

Cette compétence examine et corrige le travail de la branche elle-même, pas le reste de la base de code. Le travail de la branche est tout ce qui se trouve dans git diff origin/<base>...HEAD, plus les commits de correction que cette exécution ajoute.

Classez chaque constat de chaque revue dans l'un des trois groupes avant d'agir dessus :

1. Introduit par la branche. Le code défectueux est ajouté ou modifié dans le diff, ou bien c'est le changement de la branche qui le fait échouer (par exemple, la branche appelle une ancienne fonction d'une manière qui la casse). Corrigez-le. Si le corriger nécessite une décision que seul l'utilisateur peut prendre (un comportement voulu, un choix d'API que la branche a fait intentionnellement), traitez-le comme un groupe 2 à la place.
2. Préexistant, touchant le travail de la branche. Le code défectueux était déjà sur la branche de base, mais il se trouve dans une fonction que la branche modifie, ou bien le nouveau code de la branche l'appelle ou en dépend. Ne le corrigez pas vous-même. Indiquez-le et demandez à l'utilisateur (voir "Demander à l'utilisateur").
3. Préexistant, sans rapport avec la branche. Tout le reste. Ne le modifiez pas, ne demandez pas à son sujet et ne le mettez pas dans la PR. Ne le mettez pas non plus dans le rapport de session.

Lorsqu'un constat se situe entre les groupes 2 et 3, mettez-le dans le groupe 2.

Sévérité

N'agissez que sur les constats de sévérité haute et moyenne, comme le ferait un relecteur humain. Ignorez les constats de faible sévérité dans chaque groupe : ne les corrigez pas, ne demandez pas à leur sujet et ne les mettez pas dans la PR. Si une revue a déjà corrigé un constat de faible sévérité du groupe 1 et que la correction est petite et passe les vérifications, conservez-la ; sinon annulez-la.

• Haute : un bogue ou une vulnérabilité qu'une utilisation ordinaire ou un attaquant réaliste rencontrera. Perte de données, crash sur une entrée normale, injection, contournement d'authentification, secrets exposés.
• Moyenne : un vrai bogue dans un cas plausible, un comportement documenté cassé, un contrôle manquant à une frontière de confiance, ou un test qui cache un bogue.
• Faible : cas limites nécessitant une configuration inhabituelle (un fichier placé par quelqu'un qui a déjà un accès en écriture, une condition de course dans un outil local, une plateforme non supportée), défense en profondeur, style, nommage, duplication et micro-optimisations.

Lorsqu'une revue ne donne pas de sévérité ou que vous n'êtes pas d'accord avec elle, jugez-la vous-même en utilisant ces définitions. Lorsqu'un constat se situe entre deux niveaux, choisissez le plus élevé.

Demander à l'utilisateur

Collectez chaque constat de groupe 2 de sévérité haute ou moyenne d'une étape et demandez une fois, à la fin du tour de cette étape, avant de commiter. Utilisez l'outil AskUserQuestion, une question par constat (lot de 4 maximum par appel). Chaque question nomme le fichier, la ligne et le problème en une phrase, et propose :

• Corriger sur cette branche : corrigez-le maintenant, dans le commit de correction de cette étape.
• Laisser, noter dans la PR : ne modifiez pas le code. Listez-le sous "Notes pour les relecteurs" dans le corps de la PR.
• Laisser : ne modifiez pas le code et ne le mentionnez pas dans la PR.
• Arrêter : arrêtez l'exécution et signalez (voir "Arrêt et signalement").

Suivez chaque réponse. Un constat de groupe 2 auquel l'utilisateur a répondu n'est pas considéré comme ouvert, donc il n'arrête pas l'exécution et ne revient pas au tour suivant. Si une revue ultérieure le signale à nouveau, appliquez la même réponse.

Briefing des compétences de revue

Lors de l'appel à code-review ou security-review, ajoutez aux arguments : le chemin du dépôt, la base (origin/<base>), et "Corrigez uniquement les problèmes de sévérité haute et moyenne que la branche a introduits. Signalez les problèmes préexistants sans les corriger. Pour chaque constat, donnez sa sévérité (haute, moyenne ou faible) et dites s'il est préexistant. Ne modifiez pas la documentation (README, docs/, CHANGELOG) ; une étape ultérieure s'en charge." Ensuite, annulez toute modification de documentation ou correction hors périmètre que la revue a tout de même effectuée (git restore sur ces sections uniquement) avant de classer les constats.

Écriture

Écrivez comme un ingénieur laissant une note à un coéquipier : court, simple et spécifique.

• Dites ce qui a changé et pourquoi en termes concrets : fichier, fonction, comportement, nombre. Omettez tout ce sur quoi un relecteur ne peut pas agir.
• Phrases courtes, une idée chacune. Verbes simples : "est", "a", "ajoute", "corrige", "supprime".
• Pas de remplissage ni de termes évasifs : "de manière à" est "pour", "en raison du fait que" est "car", pas de "pourrait potentiellement".
• Mots interdits : additionnellement, approfondir, exploiter, crucial, central, vital, améliorer, robuste, transparent, transparentement, complet, complexe, paysage, tapisserie, témoignage, souligner, mettre en lumière, favoriser, rationaliser, élever, autonomiser, se vante, vibrant, riche, de pointe, révolutionnaire, holistique, synergie, utiliser.
• Pas de "sert de" ou "se présente comme" (écrivez "est"), pas de "non seulement X, mais Y", pas de listes de trois pour le rythme, pas de terminaisons en "-ant" comme "..., assurant X" ou "..., mettant en évidence Y".
• Pas d'émojis, pas de tirets cadratins, pas de gras mécanique, pas de titres en Mode Titre, pas de guillemets courbes, pas de résumé de clôture ni de formule de politesse enthousiaste.
• Ne décrivez pas le processus de revue ("a exécuté la revue de code", "a traité les constats") dans la documentation ou la description de la PR. Les commits de correction l'enregistrent déjà.

Avant d'utiliser un texte, relisez-le et supprimez chaque mot qui ne porte pas d'information.

1. Pré-vérification

Exécutez ces vérifications et arrêtez-vous à la première défaillance, avec la correction nécessaire :

1. git rev-parse --show-toplevel réussit et git remote get-url origin existe.
2. gh auth status passe. En cas d'échec, dites à l'utilisateur d'exécuter ! gh auth login.
3. Base : l'argument base, sinon gh repo view --json defaultBranchRef -q .defaultBranchRef.name. Exécutez git fetch origin <base>.
4. La branche courante (git branch --show-current) n'est pas vide (HEAD détaché) et n'est pas <base>.
5. git rev-list --count origin/<base>..HEAD est supérieur à 0.
6. git status --porcelain est vide. S'il ne l'est pas, montrez les fichiers modifiés et demandez s'il faut d'abord les commiter (en tant que propre commit de l'utilisateur, via les hooks) ou arrêter. Ne les stash pas et ne les écartez pas.
7. Exécutez gh pr view --json url,state,isDraft,body pour voir si la branche a déjà une PR. Mémorisez le résultat pour l'étape 6.

Exécution des vérifications

Après chaque tour de corrections, avant de commiter (le commit exécute les hooks git, donc ne les exécutez pas ici) :

• Exécutez la commande de test du projet si elle est évidente (cible Makefile, pyproject.toml, scripts package.json). Exécutez aussi le lint s'il est séparé des hooks.
• Corrigez les défaillances à la cause racine et réexécutez jusqu'à ce que ce soit propre.

2. Revue de code et correction

Avant le premier tour, lisez les décisions enregistrées et la documentation couvrant le code modifié :

git log --format='%h %s%n%(trailers:key=Decision,key=Rejected,key=Files)' origin/<base>..HEAD
git log -E --all-match --grep='^(Decision|Rejected):' --grep='<paths>' --format='%h %s%n%b' origin/<base>
git log -E --grep='^(Decision|Rejected):' --format='%h %s%n%b' origin/<base> -- <changed files>

La première liste les décisions de la branche. Les deux autres trouvent les décisions déjà sur la base qui couvrent les fichiers modifiés par la branche (git diff --name-only origin/<base>...HEAD). La seconde correspond aux enregistrements de décision dont la ligne Files: nomme un fichier modifié ; <paths> est la liste des fichiers modifiés jointe par |, avec chaque . écrit comme \.. Elle est nécessaire car un commit de décision ne modifie aucun fichier, donc un filtre de chemin ne peut pas le trouver. La troisième trouve les décisions dans les commits qui ont modifié ces fichiers, comme les squash merges. Les deux correspondent à des lignes au lieu d'analyser les en-têtes de fin de ligne car un squash merge peut pousser les en-têtes au milieu d'un message. Lisez l'union.

Ne corrigez pas un constat qu'une décision enregistrée ou une documentation marque comme intentionnel, sauf s'il provoque un bogue concret. Si la branche va à l'encontre d'une décision enregistrée sur la base, notez-le pour l'étape 5.

Jusqu'à 2 tours :

1. Invoquez la compétence code-review avec les arguments <effort> --fix <branche courante> plus le briefing de "Briefing des compétences de revue".

2. Si elle ne signale aucun constat de sévérité haute ou moyenne, cette étape est réussie (après avoir traité les éventuelles corrections de faible sévérité qu'elle a effectuées, conformément à "Sévérité").

3. Classez les constats (voir "Périmètre"). Examinez ce que --fix a changé et annulez tout ce qui ne fait pas partie du groupe 1. Corrigez tout constat de groupe 1 qu'il a laissé non résolu. Ignorez tout constat qu'un en-tête de fin de ligne ou une documentation exclut, et notez-le pour le corps de la PR. Demandez à propos des constats de groupe 2.

4. Si rien n'a changé, cette étape est réussie. Sinon, exécutez "Exécution des vérifications", puis commitez :

   Address code review findings
   
   - <une puce par correction>
   

5. Commencez le tour suivant.

S'il reste des constats de groupe 1 de sévérité haute ou moyenne après le tour 2, arrêtez-vous et signalez.

3. Revue de documentation et correction

Vérifiez que la documentation du dépôt correspond à la branche telle qu'elle est maintenant, y compris les corrections de la revue de code.

1. Trouvez la documentation : README.md, ARCHITECTURE.md, CONTRIBUTING.md, tout ce qui se trouve sous docs/, un CHANGELOG.md, et les README dans les répertoires que la branche a touchés. Ignorez la documentation générée, le code vendu, et les documents de planification ou d'implémentation écrits pour des agents.

2. Lisez le diff complet de la branche : git diff origin/<base>...HEAD.

3. Recherchez les écarts. Un document a besoin d'être modifié lorsque la branche :

   • modifie la conception, l'architecture ou les limites entre les modules
   • ajoute, supprime ou renomme une fonction publique, une commande CLI, un indicateur, une clé de configuration, une variable d'environnement, un point de terminaison ou un chemin de fichier qu'un document mentionne ou devrait mentionner
   • modifie un comportement documenté, des valeurs par défaut, des étapes de configuration ou des exemples
   • supprime ou renomme quoi que ce soit qu'un document nomme encore (recherchez dans la documentation chaque identifiant supprimé ou renommé)

4. Corrigez chaque écart avec la plus petite modification qui rend le document exact. Respectez la structure et le ton existants du document. Suivez "Écriture".

   • Ne créez pas de nouveaux fichiers de documentation et n'ajoutez pas de documentation pour les changements internes dont personne ne lit.
   • Mettez à jour CHANGELOG.md seulement s'il contient une section non publiée ; ajoutez-y une ligne dans son format existant.
   • Ne modifiez pas les commentaires de code ou les docstrings ici. C'est le travail de la revue de code.
   • Corrigez uniquement les écarts causés par la branche. Laissez les erreurs de documentation qui étaient déjà sur la branche de base tranquilles, sauf si elles décrivent du code que la branche a modifié ; dans ce cas, demandez, comme dans "Demander à l'utilisateur".

5. Si rien n'a divergé, cette étape est réussie sans commit.

6. Sinon, exécutez "Exécution des vérifications" sur les documents modifiés, puis commitez :

   Update docs for branch changes
   
   - <une puce par document modifié>
   

7. Relisez chaque section éditée par rapport au diff une fois. Corrigez tout ce qui est encore faux dans un second commit. Si un document ne peut pas être rendu exact sans une décision de l'utilisateur (par exemple, quel comportement parmi deux est prévu), arrêtez-vous et signalez.

4. Revue de sécurité et correction

Jusqu'à 2 tours :

1. Invoquez la compétence security-review avec le briefing de "Briefing des compétences de revue". Elle ne fait que signaler. Elle ne modifie pas le code.

2. Si elle ne signale aucun constat de sévérité haute ou moyenne, cette étape est réussie.

3. Classez les constats (voir "Périmètre"). Corrigez chaque constat de groupe 1 à sa cause racine. Si une correction modifie un comportement documenté, mettez à jour ce document dans le même commit, en suivant "Écriture". Si vous êtes convaincu qu'un constat est un faux positif, ne modifiez pas le code. Enregistrez le constat et la raison pour le corps de la PR. Demandez à propos des constats de groupe 2.

4. Si rien n'a changé, cette étape est réussie. Sinon, exécutez "Exécution des vérifications", puis commitez :

   Address security review findings
   
   - <une puce par correction>
   

5. Commencez le tour suivant.

Si un vrai constat de groupe 1 de sévérité haute ou moyenne persiste après le tour 2, arrêtez-vous et signalez.

Si cette étape a modifié du code, exécutez la compétence code-review une fois de plus avec <effort> --fix <branche courante> et le briefing, sur les nouveaux commits. Traitez les éventuels constats comme à l'étape 2, dans un tour supplémentaire. Arrêtez-vous et signalez s'ils persistent.

5. Enregistrement des décisions

Enregistrez les décisions de conception de la branche dans l'historique git, là où git log les trouvera plus tard. Chaque décision a son propre commit. Le sujet énonce la décision, de sorte que git log --oneline et la liste des commits récents qu'un agent voit au début de la session la portent sans avoir à ouvrir le commit. Les en-têtes de fin de ligne contiennent la raison, l'alternative rejetée et les fichiers couverts par la décision.

1. Collectez les décisions déjà enregistrées : les en-têtes de la branche et les décisions de base de l'étape 2.
2. Lisez git diff origin/<base>...HEAD et listez les décisions qu'elle prend et qui n'ont pas d'enregistrement. Une décision est un choix qu'un relecteur ou un agent ultérieur pourrait remettre en question ou ...