Examiner un changement de code avec un autre modèle en 3 rounds maximum : un relecteur lit le changement, et un briseur tente de le briser avec des tests. Gardez chaque correction la plus petite possible qui résout sa constatation, et contre-argumentez avec des preuves lorsqu'une constatation est erronée.
1. Briefing du relecteur et du briseur
Le relecteur et le briseur sont le modèle le plus récent, dans orchestrator_capabilities, de la famille nommée par l'utilisateur (sol, opus, …), avec l'effort qu'il a nommé ; ne définissez aucune autre option de modèle. Un fournisseur seul (gpt, claude) ne nomme pas de famille. Si la famille ou l'effort est manquant, demandez-le et ne faites rien d'autre jusqu'à ce qu'il réponde.
Épinglez la base : celle passée par l'appelant, sinon git merge-base HEAD <remote>/<default-branch>, où le remote est celui dans lequel le changement fusionne (upstream sur un fork), ou HEAD lorsque le changement est uniquement non commité. Exécutez les vérifications qui couvrent le changement, via la compétence de vérification du dépôt si elle existe (.agents/skills/verify/), et corrigez tout échec avant le round 1. Enregistrez la révision sur laquelle elles ont été exécutées, modifications non commitées incluses.
Commencez chaque round comme un delegate_task frais. Les contre-argumentations et les rounds ultérieurs vont dans le nouveau briefing, jamais dans un message de suivi à un relecteur terminé. Un délai d'attente ou une erreur n'est pas une approbation : redémarrez l'agent qui a échoué, une fois.
Lorsque le diff ne modifie que des commentaires, de la documentation ou du formatage, n'exécutez aucune boucle et dites-le dans le message final. Au round 1, démarrez le relecteur et le briseur en parallèle, le briseur avec isolation: "worktree". Sautez le briseur lorsque le diff ne modifie aucun code qui s'exécute. Dans une exécution légère (le niveau see-it-through est passé), ne démarrez pas de briseur au round 1 ; une fois que le relecteur a répondu, démarrez-en un ciblé sur les conditions de sa ligne Non vérifié qu'un test pourrait trancher, le cas échéant.
Les deux briefings commencent par cet en-tête :
Repo : <chemin abs> Base : <sha> Hors de portée : <portée>
Normes : <les fichiers de règles du dépôt, tels que AGENTS.md ou CONTRIBUTING.md ; ou aucun>
Setup : <ce que chaque shell doit exécuter en premier, comme un script de chaîne d'outils épinglée, et ce dont une nouvelle extraction a besoin, comme une installation ; ou aucun>
Vérifications : <résultats> En cours : <vérifications toujours en cours ; ou aucun>
Demande : <la demande ou le briefing de l'utilisateur, mot pour mot, ou son chemin absolu>
Approche : <l'approche approuvée, ou son chemin absolu ; ou aucun>. Ses affirmations sont celles de l'auteur : vérifiez celles sur lesquelles le diff s'appuie.
Acceptation : <le commit ou le patch contenant les vérifications d'acceptation écrites avant le changement ; ou aucun>
Diff : git diff <base> ; lisez également les fichiers non suivis à partir de git status --short.
Conditions : avant de lire le diff, écrivez les conditions d'acceptation à partir de la Demande : ce que l'utilisateur devrait voir ou recevoir en cas de succès, d'échec, d'annulation et de nouvelle tentative ; après un échec partiel (ce qui reste en mémoire, sur disque et à l'écran) ; lors d'une répétition, ou d'une tentative antérieure se terminant après une plus récente ; lorsqu'une attente se termine après que l'utilisateur est passé à autre chose ; sur chaque surface qui montre le résultat, données cachées incluses ; et un moyen de sortir de chaque état que le changement peut laisser. N'en écrivez un que là où le code modifié atteint ce cas : sur le chemin prévu, à travers chaque autre appelant du code modifié, et à travers chaque autre rédacteur d'état que le changement fait désormais confiance (recherchez les deux).
Briefing du relecteur, après l'en-tête :
Relecture uniquement : lisez et tracez. Ne modifiez pas, ne commitez pas, ne poussez pas, ne commentez pas, ne démarrez pas de sous-agents, et n'écrivez ou n'exécutez pas de tests ou de builds.
Écrivez les conditions d'acceptation comme le dit Conditions, puis comment vous feriez le changement dans le cadre de l'Approche. Commencez votre réponse finale par les deux, mot pour mot ; la ligne VERDICT les suit.
Trouvez des problèmes avec le changement, en traçant chaque condition à travers le code jusqu'à ce que l'utilisateur voit ou reçoive. Votre approche n'est une constatation que là où elle rencontre une condition que le diff échoue, ou rencontre chaque condition avec moins de code.
Pour chaque bogue que vous trouvez, nommez sa classe et recherchez la même erreur dans le reste du diff et ses appelants, y compris un cas frère que le changement traite différemment ; signalez une constatation par classe, en listant chaque emplacement.
Vérifiez le changement par rapport aux fichiers Normes ; étiquetez ces constatations [normes] et ignorez ce que les linters et les vérifications de type imposent.
Signalez comme nits le code ou les gardes dont aucune condition n'a besoin, le nouveau code que le dépôt ou la plateforme fournit déjà, et le code qui s'écarte des Normes ou des conventions du code environnant ; pas le style que vous préférez simplement.
Vérifiez si le changement introduit une propriété concurrente de l'état, une décision prise à deux endroits, une obligation dont les appelants doivent se souvenir, ou une limite que les appelants peuvent contourner ; étiquetez-les [structure], nommez le code et sa conséquence, et notez-les selon les définitions ci-dessous. Une conception différente sans une telle conséquence est un nit ; une refonte plus importante n'est une constatation qu'avec la raison pour laquelle la plus petite correction ne peut pas la réparer.
Une modification d'une vérification dans Acceptation qui l'empêche de prouver ce qu'elle promet est un devrait.
bloquant = le cas prévu est erroné. devrait = un problème que ce changement provoque et qu'une action ou une entrée prise en charge peut atteindre : une action utilisateur, des fichiers sur disque, un échec d'E/S, des fichiers que l'utilisateur a créés, démontrés en l'exécutant ou tracés à travers le code, y compris via des appelants que le diff n'a pas touchés. Un test que le changement ajoute et qui peut réussir sans le comportement qu'il prouve est un devrait.
nit = style, petite perf, polissage. préexistant = le même échec se produit sur la base, démontré par un test ou une trace, et le changement ne le rend ni plus facile à atteindre ni ne contredit une affirmation qu'il fait.
VERDICT : APPROUVER ou CHANGEMENTS, puis une ligne par constatation :
S1 [bloquant|devrait|nit|préexistant] <fichier>:<ligne> <affirmation>. Correction : <la plus petite correction>
puis Vérifié : une ligne par condition : <fichier>:<ligne> et ce que cette ligne établit.
puis Non vérifié : ce que vous n'avez pas pu confirmer, et pourquoi ; ou aucun.
Briefing du briseur, après l'en-tête :
Brisez ce changement. Ne commitez pas, ne poussez pas, ne commentez pas, et ne démarrez pas de sous-agents.
Travaillez uniquement dans votre propre checkout, le répertoire de travail dans lequel vous avez commencé, qui est une copie de HEAD de <repo>. Apportez d'abord la partie non commitée du changement : git -C <repo> diff HEAD | git apply, puis copiez les fichiers non suivis listés par git -C <repo> status --short. Ne modifiez jamais les fichiers dans <repo> ou la config de l'utilisateur, et n'exécutez rien qui pousse, publie ou notifie ; les caches du gestionnaire de paquets sont acceptables. Ignorez les exécutions E2E et tout ce qui est listé dans En cours ; compilez uniquement ce dont vos tests ont besoin.
Écrivez les conditions d'acceptation comme le dit Conditions. Pour chacune, écrivez et exécutez le plus petit test qui échouerait si la condition se brisait, en affirmant ce que l'utilisateur voit ou reçoit.
Pour chaque test en dessous d'E2E que le changement ajoute comme preuve, annulez la garde qu'il devrait attraper, ou brisez sa précondition, exécutez-le, puis restaurez le code.
COULDN'T TEST est uniquement pour une condition que ce niveau ne peut pas atteindre, comme celle qui nécessite E2E. Une file d'attente lente ou votre propre configuration cassée n'en est pas une : regroupez vos tests en un seul job, attendez-le sans annuler, et corrigez votre configuration.
Avant de répondre, écrivez un patch de vos tests réussis qui couvrent une condition qu'aucun test existant ne couvre vers <chemin de conservation>, et supprimez tout le reste que vous avez ajouté.
Répondez, une ligne par condition : B1 TENU <condition> — <commande> ; B2 BRISÉ <condition> — <commande> et la sortie d'échec ; ou B3 COULDN'T TEST <condition> — pourquoi. Ensuite, une ligne par test de preuve : P1 ÉCHOUE <test> avec <garde> annulée ; ou P2 RÉUSSIT ENCORE <test> avec <garde> annulée. Ensuite : Conservé : <chemin de conservation> et la condition que chaque test couvre ; ou aucun.
Choisissez <chemin de conservation> : un chemin absolu en dehors des deux checkouts.
2. Répondre aux constatations
Notez vous-même chaque constatation selon les définitions du briefing du relecteur, quelle que soit l'étiquette avec laquelle elle est venue. Traitez chaque ligne BRISÉ et RÉUSSIT ENCORE comme une constatation.
- D'accord : reproduisez-la d'abord, avec un test qui échoue sur le code actuel lorsqu'un test significatif est pratique, sinon une reproduction directe (commande et sortie) avec ses limites notées ; vérifiez une affirmation sur des faits, comme ce que CI exécute ou ce que la base fait, par rapport à sa source. Ensuite, recherchez dans les cas frères du code modifié et ses appelants plus de la classe de la constatation, et appliquez la plus petite correction à chaque instance que le changement a introduite ou exposée ; listez les préexistantes non liées comme des suivis. Montrez que le test réussit (pour une constatation RÉUSSIT ENCORE, que le test corrigé échoue avec la garde annulée), et conservez le test. Préférez supprimer ou réduire le code plutôt qu'un nouveau verrou, cache, helper ou option.
- En désaccord : dites pourquoi, avec des preuves (une sortie de test ou de commande). Une raison lue uniquement dans le code, comme « ça ne peut pas arriver », laisse la constatation contestée, pas abandonnée ou déclassée.
- Nit : sur du code que le diff ajoute, modifie ou déplace, appliquez-le lorsque sa correction supprime du code, réutilise ce que le dépôt ou la plateforme fournit, ou aligne le code avec les Normes ou le code environnant, en gardant chaque vérification réussie et sans échanger la clarté contre la longueur. Refusez en une ligne un nit qui ajoute un chemin, un cas, une option ou une couche de compatibilité, un nit dont la correction modifie ce que l'utilisateur voit ou reçoit, et un qui n'est que du goût.
- Préexistant ou hors de portée : refusez en une ligne.
Commitez chaque test dans le patch du briseur, ou nommez le test existant qui couvre sa condition.
N'acceptez jamais juste pour terminer la boucle. Ré-exécutez les vérifications et git diff --shortstat <base> ; supprimez ce que la relecture a ajouté en dehors des tests dont aucune constatation acceptée n'a besoin, en gardant la plus petite correction correcte même lorsqu'elle augmente le code.
3. Round suivant
N'en démarrez un que lorsqu'un bloquant ou un devrait est ouvert, ou que du code de comportement a changé. Envoyez l'en-tête avec sa ligne Conditions remplacée par les conditions du relecteur du round 1, le briefing du relecteur sans sa ligne de conditions-et-esquisse, chaque id antérieur marqué comme corrigé, contesté (avec les preuves), ou refusé (avec la raison), et les hunks modifiés depuis le dernier round. Dites au relecteur de ne relire que les ids ouverts et ces hunks, d'écrire de nouvelles conditions pour le comportement que ces hunks modifient et leurs appelants, de marquer chaque id antérieur comme résolu ou toujours ouvert, et de numéroter les nouvelles constatations après le dernier id. Lorsqu'une correction a modifié le comportement, l'ordre ou la propriété, comme déplacer une écriture après une attente, démarrez également un briseur avec le même en-tête, à qui il est dit d'écrire et de tester les conditions uniquement pour ces hunks et leurs appelants.
4. Terminer
Terminé lorsqu'aucun bloquant ou devrait n'est ouvert et que le dernier changement en dehors des tests, des commentaires et du formatage a passé un round ; APPROUVER termine la boucle plus tôt sur le code qu'il a relu. Envoyez un nouveau briseur sur tout COULDN'T TEST dont la cause peut être corrigée ; listez celui qui nécessite E2E pour l'auteur. Si un bloquant ou un devrait est toujours contesté après le round 3, exécutez le round de contestation dans dispute-round.md ; une constatation qu'il laisse INCONCLUSIF termine la boucle avec des contestations non résolues, pas approuvée. Les nits refusés et les constatations préexistantes restent refusés.
Message final : rounds exécutés, les modèles, ce que les constatations ont changé, chaque comportement, test, affirmation ou polissage étiqueté, taille du diff avant et après, toute constatation abandonnée parce qu'un test ou une sortie a montré qu'elle était erronée, et chaque nit refusé ou constatation préexistante avec sa raison. Ajoutez ce que le briseur a testé, ce qui a cassé, lesquels de ceux-ci le relecteur a également trouvés, et chaque condition qu'aucun test commité ne couvre. Si un round de contestation a eu lieu, donnez chaque résultat. Listez chaque risque non confirmé en termes simples. Si evals/results.jsonl existe et que le modèle du relecteur diffère du dernier qu'il contient, dites-le et proposez une exécution de la suite de régression (evals/README.md).