adversarial-review

name	adversarial-review
description	Review adversariale d'un livrable : mode refute (≥2 réfutants mis en compétition) ou jury (2 juges indépendants qui scorent sur une grille /5 puis synthétisent). Usage canonique de delegate_task.
version	1.1.0
platforms	["linux","macos"]
metadata	{"hermes":{"tags":["review","adversarial","jury","delegate","quality"],"related_skills":["devils-advocate","engineering-advisor"],"model":"deepseek-v4-full"}}

adversarial-review

Adaptation de harper (66) + harvey (jury) — ULK → Hermes. Carte : docs/backlog/2026-06-28-SPEC-HERMES-ADVERSARIAL-REVIEW/CARD.md (P2, GitHub #268).

Lance ≥2 sous-agents concurrents à perspectives antagonistes puis agrège. Mode refute (harper : réfutants mis en compétition, on garde ce qui survit) ou jury (harvey : 2 juges scorent sur une grille /5 puis synthèse). Usage canonique de delegate_task.

Runtime & modèles

• DeepSeek V4 full : cadre les prompts antagonistes, agrège les verdicts, tranche. Tier ULK sonnet → DeepSeek full. Les sous-agents delegate_task tournent aussi sur DeepSeek full.
• Pas de délégation coding : la skill réfute et juge un livrable en argumentaire, elle n'écrit pas de code. delegate_task sert ici à paralléliser des revues, pas à coder.

Mode refute — cadrage compétitif (harper)

Les réfutants ne se contentent pas de réfuter : ils sont en compétition. Chaque sous-agent sait qu'il affronte ≥1 concurrent indépendant sur le même livrable, et celui qui remonte le plus de problèmes sérieux gagne (récompense performative — c'est la conscience d'être évalué contre un pair qui fait le travail, pas la récompense). On agrège, on dédoublonne, et on garde ce qui survit au recoupement. Prompt brutal (invalider), jamais poli (nuancer).

Mode jury — rubric harvey (/5)

Deux juges séquestrés (ne voient pas la note de l'autre) scorent le livrable sur la grille harvey, puis on moyenne. Écart de total > 1.0 → exposer le désaccord (axe litigieux + arbitrage motivé), jamais le masquer.

Axe	Pts	Question du juge
Feature	0–2	L'intention/le ticket est-il réellement satisfait ? (0 cassé · 1 partiel · 2 complet)
Code quality	0–2	Propre, idiomatique, sans duplication ni commentaires-bruit ni sur-ingénierie ?
Efficiency	0–1	Simple et direct (pas de détour, pas de data dupliquée) ?
TOTAL	/5

Procédure

1. INPUT : livrable + mode: refute|jury.
2. DELEGATE : 2 sous-tâches parallèles à prompts indépendants (angle X / angle Y), lancées sans attendre la première. Mode refute : injecter le cadrage compétitif dans chaque prompt.
3. Mode jury : chaque juge remplit la grille harvey (Feature /2 · Code quality /2 · Efficiency /1 → /5).
4. SYNTHESIS : agréger les 2 verdicts, verdict final consolidé (refute : garder ce qui survit · jury : moyenne des grilles + désaccord exposé si écart > 1.0).

Critères d'acceptation

• delegate_task lance ≥2 sous-agents en parallèle (pas séquentiel).
• Mode refute : cadrage compétitif explicite — chaque agent sait qu'il affronte un concurrent, cherche à invalider (pas nuancer), on garde ce qui survit au recoupement.
• Mode jury : grille harvey /5 (Feature /2 · Code quality /2 · Efficiency /1) + verdict consolidé.
• Synthèse finale intègre les deux verdicts et tranche (désaccord jury exposé, jamais masqué).
• Test sur une spec réelle validé.

Pièges

• « Nuancer » ≠ « réfuter » : le prompt des sous-agents doit être brutal (harper), pas poli.
• Ne pas inventer d'échelle : harvey note en /5 (Feature/Code quality/Efficiency), jamais /10.
• Prompts des 2 sous-tâches indépendants (pas de référence croisée) — synthèse après collecte.
• Perdre le cadrage compétitif de refute ou la grille harvey /5 = perdre la valeur ajoutée vs une simple contre-lecture.