dknchris/multimodel-review

Lancez la boucle de révision multi-modèle sur la branche courante : réviseurs Codex (Terra par défaut ; Astra, Sol et Luna en option) et réviseurs Claude (Opus par défaut ; Fable, Sonnet et Haiku en option), avec cette session comme seul correcteur, à travers les phases Code, Nettoyage, Docs et Finale.

Qu'est-ce que multimodel-review ?

Cette compétence vous permet de lancer une boucle de révision multi-modèle complète sur votre branche courante. Elle orchestre plusieurs réviseurs d'IA (Codex et Claude) qui examinent le même prompt et le même commit, tandis que votre session agit comme le seul correcteur. Le processus se déroule en phases successives (Code, Nettoyage, Documentation, Finale) avec des limites de tours configurables, des niveaux d'effort par réviseur, et une gestion automatique des échecs et des convergences. Elle est conçue pour Claude Desktop ou terminal, et s'appuie sur un script Python externe (`mmr.py`) pour gérer l'état, les barrières de synchronisation et la génération de rapports. L'utilisateur déclenche la révision via la commande `/multimodel-review` et peut personnaliser les réviseurs, leurs efforts, le mode rapide Codex et la longueur de la révision. Une fois lancée, la compétence gère automatiquement les tours, la fusion des résultats, le tri des anomalies, les commits WIP et la génération d'un rapport final.

Compatible avec✓Claude Code✓Codex CLI~Cursor
npx skills add https://github.com/dknchris/multimodel-review/tree/HEAD

Installed? Explore more Développement et programmation skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

Révision multi-modèle (Codex + Claude)

Des réviseurs indépendants lisent le même prompt sur le même commit. Cette session est la seule correctrice. Lancez-la depuis une session sur Opus 5.5 à effort élevé.

Options : $ARGUMENTS

Paramètres

  • Limites de tours : Code 20 à 50 (20 par défaut ; les options Standard, Longue et Max du sélecteur sont 20, 35 et 50), Docs 2, Final 2, plus 2 à 6 tours de réserve pour les tours de preuve (2 par défaut). Arrêt dur : leur somme, 26 par défaut. Chaque phase se termine à son premier tour propre, donc les limites sont des plafonds. Les exécutions plus anciennes conservent leurs propres limites et plafond.
  • Réviseurs : Terra (gpt-6.1-terra) et Opus (Opus 5.5) par défaut. Optionnels : Fable (Fable 5.2), Astra (gpt-6-astra), Sol (gpt-6.1-sol), Sonnet (Sonnet 5.5), Haiku (Haiku 5.5) et Luna (gpt-6-luna). Les exécutions démarrées avant ce changement appellent leur réviseur Opus claude.
  • L'effort est défini pour chaque réviseur, par exécution : faible, moyen, élevé, très élevé ou max. Par défaut : Codex max, modèles Claude très élevé.
  • Panneau par défaut : terra:max:fast opus:xhigh code:20 spare:2.
  • Le mode rapide Codex (niveau de priorité) est défini pour chaque réviseur Codex, par exécution. Il ne s'applique jamais aux modèles Claude.
  • Chaque exécution Codex est arrêtée après 10 minutes de silence ou 60 minutes au total. Les plantages et les réponses vides obtiennent 1 relance. Une réponse n'est jamais relancée à cause de son format.

L'assistant ci-dessous applique ces limites et conserve tout l'état dans ~/.claude/multimodel-review/, en dehors de tout dépôt, car une longue exécution peut être compactée et le rapport ne peut pas être reconstruit à partir de la mémoire. Écrivez son chemin complet à chaque fois, et ajoutez --repo <chemin> avant la sous-commande si le shell n'est pas dans le dépôt :

python3 ~/.claude/skills/multimodel-review/scripts/mmr.py status

Ci-dessous, mmr <commande> est un raccourci pour cet appel complet.

