Communitygithub.com

santa-method

Vérification multi-agent adversarial avec boucle de convergence. Deux agents d'évaluation indépendants doivent tous deux réussir avant la publication. À utiliser lorsque la sortie doit être approuvée par deux réviseurs adverses indépendants avant d'être livrée.

Qu'est-ce que santa-method ?

Santa Method est un framework de vérification multi-agent adversarial conçu pour les sorties générées par IA qui doivent être fiables et sans erreurs. Son principe central est qu'un seul agent évaluant sa propre production partage les mêmes biais, lacunes et erreurs systématiques. En utilisant deux agents d'évaluation totalement indépendants, sans contexte partagé, ce mode de défaillance est éliminé. Le processus se déroule en quatre phases : génération, double évaluation indépendante avec la même grille d'évaluation, verdict (les deux doivent passer pour que la sortie soit qualifiée de « sage »), et boucle de correction jusqu'à convergence. Le framework définit des composants clés comme la grille d'évaluation (rubric) qui doit être objective et précise, avec des critères tels que l'exactitude factuelle, l'absence d'hallucinations, la complétude et la conformité. Il propose plusieurs implémentations : sous-agents Claude Code en parallèle (recommandé), évaluation séquentielle en ligne, et échantillonnage par lots pour les grands volumes. Les métriques de suivi incluent le taux de première passe, le nombre moyen d'itérations, la taxonomie des échecs, la concordance entre évaluateurs et le taux d'échappement. Le coût est estimé à 2-3 fois le coût de génération seul, mais cela reste une bonne affaire au vu des risques évités.

Compatible avec✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/affaan-m/ECC/tree/main/skills/santa-method

Demander à votre IA préférée

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

Documentation

Méthode Santa

Framework de vérification multi-agent adversarial. Fais une liste, vérifie-la deux fois. Si c'est méchant, corrige jusqu'à ce que ce soit sage.

L'idée fondamentale : un seul agent qui évalue sa propre production partage les mêmes biais, lacunes de connaissances et erreurs systématiques qui ont produit cette sortie. Deux évaluateurs indépendants, sans contexte partagé, brisent ce mode de défaillance.

Quand activer

Invoque cette compétence lorsque :

  • La sortie sera publiée, déployée ou consommée par des utilisateurs finaux
  • Des contraintes de conformité, réglementaires ou de marque doivent être respectées
  • Le code est livré en production sans revue humaine
  • L'exactitude du contenu est importante (docs techniques, matériel éducatif, contenu client)
  • La génération en lots à grande échelle où le contrôle ponctuel manque les schémas systémiques
  • Le risque d'hallucination est élevé (affirmations, statistiques, références API, langage juridique)

Ne PAS utiliser pour les brouillons internes, la recherche exploratoire ou les tâches à vérification déterministe (utilise les pipelines build/test/lint pour celles-ci).

Architecture

┌─────────────┐
│  GÉNÉRATEUR  │  Phase 1 : Fais une Liste
│  (Agent A)   │  Produis le livrable
└──────┬───────┘
       │ sortie
       ▼
┌──────────────────────────────┐
│   DOUBLE ÉVALUATION INDÉP.   │  Phase 2 : Vérifie-le Deux Fois
│                               │
│  ┌───────────┐ ┌───────────┐ │  Deux agents, même grille,
│  │ Évaluateur│ │ Évaluateur│ │  aucun contexte partagé
│  │ B         │ │ C         │ │
│  └─────┬─────┘ └─────┬─────┘ │
│        │              │       │
└────────┼──────────────┼───────┘
         │              │
         ▼              ▼
┌──────────────────────────────┐
│      VERDICT – PORTE          │  Phase 3 : Méchant ou Sage
│                               │
│  B réussi ET C réussi → SAGE  │  Les deux doivent réussir.
│  Sinon → MÉCHANT              │  Aucune exception.
└──────┬──────────────┬─────────┘
       │              │
     SAGE          MÉCHANT
       │              │
       ▼              ▼
   [ LIVRER ]   ┌─────────────┐
                │  CYCLE DE   │  Phase 4 : Corriger Jusqu'à Sage
                │ CORRECTION  │
                │             │
                │ itération++ │  Collecte tous les flags.
                │ si i > MAX: │  Corrige tous les problèmes.
                │   escalade  │  Relance les deux évaluateurs.
                │ sinon:      │  Boucle jusqu'à convergence.
                │   goto Ph.2 │
                └─────────────┘

