Description
Produisez un travail qui résiste à un examen indépendant — créez des évaluateurs ciblés, révisez selon leurs objections, et ne vous arrêtez que lorsque le seuil de qualité est atteint.
Déclencheurs
- « ne t'arrête pas tant que ce n'est pas vraiment bon / tant que chaque évaluateur n'est pas satisfait »
- « compare-le avec le vrai X » / « benchmarque-le contre Y »
- « évalue ceci correctement » / « c'est vraiment bon ? »
- Tout livrable qui doit tenir face à un concurrent ou à une spécification
Instructions
L'échec par défaut du travail d'agent est de livrer la première version. Elle se lit bien, elle est plausible, et rien ne l'a vérifiée. Vous êtes le pire juge possible de votre propre production — vous l'avez écrite, donc elle correspond à votre modèle de ce qui était attendu par construction.
Recourez à panel_refine quand
- Le travail sera comparé à quelque chose de spécifique — la sortie d'un concurrent, une spécification, une implémentation existante, un document de référence.
- Se tromper est coûteux : livrables clients, toute publication, code touchant l'argent, l'authentification ou la suppression.
- L'opérateur signale un seuil de qualité plutôt qu'une tâche (« ne t'arrête pas tant que… », « rends-le vraiment bon »).
Ne le faites pas quand
- La tâche est une recherche, un appel d'outil unique ou une réponse rapide. Chaque itération comprend plusieurs exécutions complètes d'agent — c'est votre outil le plus coûteux.
- Il n'y a pas de référence et pas de standard clair. Des évaluateurs invités à noter les impressions retournent des impressions.
Comment bien l'utiliser
Fournissez toujours reference quand elle existe. C'est la différence entre « c'est bon ? » (sans réponse) et « cela correspond ou surpasse cela ? » (répondable). Si l'opérateur a nommé quelque chose à comparer, passez-le.
Choisissez des angles qui divergent. Cinq évaluateurs interrogés sur « c'est bon » vous donnent une opinion cinq fois. Les paquets intégrés (code, writing, analysis) sont déjà distincts ; ajoutez des angles personnalisés quand le travail a un risque spécifique :
lenses: [{"name": "licensing", "brief": "Code GPL copié dans un repo sous licence
PolyForm ; attribution supprimée"}]Gardez max_rounds à 2–3. Si trois itérations de critiques ciblées ne l'ont pas corrigé, l'objectif est mal spécifié — retournez à l'opérateur plutôt que de brûler une quatrième.
Utilisez panel_review seul quand le travail existe déjà et que vous avez seulement besoin du verdict — évaluer une PR, vérifier un brouillon avant l'envoi.
Lire le résultat
converged: true signifie que les angles indépendants l'ont accepté. Dites-le clairement.
converged: false signifie qu'il n'a pas réussi. L'artefact est la meilleure tentative, pas un résultat. Rapportez les constatations en attente et dites ce qui ne va toujours pas — ne le présentez pas comme terminé et ne supprimez pas silencieusement la réserve.
L'outil refuse de revendiquer un succès qu'il n'a pas obtenu ; vous ne devez pas blanchir cela en son nom.
Un rejet qui ne cite aucun défaut spécifique est rejeté par conception. Si la série s'arrête avec « approbation retenue sans citer un défaut », le panel n'avait rien de réel à dire — traitez le travail comme non validé plutôt que comme échoué.
La version honnête de « ne t'arrête pas tant que »
L'opérateur qui le demande veut que le travail soit bon, pas que la boucle s'exécute indéfiniment. Converger en une itération est un succès, pas un raccourci. Passer trois itérations et échouer toujours vaut la peine de le signaler immédiatement — cela signifie généralement que la tâche était ambiguë, et une autre itération ne résoudra pas l'ambiguïté.
Vérifier
- Une
referencea été passée chaque fois que l'opérateur a nommé quelque chose à égaler - Les angles étaient genuinely distincts, pas des reformulations de « sois bon »
convergeda été rapporté honnêtement, y compris quand c'est faux- Les constatations en attente ont été mises en évidence plutôt que supprimées
- L'outil n'a pas été utilisé pour un travail qui ne justifiait pas le coût