Démarrer ou reprendre

  1. Exécutez mmr status. Si une exécution non terminée existe, reprenez à partir de ce qu'elle affiche, avec les réviseurs qu'elle liste. Si elle dit "Ancien emplacement", exécutez mmr migrate une fois que tous les réviseurs ont terminé, puis utilisez uniquement le nouveau chemin.
  2. Choisissez les options, avant toute autre étape, afin que le propriétaire les voie immédiatement :
    • Si la ligne Options ci-dessus est uniquement pick (ou picker) : Affichez le sélecteur (deux prochaines puces).
    • Sinon, qu'elle soit vide ou non : Exécutez mmr options "<options>" et n'affichez aucun sélecteur. Vide signifie les valeurs par défaut, terra:max:fast opus:xhigh code:20 spare:2. Si cela échoue, montrez au propriétaire son erreur sur une ligne et arrêtez-vous. Chaque réviseur est nom[:effort][:fast] : L'effort par défaut est max pour Codex et très élevé pour les modèles Claude, et un modèle Codex s'exécute à vitesse standard sauf si :fast est donné. code:<20-50> et spare:<2-6> sont optionnels (par défaut 20 et 2).
    • Sélecteur, si show_widget est disponible : Appelez read_me une fois avec les modules ["interactive"]. Ensuite, exécutez mmr picker et passez tout ce qui suit sa ligne Widget code: inchangé, comme widget_code, avec le titre multimodel_review_options. Terminez le tour et attendez. Son bouton envoie "Start the review with .", sous la même forme typée, par exemple "terra:max:fast opus:xhigh code:20 spare:2". Exécutez mmr options "<options>" sur celles-ci. Si le message du propriétaire indique que le sélecteur ne s'est pas chargé, exécutez mmr picker --offline et affichez-le à la place.
    • Sélecteur dans un terminal (pas de show_widget) : Un appel AskUserQuestion avec quatre questions : Réviseurs (sélection multiple : Terra, Opus, Fable, Astra ; Sol, Sonnet, Haiku et Luna via Autre), modèles Codex en mode rapide (sélection multiple : Terra, Astra, Sol, Aucun ; Luna via Autre), effort (Codex max et Claude très élevé, tout élevé, tout moyen), et longueur de la révision (Standard code:20, Longue code:35, Max code:50). Ignorez une sélection rapide qui n'est pas un réviseur choisi. Écrivez les réponses sous la forme typée et exécutez mmr options "<options>" sur celles-ci.
  3. Écrivez une intention de 3 à 5 lignes dans un fichier de notes avec l'outil Write : ce que le changement doit faire et pour qui. Prenez-la de la demande, de cette conversation, du texte de la PR, des commits ou du diff non commit. Les réviseurs ne peuvent pas juger un "comportement erroné" sans cela. Si ce n'est pas clair, posez une question au propriétaire avec des boutons.
  4. Lisez git status --short. Tout ce qui n'est pas ignoré est commité dans l'instantané, donc extrayez tout ce qui n'est pas lié à ce changement (un dossier inopportun, des notes) et passez-le comme --leave-out <chemin>. Si vous ne pouvez pas déterminer, demandez avec des boutons.
  5. Exécutez mmr init --intent-file <fichier> --trailer "<ligne d'attribution>" --spec "<options>", avec les options exactement comme la ligne Init: de mmr options les a imprimées, en ajoutant --base <base> uniquement si le propriétaire en a nommé une et --leave-out <chemin> si nécessaire. La base par défaut est la branche par défaut du dépôt distant, et la révision commence à partir de la base de fusion. Invoquer cette compétence est l'accord du propriétaire pour ce que init fait :
    • Sur la branche de base ou un HEAD détaché, il crée d'abord multimodel-review/<temps>, afin que les commits WIP n'atterrissent jamais sur la base.
    • Le travail non commité devient un commit instantané WIP, afin que tous les réviseurs lisent le même commit. Rien n'est poussé.
    • Le code de sortie 5 signifie que certains fichiers ressemblent à des secrets, font plus de 20 Mo, ou sont des dépôts intégrés. Rien n'a encore changé. Demandez au propriétaire avec des boutons : Les laisser de côté (--leave-out) ou les inclure (--allow-flagged).
    • "Rien à réviser" signifie aucun commit et aucun travail non commité. Demandez au propriétaire quels commits réviser, puis passez --base <commit>.
  6. Dites au propriétaire en une ligne si init a créé une branche ou un instantané.