Détails des Phases

Phase 1 : Fais une Liste (Générer)

Exécute la tâche principale. Aucun changement à ton workflow de génération normal. La Méthode Santa est une couche de vérification post-génération, pas une stratégie de génération.

# Le générateur fonctionne normalement
output = generer(specification_tache)

Phase 2 : Vérifie-le Deux Fois (Double Évaluation Indépendante)

Lance deux agents d'évaluation en parallèle. Invariants critiques :

  1. Isolement de contexte — aucun évaluateur ne voit l'évaluation de l'autre
  2. Grille identique — les deux reçoivent les mêmes critères d'évaluation
  3. Mêmes entrées — les deux reçoivent la spécification originale ET la sortie générée
  4. Sortie structurée — chacun retourne un verdict typé, pas une prose
PROMPT_EVALUATEUR = """
Tu es un évaluateur qualité indépendant. Tu N'AS PAS vu d'autre évaluation de cette sortie.

## Spécification de la Tâche
{tache_spec}

## Sortie à Évaluer
{sortie}

## Grille d'Évaluation
{grille}

## Instructions
Évalue la sortie sur CHAQUE critère de la grille. Pour chacun :
- RÉUSSI : le critère est pleinement satisfait, aucun problème
- ÉCHEC : problème spécifique trouvé (cite le problème exact)

Retourne ton évaluation sous forme de JSON structuré :
{
  "verdict": "RÉUSSI" | "ÉCHEC",
  "verifications": [
    {"critere": "...", "resultat": "RÉUSSI|ÉCHEC", "detail": "..."}
  ],
  "problemes_critiques": ["..."],   // bloqueurs à corriger
  "suggestions": ["..."]            // améliorations non bloquantes
}

Sois rigoureux. Ton travail est de trouver des problèmes, pas d'approuver.
"""
# Lance les évaluateurs en parallèle (sous-agents Claude Code)
evaluateur_b = Agent(description="Évaluateur Santa B", prompt=PROMPT_EVALUATEUR.format(...))
evaluateur_c = Agent(description="Évaluateur Santa C", prompt=PROMPT_EVALUATEUR.format(...))

# Les deux s'exécutent simultanément — aucun ne voit l'autre

Conception de la Grille d'Évaluation

La grille est l'entrée la plus importante. Des grilles vagues produisent des évaluations vagues. Chaque critère doit avoir une condition de réussite/échec objective.

CritèreCondition de RéussiteSignal d'Échec
Exactitude factuelleToutes les affirmations vérifiables par rapport à la source ou aux connaissances courantesStatistiques inventées, mauvais numéros de version, APIs inexistantes
Sans hallucinationAucune entité, citation, URL ou référence fabriquéeLiens vers des pages qui n'existent pas, citations attribuées sans source
ComplétudeChaque exigence de la spécification est traitéeSections manquantes, cas limites ignorés, couverture incomplète
ConformitéPasse toutes les contraintes spécifiques au projetTermes interdits utilisés, violations de ton, non-conformité réglementaire
Cohérence interneAucune contradiction dans la sortieSection A dit X, section B dit non-X
Exactitude techniqueLe code compile/fonctionne, les algorithmes sont validesErreurs de syntaxe, bugs logiques, mauvaises affirmations de complexité

Extensions de Grille par Domaine

Contenu/Marketing :

  • Respect de la voix de la marque
  • Exigences SEO satisfaites (densité de mots-clés, balises meta, structure)
  • Pas d'utilisation abusive des marques concurrentes
  • Appel à l'action présent et lié correctement

