RIJUDEVx/interrogate

Que fait interrogate ?

Générer un réviseur par modèle configuré pour examiner contradictoirement les modifications de code. Chaque modèle reçoit le même prompt et la même rubrique. Le signal contradictoire provient de la diversité des modèles, non de personnages attribués.

Une conclusion ne survit que lorsqu'une exécution la prouve.

Le livrable est un verdict synthétisé. Ne PAS appliquer les modifications automatiquement.

Étape 1, Déterminer le périmètre

Identifier ce qu'il faut examiner à partir du contexte :

• Si l'utilisateur pointe vers des fichiers spécifiques ou un diff, utilisez-les
• Si sur une branche de fonctionnalité, exécutez git diff main...HEAD (ou la branche de base appropriée) pour l'ensemble des modifications
• Si le message de l'utilisateur fait référence à un travail récent, rassemblez les fichiers concernés

Regroupez le diff (ou le contenu des fichiers) ainsi que les fichiers de contexte environnants nécessaires aux réviseurs pour comprendre le code.

Étape 2, Énoncer l'intention

Avant de générer les réviseurs, énoncer l'intention explicitement. Déduisez-la de :

• Le message de l'utilisateur
• Les messages de commit
• La description de la PR si elle existe
• Le code lui-même

Rédigez un paragraphe clair. Si vous n'êtes pas sûr de l'intention, demandez à l'utilisateur avant de continuer.

Étape 3, Générer les réviseurs

Lancez tous les réviseurs dans un seul message, un par emplacement, avec l'outil de sous-agent du harnais ou delegate_task.

Visez la diversité des modèles : différentes familles de modèles détectent différents bugs. Dans T3 Code, choisissez 3-4 modèles solides parmi les favoris de l'utilisateur, de différentes familles, et démarrez chacun avec delegate_task (le skill t3-tools contient les étapes). Ailleurs, choisissez 3-4 modèles distincts de haute capacité que le harnais expose. Si vous ne pouvez pas sélectionner un modèle par sous-agent, générez des réviseurs sans remplacement de modèle et obtenez la diversité à partir de contextes indépendants à la place.

Sous-agent	Rôle
Réviseur A	réviseur axé sur le raisonnement
Réviseur B	deuxième famille de modèles indépendante
Réviseur C	une troisième famille rapide/différente
Réviseur D	réviseur contradictoire/strict sur la qualité du code

Pour chaque réviseur, générez un sous-agent à usage général :