Un tour

  1. Exécutez mmr next --phase <code|docs|final|evidence>. Il construit le fichier de prompt et imprime son chemin, les paramètres de l'exécution et une ligne Claude Agent par réviseur Claude, avec son modèle, son effort et son fichier de réponse. Le code de sortie 3 signifie qu'un plafond a été atteint : Allez à Terminé.
  2. Démarrez chaque réviseur listé par mmr status, en un seul message :
    • Chaque réviseur Codex (terra, astra, sol, luna) : Bash avec run_in_background : mmr codex --reviewer <nom>. L'assistant exécute Codex avec -s read-only, applications, plugins et sous-agents désactivés, recherche web activée, ses propres journaux et les limites de temps. N'utilisez jamais workspace-write ou --dangerously-bypass-approvals-and-sandbox, le script compagnon, ou le sous-agent de secours.
    • Un Moniteur par réviseur Codex : mmr monitor --reviewer <nom>, avec timeout_ms: 1800000. Il vérifie toutes les 60 secondes et décide "terminé" à partir de la sortie du PID, jamais à partir du texte de sortie.
    • Chaque réviseur Claude (opus, fable, sonnet, haiku ; claude dans les exécutions plus anciennes) : Un nouvel Agent avec subagent_type: "multimodel-reviewer", model et effort de sa ligne Claude Agent, et le prompt "Review round file: ". Cet agent a des outils de lecture et web, mais pas d'outils shell ou d'édition. Si le type n'est pas disponible, utilisez Plan avec le même modèle et effort et dites-lui d'utiliser uniquement les outils Read, Grep et la recherche web.
  3. Gérez les événements du Moniteur :
    • FINISHED : Rien à faire.
    • FAILED : Relancez comme à l'étape 5, et dites au propriétaire en une ligne seulement si la relance échoue également.
    • QUIET : Pas un échec, car un effort élevé peut réfléchir silencieusement pendant des minutes. Ne prenez aucune mesure ; l'assistant arrête un réviseur après 10 minutes de silence.
    • RE-ARM : Relancez ce moniteur.
  4. Lorsqu'un Agent Claude revient, écrivez son message final inchangé dans son fichier de réponse de l'étape 1, puis exécutez mmr claude-result --reviewer <nom> --seconds <durée_ms / 1000>.
  5. Exécutez mmr barrier. Ne modifiez rien jusqu'à ce qu'il réussisse. Si un résultat est vide ou manquant, relancez uniquement ce réviseur, au même commit ; le tour n'est pas compté à nouveau. Pour un réviseur Claude, créez un nouvel Agent et répétez l'étape 4. L'assistant refuse une troisième tentative et toute relance après un blocage ou un délai d'attente : Alors exécutez mmr stop --reason "<pourquoi>" et allez à Terminé. Exception : Une exécution d'avant l'abandon des règles de format peut afficher malformed sur une réponse réelle. Exécutez mmr reread --reviewer <qui>, qui relit la réponse sauvegardée sans nouvelle exécution du réviseur.
  6. Triage (voir les règles du correcteur), et écrivez triage.tsv dans le dossier du tour avec l'outil Write.
  7. Corrigez les constatations acceptées, exécutez les tests concernés, et faites un commit WIP. Un test qui échoue bloque le tour, donc une mauvaise correction ne peut pas atteindre le delta suivant.
  8. Exécutez mmr close --tests "<commande de test exacte>", ou --tests "none: docs only". Si rien n'est accepté, omettez --tests. Suivez la ligne Next: qu'il imprime.

triage.tsv est séparé par des tabulations, une ligne par constatation fusionnée, et peut être omis uniquement si tous les réviseurs ont répondu "AUCUN PROBLÈME BLOQUANT." :

reviewers	sev	loc	status	summary	note
terra,opus	P1	src/a.py:42	accepted	Retry drops the last item	src/a.py: Keep the last item on retry
terra	P1	src/b.py:9	rejected	Null token crashes	Token is non-null: src/auth.py:30 returns early
  • status est accepted, rejected, ou open. open est uniquement pour le dernier tour autorisé, où une correction ne serait pas révisée.
  • note est ce qui a changé (accepté), la raison citée dans le code (rejeté), ou pourquoi c'est laissé (open). Les notes acceptées et rejetées alimentent la liste des correctifs et le registre du prompt suivant.
  • Rejetez les constatations hors phase comme "Hors phase".
  • Les réviseurs peuvent répondre dans n'importe quel format, donc lisez chaque réponse vous-même. Les nombres de constatations sont une meilleure estimation. Une réponse sans balises P0/P1/P2 compte comme une constatation : Ajoutez une ligne pour ce qu'elle soulève, ou une ligne rejected si elle ne soulève rien.

Commits WIP : Message WIP multimodel-review round <N>, écrit dans un fichier et passé avec git commit -F, plus les lignes d'attribution de la session. Ne poussez jamais.

