self-review — examinez votre propre travail avant la PR

Examinez la diff complète de la branche, pas seulement le dernier commit. Ne donnez pas votre aval à votre propre travail simplement parce que vous l'avez écrit.

Annoncez au démarrage : « Utilisation de la skill self-review — examen de la diff de la branche par rapport à main. »

Étape 1 : Obtenir la diff

Une PR existe → gh pr view + gh pr diff.
Pas de PR → git diff $(git merge-base origin/main HEAD)...HEAD (plus --name-only pour la liste des fichiers).
Vous connaissez déjà la PR de cette session → ne la re-prouvez pas ; récupérez simplement la diff.

Étape 2 : Lire la totalité

Lisez la diff complète avec attention. Ne survolez pas. Relisez les hunks délicats jusqu'à comprendre pourquoi ils ont changé. Quand une modification semble subtile, risquée ou surprenante, ouvrez le fichier environnant et confirmez que le changement est sensé dans son contexte.

Recherchez activement :

les bugs ou erreurs logiques ; les cas limites manquants
les scopes manquants sur companyId pour les requêtes nouvelles/modifiées
la complexité inutile ; le code mort ; le churn accidentel
le code de debug restant, les logs, les TODOs, le code commenté, les fichiers égarés
les noms qui pourraient être plus clairs ; les patterns incohérents avec les voisins
les tests manquants ou faibles (ce test attraperait-il une annulation du correctif ?)
les changements risqués non évidents dans la diff (changements de signature, helpers partagés)
le titre/corps/scope de la PR ne correspondant pas au changement réel
les choses qui fonctionnent mais semblent fragiles ou difficiles à maintenir

Signalez le travail manquant, pas seulement les défauts dans ce qui est présent.

Étape 3 : Fraîcheur des docs

Pour chaque répertoire de package ou module que la diff touche :

Un AGENTS.md sibling existe-t-il ? La diff change-t-elle quelque chose qu'il référence (fonction, table, export, chemin d'import) ? → signalez la ligne exactement obsolète.
Nouveau package/module sans AGENTS.md ? → signalez-le (créez-le via /create-agents-md).
Nouveau pattern, convention ou piège méritant d'être conservé ? → signalez-le pour .ai/lessons.md. Spec implémentée ? → signalez la spec pour implemented/ selon .ai/specs/AGENTS.md.

Étape 4 : Résultat

Quatre sections, spécifiques, avec des références fichier:ligne — une trouvaille que vous ne pouvez pas lier à un fichier et une ligne est supprimée, pas rembourrée. Si vous hésitez sur le caractère réel d'un bug, incluez-le comme risque/question plutôt que de le laisser tomber.

À corriger obligatoirement
Risques / questions
Améliorations suggérées
Fraîcheur des docs

Terminez avec un TLDR compact listant chaque item à nouveau, groupé par section. Présentez les trouvailles à l'utilisateur — c'est lui qui décide quoi traiter ; ne faites pas de corrections automatiques.

Mode strict (thermo-nucléaire)

Exécutez seulement sur demande explicite (« thermo-nucléaire », « harsh », « deep code quality », « extremely strict »). Élève le standard de « correct et livrable » à « structure la plus simple et la plus maintenable possible ».

Recherchez les restructurations préservant le comportement qui font disparaître des branches entières, des helpers, des modes ou des couches. Préférez supprimer la complexité plutôt que de la réorganiser. Standards non négociables au-delà de l'examen de base :

Croissance de fichier — une PR qui pousse un fichier au-delà de ~1k lignes sans bonne raison est un signal d'alerte ; préférez extraire les modules d'abord.
Pas de croissance spaghetti — les nouveaux conditionnels ad-hoc et les cas spéciaux ponctuels boulonnés à des flux non liés appartiennent dans une abstraction dédiée.
Nettoyez la conception, ne vous contentez pas d'accepter du code fonctionnant — le même comportement avec une structure significativement plus propre mérite d'être poussé.
Direct plutôt que magique — signalez les thin wrappers, les abstractions identité et les helpers pass-through qui ajoutent de l'indirection sans clarté.
Propreté type/boundary — questionnez l'optionnalité inutile, any, unknown, le code chargé de casts et les fallbacks silencieux camouflant les invariants.
Couche canonique + réutilisation — la logique feature fuyant dans les chemins partagés, ou un helper sur mesure dupliquant un existant canonique, est un bloqueur.
Atomicité + orchestration — signalez les flux inutilement séquentiels et les mises à jour liées qui peuvent laisser l'état semi-appliqué.

Traitez chaque violation comme un bloqueur présumtif sauf justification claire. Soyez direct et exigeant sans être rude.