• OpenCode / Codex : subagent_type: general (via l'outil task)
• Claude Code : subagent_type: general-purpose
• Autres harnais : le sous-agent général le plus proche capable de lire le dépôt

Gardez les réviseurs en lecture seule dans l'esprit : ils ne doivent pas modifier les fichiers. Un réviseur qui a besoin d'une reproduction l'exécute dans sa propre copie de travail ou son propre espace de travail, jamais sur place.

Donnez à chaque réviseur ce briefing ainsi que le modèle rempli :

Cassez cette modification. Prouvez chaque conclusion avec une exécution contre le code réel, comme un test échoué, un script de reproduction, ou une sortie de commande qui montre le comportement erroné. Pour une conception ou un plan, exécutez un prototype ou sondez l'arborescence actuelle. Gardez les reproductions dans votre propre espace de travail. Rapportez chaque conclusion avec un titre, la commande exacte, la sortie qu'elle a imprimée, et la sortie requise par l'intention. Laissez de côté tout ce que vous n'avez pas exécuté. Cela couvre le style, le nommage, la structure et les risques qui nécessitent une modification future pour avoir de l'importance. Aucune conclusion est un résultat valable.

Si un slug de modèle est rejeté comme irrésolvable, vérifiez les slugs valides dans le message d'erreur de l'outil Task, choisissez l'équivalent le plus proche (préférez le niveau de raisonnement le plus élevé de la même famille), et générez avec le slug valide. Ne bloquez pas la revue sur le problème de slug.

Lisez references/reviewer-prompt.md et remplissez le modèle avec :

1. L'intention énoncée
2. Le diff ou le contenu des fichiers
3. La rubrique de revue de references/rubric.md
4. L'optique de qualité de code de references/code-quality-review.md

Le même modèle rempli va à tous les réviseurs, de sorte que chaque modèle applique l'optique de qualité de code.

Étape 4, Synthétiser

Au fur et à mesure que les résultats reviennent, construisez une image unifiée :

1. Vérifiez chaque conclusion en réexécutant sa commande. Gardez une conclusion lorsque la sortie montre l'échec et que l'échec contredit l'intention. Jetez le reste. Fusionnez les conclusions qui partagent une cause racine.
2. Analysez toutes les conclusions des réviseurs
3. Identifiez le consensus. Les conclusions soulevées par 2 modèles ou plus indépendamment sont le signal le plus fort.
4. Identifiez les conclusions d'un seul modèle. Toujours dignes d'être lues, mais pondérez en conséquence.
5. Dédoublez. Différents modèles peuvent décrire le même problème différemment. Fusionnez-les et notez quels modèles l'ont soulevé.
6. Notez les désaccords. Si un modèle signale quelque chose et qu'un autre dit explicitement le contraire, c'est un contexte utile pour le verdict.

Étape 5, Jugement principal

Vous êtes le réviseur principal, un ingénieur senior pragmatique, pas un agrégateur neutre.

Lisez references/lead-judgment.md pour le cadre complet.

Catégorisez chaque conclusion en utilisant ces catégories :

• Agir. Problèmes réels affectant l'exactitude, la sécurité ou la maintenabilité compte tenu des objectifs réels. Ceux-ci bloqueraient une vraie PR.
• Considérer. Points légitimes, mais vous n'êtes pas sûr qu'ils surpassent le coût de les traiter maintenant. Digne de l'attention de l'utilisateur.
• Noté. Techniquement valide mais non actionnable. Dépendant du contexte, optimisation prématurée, ou faible impact compte tenu de l'étape actuelle.
• Rejeté. Faux, pointilleux, ou manquant de contexte. Brève explication pourquoi.

Pour chaque conclusion, incluez :

• Quel(s) modèle(s) l'ont soulevée
• La catégorie (agir / considérer / noté / rejeté)
• Une justification d'une ligne pour la catégorisation

Format de sortie

Présentez le verdict dans cette structure :

Intention

[Le paragraphe d'intention énoncée de l'étape 2]

Réviseurs

• Réviseur [étiquette] : [nom du modèle], [N conclusions] (une puce par réviseur)

Agir

[Conclusions qui doivent être traitées. Pour chacune : description, quels modèles l'ont soulevée, pourquoi c'est important.]

Considérer

[Conclusions qui méritent réflexion. Pour chacune : description, quels modèles l'ont soulevée, compromis impliqué.]

Noté

[Valides mais faible priorité. Liste brève.]

Rejeté

[Conclusions rejetées avec brève justification, y compris les conclusions qu'aucune exécution n'a prouvées.]

Carte des accords

[Où les modèles étaient-ils d'accord, où ont-ils divergé, et que nous dit le modèle d'accord/désaccord ?]

Rayon d'explosion

Utilisez ce mode lorsqu'une modification est petite mais pas encore fiable, et que la question est de savoir ce qu'elle casse au-delà du diff. Lister les appelants n'est pas le travail. Grep les trouve en une seconde. Le travail est la casse que grep ne montrera pas.

Ne faites pas confiance à votre propre compte rendu

Un compte rendu de ce qu'une modification casse qui semble correct est sans valeur. Il se lit comme convaincant, qu'il soit vrai ou non. Donc ne rendez pas le compte rendu. Trouvez le ou les deux faits dont tout dépend et prouvez-les en exécutant du code.

À quel point êtes-vous sûr

Pour chaque fait dont dépend la sécurité de la modification, faites-le descendre aussi loin que possible dans cette liste, et dites où il s'est arrêté.

1. Vous l'avez dit. Sans valeur seul.
2. Vous avez pointé la ligne. Un vrai fichier:ligne, ou le code source de la bibliothèque elle-même.
3. Vous avez montré que le mauvais cas ne peut pas arriver. Vous avez parcouru l'échec étape par étape et il n'atteint pas.
4. Vous l'avez exécuté. Un script ou un test qui appelle le code réel et échoue bruyamment si vous avez tort.
5. Vous l'avez reproduit dans l'application en cours d'exécution.

Tout fait de sécurité que vous ne pouvez pas amener à l'étape 4, dites-le. Ne le rédigez pas comme réglé. L'étape 4 est généralement un petit script qui importe la même bibliothèque que celle livrée avec l'application et appelle la fonction exacte qui vous préoccupe.

Étapes

1. Lisez la modification. Le diff, les symboles qu'il ajoute, modifie et supprime, et ce qu'il fait maintenant différemment, y compris la partie que le diff n'explicite pas. Tirez les messages de la PR et du commit pour la raison qui la sous-tend.
2. Trouvez l'unique fait pour lequel elle est sûre. La plupart des modifications qui semblent risquées sont sûres à cause d'un seul fait, comme "cet appel ne supprime que les entrées de cache déjà mortes et ne fait rien d'autre". Trouvez ce fait. S'il tient, la plupart des cas risqués sont éliminés d'un coup. Passez votre temps ici, pas sur une longue liste de peut-être.
3. Regardez où grep s'arrête. Lisez le code source de la bibliothèque que vous appelez, et vérifiez sa version figée et tout patch local. Déterminez quand les choses s'exécutent : micro-tâches, démontage et nettoyage, Solid versus React. Suivez ce qu'une recherche de symbole manque : le JSON qu'une API retourne, une colonne de base de données, un format filaire, une autre langue lisant les mêmes octets, un drapeau de fonctionnalité, du code à trois sauts en aval.
4. Soyez honnête sur chaque risque. Donnez-lui une réelle probabilité de se produire et un coût réel si c'est le cas. Gardez les risques que vous avez confirmés. Listez ceux que vous avez vérifiés et écartés séparément. Citez un vrai fichier:ligne, une recherche qui ne trouve rien est toujours une réponse, et n'inventez jamais un appelant ou une API.
5. Prouvez l'unique fait. Écrivez un script ou un test qui exécute le code réel, exécutez-le, et collez ce qui s'est passé. Si vous ne pouvez pas le prouver à moindre coût, marquez-le comme non prouvé. N'exagérez pas.
6. Pour une modification importante ou étendue, passez-la en revue ci-dessus avec plusieurs modèles. Différents modèles détectent différents bugs réels.

Ce qu'il faut rendre

• Ce qu'elle fait. Ce qui a changé, y compris la partie qui n'est pas évidente.
• L'unique fait pour lequel elle est sûre. Énoncez-le, dites à quelle étape vous l'avez amené, et montrez la preuve. Si vous n'avez pas pu le prouver, écrivez non prouvé.
• Risques. Uniquement les réels. Chacun nomme comment ça casse, le fichier:ligne, la probabilité et la gravité, et comment vérifier. Collez la preuve pour ceux qui comptent.
• Écarté. Ce que vous avez vérifié et pourquoi c'est bon.
• Avant de fusionner. Le test ou la reproduction le moins cher qui détecte le vrai bug, y compris le script que vous avez écrit.

Rédigez-le via unslop, citez du code réel, et retirez tout élément privé avant qu'il n'aille quelque part de public.

Réponse : le compte rendu ci-dessus, avec l'unique fait de sécurité soit prouvé, soit marqué non prouvé.