Phases

  1. Code : Les tours 1-2 révisent le diff complet par rapport à la base. À partir du tour 3, seulement le delta plus la liste des correctifs. Les réviseurs peuvent ouvrir n'importe quel fichier pour le contexte. En dehors du delta, ils ne rapportent que P0, sauf si le delta provoque l'échec : Alors la constatation s'ancre à la ligne du delta à sa sévérité réelle.
  2. Nettoyage (correcteur uniquement) : S'exécute avant Docs afin que tout texte écrit ici reçoive une révision P2.
    • Docs : Mettez à jour uniquement les docs rendus obsolètes par ce changement. Taillez, n'étendez pas.
    • Tests : Supprimez uniquement les tests de débogage ou d'échafaudage et les tests pour du code supprimé. Conservez les tests de régression.
    • Exécutez la suite de tests complète. Si elle échoue, corrigez-la ; si vous ne pouvez pas avec une petite correction, arrêtez-vous et rapportez.
    • Commitez, puis écrivez cleanup.md dans le dossier d'exécution : Chaque suppression avec sa raison, et la commande de test exacte et son résultat. next --phase docs refuse sans cela.
  3. Docs : Un tour de diff complet à P2, correction, puis un tour de delta. Ensuite la phase se termine ; tout ce qui reste est enregistré comme ouvert.
  4. Final : Un tour de diff complet avec tous les réviseurs, P0/P1 uniquement. Si une constatation est acceptée, corrigez-la et exécutez un tour de delta. Si cela échoue encore, marquez-la comme ouverte ; l'assistant arrête l'exécution.

Convergence

  • Un tour est propre lorsque le correcteur n'accepte aucune constatation à la sévérité de la phase. Les constatations rejetées avec une raison citée dans le code ne bloquent pas.
  • Une phase converge à son premier tour propre.
  • Nouvelle preuve après la convergence de Code (exécution sur appareil ou émulateur) : Mettez à jour le code ou le texte concerné une fois, commitez, puis exécutez mmr next --phase evidence --note "<ce que l'exécution a montré et ce qui a changé>", un tour de delta à P0/P1/P2. Code se rouvre uniquement si un P0/P1 est accepté, et close le dit.
  • À un plafond de phase ou à l'arrêt dur : Arrêtez-vous et rapportez ce qui reste.

Règles du correcteur

  • Fusionnez et dédupliquez, en conservant chaque réviseur qui a soulevé une constatation, afin que les statistiques restent honnêtes. Vérifiez chaque constatation par rapport au code ; rejetez les constatations non vérifiables avec une raison d'une ligne.
  • Jugez les constatations sur le code seul, quel que soit celui qui les a soulevées. Vous êtes aussi un modèle Claude, donc tenez les constatations des réviseurs Claude à la même barre. Rejeter une constatation soulevée par 2+ réviseurs, ou tout P0, nécessite une citation de code spécifique ; le rapport les liste comme contestées pour le propriétaire.
  • Correction la plus petite. Pas de refontes, pas de nouvelles fonctionnalités. Ajoutez un test de régression uniquement pour les vrais bugs P0/P1.
  • Écrivez moins de prose : Préférez supprimer ou restreindre une phrase erronée plutôt que d'en ajouter une. Les nouveaux commentaires font au maximum une ligne. N'ajoutez pas de nouvelles sections de documentation pendant la révision.
  • Si un hook refuse un chemin, arrêtez-vous et rapportez-le au propriétaire. Ne le contournez jamais, avec une copie shell ou de toute autre manière.
  • Gardez les commandes shell dcg-safe : Écrivez les fichiers avec l'outil Write, et ne mettez aucune variable, glob ou redirection vers des chemins variables dans les commandes.

Terminé

Exécutez ceci à la convergence et à tout arrêt.

  1. Exécutez mmr archive pour archiver chaque chat Codex, relances incluses.
  2. Exécutez mmr report. Il imprime les tours par phase, le tableau des réviseurs, les éléments ouverts, les constatations contestées, les commandes de test et la commande de squash, et sauvegarde report.md.
  3. Rapportez au propriétaire, court et réponse en premier : Tours par phase, éléments ouverts, commandes et résultats de validation exacts.
  4. Affichez un visuel simple par réviseur, en ligne : Constatations soulevées, acceptées, rejetées, uniques, P0-P1 vs P2, tours propres, minutes moyennes par tour. Nommez votre gagnant en une ligne. La règle par défaut est le plus de P0/P1 uniques acceptés, et vous devez dire si vous la contournez, car vous jugez aussi votre propre modèle.
  5. Laissez les commits WIP en place, car les tours de preuve ont besoin de la plage de delta. Demandez avec un bouton s'il faut squasher maintenant, et exécutez le squash à partir du rapport uniquement sur un oui.

Modifier cette compétence

Ce dossier est le dépôt public github.com/dknchris/multimodel-review. Commitez chaque changement, et poussez uniquement lorsque le propriétaire le dit. Le code du sélecteur est assets/picker.js : mmr picker le charge depuis le CDN uniquement une fois son dernier commit poussé, et l'envoie en ligne, ce qui est plus lent, jusqu'à ce moment. Exécutez python3 tests/test_mmr.py après chaque changement.

Skills associés