Code :

  • Sécurité des types (pas de fuite any, gestion correcte de null)
  • Couverture de la gestion des erreurs
  • Sécurité (pas de secrets dans le code, validation des entrées, prévention d'injection)
  • Couverture des tests pour les nouveaux chemins

Sensible à la conformité (réglementé, juridique, financier) :

  • Pas de garanties de résultats ni d'affirmations non fondées
  • Avertissements requis présents
  • Terminologie approuvée uniquement
  • Langage approprié à la juridiction

Phase 3 : Méchant ou Sage (Porte du Verdict)

def verdict_santa(evaluateur_b, evaluateur_c):
    """Les deux évaluateurs doivent réussir. Pas de demi-mesure."""
    if evaluateur_b.verdict == "RÉUSSI" and evaluateur_c.verdict == "RÉUSSI":
        return "SAGE"  # Livre-le

    # Fusionne les flags des deux évaluateurs, déduplique
    tous_problemes = dedupliquer(evaluateur_b.problemes_critiques + evaluateur_c.problemes_critiques)
    tous_suggestions = dedupliquer(evaluateur_b.suggestions + evaluateur_c.suggestions)

    return "MÉCHANT", tous_problemes, tous_suggestions

Pourquoi les deux doivent réussir : si un seul évaluateur détecte un problème, ce problème est réel. L'angle mort de l'autre évaluateur est exactement le mode de défaillance que la Méthode Santa existe pour éliminer.

Phase 4 : Corriger Jusqu'à Sage (Boucle de Convergence)

MAX_ITERATIONS = 3

for iteration in range(MAX_ITERATIONS):
    verdict, problemes, suggestions = verdict_santa(evaluateur_b, evaluateur_c)

    if verdict == "SAGE":
        logger_resultat_santa(sortie, iteration, "réussi")
        return livrer(sortie)

    # Corrige tous les problèmes critiques (les suggestions sont optionnelles)
    sortie = agent_correction.executer(
        sortie=sortie,
        problemes=problemes,
        instruction="Corrige UNIQUEMENT les problèmes signalés. Ne refactorise pas et n'ajoute pas de modifications non demandées."
    )

    # Relance LES DEUX évaluateurs sur la sortie corrigée (agents frais, sans mémoire du tour précédent)
    evaluateur_b = Agent(prompt=PROMPT_EVALUATEUR.format(sortie=sortie, ...))
    evaluateur_c = Agent(prompt=PROMPT_EVALUATEUR.format(sortie=sortie, ...))

# Itérations épuisées — escalade
logger_resultat_santa(sortie, MAX_ITERATIONS, "escaladé")
escalader_a_humain(sortie, problemes)

Critique : chaque tour d'évaluation utilise des agents frais. Les évaluateurs ne doivent pas conserver de mémoire des tours précédents, car le contexte antérieur crée un biais d'ancrage.

Schémas d'Implémentation

Schéma A : Sous-agents Claude Code (Recommandé)

Les sous-agents offrent un isolement de contexte réel. Chaque évaluateur est un processus séparé sans état partagé.

# Dans une session Claude Code, utilise l'outil Agent pour lancer les évaluateurs
# Les deux agents s'exécutent en parallèle pour la rapidité
# Pseudo-code pour l'invocation de l'outil Agent
evaluateur_b = Agent(
    description="Évaluateur Santa B",
    prompt=f"Évalue cette sortie pour la qualité...\n\nGRILLE :\n{grille}\n\nSORTIE :\n{sortie}"
)
evaluateur_c = Agent(
    description="Évaluateur Santa C",
    prompt=f"Évalue cette sortie pour la qualité...\n\nGRILLE :\n{grille}\n\nSORTIE :\n{sortie}"
)

Schéma B : Séquentiel en Ligne (Solution de Rechange)

Lorsque les sous-agents ne sont pas disponibles, simule l'isolement avec des réinitialisations explicites du contexte :

  1. Génère la sortie
  2. Nouveau contexte : « Tu es l'Évaluateur 1. Évalue UNIQUEMENT selon cette grille. Trouve des problèmes. »
  3. Enregistre les résultats mot pour mot
  4. Efface complètement le contexte
  5. Nouveau contexte : « Tu es l'Évaluateur 2. Évalue UNIQUEMENT selon cette grille. Trouve des problèmes. »
  6. Compare les deux évaluations, corrige, répète

Le schéma par sous-agents est strictement supérieur — la simulation en ligne risque un mélange de contexte entre les évaluateurs.

Schéma C : Échantillonnage par Lots

Pour les grands lots (100+ éléments), un Santa complet sur chaque élément est trop coûteux. Utilise l'échantillonnage stratifié :

  1. Exécute Santa sur un échantillon aléatoire (10-15% du lot, minimum 5 éléments)
  2. Catégorise les échecs par type (hallucination, conformité, complétude, etc.)
  3. Si des schémas systématiques émergent, applique des corrections ciblées à l'ensemble du lot
  4. Ré-échantillonne et revérifie le lot corrigé
  5. Continue jusqu'à ce qu'un échantillon propre réussisse
import random

def santa_lot(elements, grille, taux_echantillonnage=0.15):
    echantillon = random.sample(elements, max(5, int(len(elements) * taux_echantillonnage)))

    for element in echantillon:
        resultat = santa_complet(element, grille)
        if resultat.verdict == "MÉCHANT":
            schema = classifier_echec(resultat.problemes)
            elements = corriger_lot(elements, schema)  # Corrige tous les éléments correspondant au schéma
            return santa_lot(elements, grille)          # Ré-échantillonne

    return elements  # Échantillon propre → livre le lot

Modes de Défaillance et Atténuations

Mode de DéfaillanceSymptômeAtténuation
Boucle infinieLes évaluateurs trouvent constamment de nouveaux problèmes après correctionsPlafond d'itérations max (3). Escalade.
TamponnageLes deux évaluateurs approuvent toutPrompt adversarial : « Ton travail est de trouver des problèmes, pas d'approuver. »
Dérive subjectiveLes évaluateurs signalent des préférences de style, pas des erreursGrille stricte avec critères objectifs de réussite/échec uniquement
Régression de correctionCorriger le problème A introduit le problème BNouveaux évaluateurs à chaque tour pour détecter les régressions
Biais de concordanceLes deux évaluateurs ratent la même choseAtténué par l'indépendance, pas éliminé. Pour une sortie critique, ajoute un troisième évaluateur ou un contrôle ponctuel humain.
Explosion des coûtsTrop d'itérations sur les grosses sortiesSchéma d'échantillonnage par lots. Plafonds budgétaires par cycle de vérification.

Intégration avec d'Autres Compétences

CompétenceRelation
Boucle de VérificationÀ utiliser pour les vérifications déterministes (build, lint, test). Santa pour les vérifications sémantiques (exactitude, hallucinations). Exécute d'abord la boucle de vérification, puis Santa.
Harness d'ÉvaluationLes résultats de la Méthode Santa alimentent les métriques d'évaluation. Suis le taux de réussite@k dans les exécutions Santa pour mesurer la qualité du générateur au fil du temps.
Apprentissage Continu v2Les constats de Santa deviennent des instincts. Des échecs répétés sur le même critère → comportement appris pour éviter le schéma.
Pacte StratégiqueExécute Santa AVANT de compresser. Ne perds pas le contexte d'évaluation en cours de vérification.

Métriques

Suis ces éléments pour mesurer l'efficacité de la Méthode Santa :

  • Taux de première passe : % des sorties qui réussissent Santa au tour 1 (objectif : >70%)
  • Nombre moyen d'itérations jusqu'à convergence : tours moyens pour atteindre SAGE (objectif : <1,5)
  • Taxonomie des échecs : répartition des types d'échec (hallucination vs. complétude vs. conformité)
  • Concordance entre évaluateurs : % de problèmes signalés par les deux évaluateurs vs. un seul (faible concordance = grille à resserrer)
  • Taux d'échappement : problèmes trouvés après livraison que Santa aurait dû attraper (objectif : 0)

Analyse des Coûts

La Méthode Santa coûte environ 2 à 3 fois le coût en tokens de la génération seule par cycle de vérification. Pour la plupart des sorties à haut risque, c'est une affaire :

Coût de Santa = (tokens de génération) + 2×(tokens d'évaluation par tour) × (tours moyens)
Coût de PAS Santa = (dommages à la réputation) + (effort de correction) + (érosion de la confiance)

Pour les opérations par lots, le schéma d'échantillonnage réduit le coût à environ 15-20% de la vérification complète tout en attrapant >90% des problèmes systématiques.

Individual skills in this repo

This repo contains 20 individual skills — each has its own dedicated page.

accessibility

Design, implement, and audit inclusive digital products using WCAG 2.2 Level AA. Use when building or auditing UI that must meet WCAG 2.2 Level AA, or when reviewing a change for keyboard, contrast, or screen-reader support.

affaan-m/content-engine

Create platform-native content systems for X, LinkedIn, TikTok, YouTube, newsletters, and repurposed multi-platform campaigns. Use when the user wants social posts, threads, scripts, content calendars, or one source asset adapted cleanly across platforms.

affaan-m/ECC

Multi-platform content distribution across X, LinkedIn, Threads, and Bluesky. Adapts content per platform using content-engine patterns. Never posts identical content cross-platform. Use when the user wants to distribute content across social platforms.

affaan-m/fal-ai-media

Unified media generation via fal.ai MCP — image, video, and audio. Covers text-to-image (Nano Banana), text/image-to-video (Seedance, Kling, Veo 3), text-to-speech (CSM-1B), and video-to-audio (ThinkSound). Use when the user wants to generate images, videos, or audio with AI.

affaan-m/manim-video

日本語翻訳:このファイルは manim-video 用の日本語翻訳が必要です

affaan-m/remotion-video-creation

Remotion のベストプラクティス - React で動画を作成する。3D、アニメーション、音声、字幕、チャート、トランジションなどをカバーするドメイン固有の29のルール。

affaan-m/video-editing

AI-assisted video editing workflows for cutting, structuring, and augmenting real footage. Covers the full pipeline from raw capture through FFmpeg, Remotion, ElevenLabs, fal.ai, and final polish in Descript or CapCut. Use when the user wants to edit video, cut footage, create vlogs, or build video content.

agent-architecture-audit

Full-stack diagnostic for agent and LLM applications. Audits the 12-layer agent stack for wrapper regression, memory pollution, tool discipline failures, hidden repair loops, and rendering corruption. Produces severity-ranked findings with code-first fixes. Essential for developers building agent applications, autonomous loops, or any LLM-powered feature. Use when an agent or LLM feature misbehaves and the failing layer is unknown, or before shipping an agent stack.

agent-eval

Head-to-head comparison of coding agents (Claude Code, Aider, Codex, etc.) on custom tasks with pass rate, cost, time, and consistency metrics. Use when choosing between coding agents, or when a change to an agent setup needs measured pass rate, cost, and time rather than an impression.

agent-harness-construction

Design and optimize AI agent action spaces, tool definitions, and observation formatting for higher completion rates. Use when defining or revising an agent

agentic-engineering

Operate as an agentic engineer using eval-first execution, decomposition, and cost-aware model routing. Use when planning or executing engineering work that agents will carry out end to end.

agentic-os

Build persistent multi-agent operating systems on Claude Code. Covers kernel architecture, specialist agents, slash commands, file-based memory, scheduled automation, and state management without external databases. Use when building a persistent multi-agent system on Claude Code with its own memory, commands, and scheduling.

agent-introspection-debugging

Structured self-debugging workflow for AI agent failures using capture, diagnosis, contained recovery, and introspection reports. Use when an agent run fails and you need a reproducible diagnosis instead of a retry.

agent-payment-x402

Add x402 payment execution to AI agents with per-task budgets, spending controls, and non-custodial wallets. Supports Base through agentwallet-sdk and X Layer through OKX Payments / OKX Agent Payments Protocol. Use when an agent must pay for something itself and needs per-task budgets, spending controls, and a non-custodial wallet.

agent-self-evaluation

Use after completing any non-trivial task. The agent self-rates its output on 5 axes — accuracy, completeness, clarity, actionability, conciseness — with concrete evidence per criterion. Produces a structured 1-5 scorecard with specific improvement suggestions.

agent-sort

Build an evidence-backed ECC install plan for a specific repo by sorting skills, commands, rules, hooks, and extras into DAILY vs LIBRARY buckets using parallel repo-aware review passes. Use when ECC should be trimmed to what a project actually needs instead of loading the full bundle.

ai-first-engineering

Engineering operating model for teams where AI agents generate a large share of implementation output. Use when setting team process, review gates, or ownership rules for a codebase largely written by agents.

ai-regression-testing

Regression testing strategies for AI-assisted development. Sandbox-mode API testing without database dependencies, automated bug-check workflows, and patterns to catch AI blind spots where the same model writes and reviews code. Use when adding regression coverage to AI-assisted code, or when the same model both wrote and reviewed a change.

android-clean-architecture

Clean Architecture patterns for Android and Kotlin Multiplatform projects — module structure, dependency rules, UseCases, Repositories, and data layer patterns. Use when structuring modules, layers, or data flow in an Android or KMP project.

angular-developer

Generates Angular code and provides architectural guidance. Trigger when creating projects, components, or services, or for best practices on reactivity (signals, linkedSignal, resource), forms, dependency injection, routing, SSR, accessibility (ARIA), animations, styling (component styles, Tailwind CSS), testing, or CLI tooling.

Skills associés