mirac221/frame-judge

Que fait frame-judge ?

Vous n'avez pas le droit de noter votre propre travail visuel.

Vous construisez et rendez. Ensuite, un critique séparé juge ce qui est réellement apparu à l'écran par rapport à ce que l'utilisateur a réellement demandé. Le critique ne voit jamais votre code, votre raisonnement ni votre opinion du résultat. Jusqu'à ce que le travail soit accepté, ou que la limite de rounds soit atteinte, vous ne le déclarez pas terminé, poli, lisse ou beau.

Pourquoi : le modèle qui a écrit le code projette son intention sur le résultat. Il "voit" le cycle de marche qu'il voulait écrire, pas celui qui est rendu. Un critique qui ne reçoit que les pixels plus les mots de l'utilisateur ne peut pas faire cela. Il doit regarder.

<skill> ci-dessous signifie le dossier dans lequel se trouve ce fichier (dans Claude Code : ${CLAUDE_SKILL_DIR}). Les scripts sont du Node 18+ simple sans étape d'installation. Ils conservent l'état dans .frame-judge/ sous votre répertoire de travail.

La boucle

Étape	Quoi	Qui
0	Verrouiller la demande de l'utilisateur, textuellement	vous
0b	Demander "unsloppy?". Si oui, un éclaireur recherche les défauts d'IA à éviter	vous, l'utilisateur, un éclaireur
1	Construire	vous
2	Rendre et capturer : captures d'écran, feuilles de trames, traînées de mouvement	scripts
3	Auto-vérification mécanique : le rendu fonctionne, rien de vide, aucune erreur d'exécution	vous
4	Emballer un dossier de révision sans code	script
5	Demander sur quel modèle le critique tourne, si la plateforme le permet (une fois)	vous, puis l'utilisateur
6	Le critique examine le dossier	nouveau sous-agent
7	La porte valide la révision et décide	script
8	Répondre à chaque constatation de correction obligatoire, puis retour à l'étape 2	vous
9	Rapporter le verdict du critique, pas votre opinion	vous

Limite par défaut : 3 rounds de critique.

0. Verrouiller le brief

node <skill>/scripts/judge.mjs init --brief-file request.txt --kind frontend,motion

Utilisez --brief "..." pour du texte en ligne, ou --brief-file - pour lire l'entrée standard.

• Textuellement. Sauvegardez le message de l'utilisateur tel qu'écrit : fautes de frappe, majuscules, tout. Ne paraphrasez, ne résumez et ne "clarifiez" jamais. Le critique juge par rapport à leurs mots, pas par rapport à votre lecture.
• Les clarifications ultérieures de l'utilisateur sont ajoutées avec judge.mjs brief --add "<leurs mots exacts>". Vos propres hypothèses ne sont jamais ajoutées.
• Les images de référence que l'utilisateur vous a données : ajoutez --ref mock.png (répétable) pour que le critique puisse les comparer.
• --kind choisit les grilles : frontend pour les pages et l'interface utilisateur, motion pour toute animation, video pour les clips et montages. Omettez-le pour une détection automatique à partir des captures.
• --critic-model si l'utilisateur a déjà nommé un modèle.

Ceci crée .frame-judge/ (il s'ajoute à git-ignore) avec brief.md et ledger.json. Le registre survit à la compaction du contexte. Si vous perdez la trace, exécutez judge.mjs status.

0b. Demander le mode unslop (avant de construire)

Demandez à l'utilisateur une fois, avec ces mots :

Voulez-vous un travail non bâclé (unsloppy) ? (expérimental : peut diminuer la qualité et dépensera plus de tokens)

Sur Claude Code, demandez avec AskUserQuestion, dans le même prompt que la question sur le modèle du critique de l'étape 5. Ailleurs, demandez dans le chat. Passez si l'utilisateur a déjà répondu.

• Non : continuez. Unsloppy est désactivé par défaut.
• Oui :
  1. Exécutez judge.mjs set unslop on, puis judge.mjs scout. Cela imprime un message pour un éclaireur slop : un nouveau sous-agent avec recherche web qui découvre comment les IA font généralement des erreurs sur ce type de demande.
  2. Envoyez ce message à l'éclaireur et rien d'autre. Les mêmes règles que pour le critique s'appliquent : agent frais, pas de fork, rien ajouté. Utilisez le modèle du critique s'il est défini.
  3. Sauvegardez sa réponse, puis exécutez judge.mjs avoid --file <reply>. Cela rejette les listes sans sources réelles.
• Pas de recherche web disponible : dites à l'utilisateur que unslop ne peut pas fonctionner ici, et continuez sans.

La liste d'évitement atterrit dans .frame-judge/avoid.md, et elle est incluse dans chaque dossier de révision, donc le critique vérifie aussi le travail par rapport à celle-ci.

"Expérimental" car s'éloigner des valeurs par défaut peut pousser une construction vers des choix étranges, et l'éclaireur coûte un tour d'agent supplémentaire avec des recherches web.

1. Construire

Si unslop est activé, lisez d'abord .frame-judge/avoid.md.

• Concevez autour de chaque motif. Ne vous contentez pas de l'inverser : le but est un travail qui correspond au brief, pas un travail qui est simplement différent.
• Tout ce que l'utilisateur a explicitement demandé prime sur la liste.

Avant de construire, lisez la section de references/craft.md pour votre médium, une fois par session. Elle couvre ce que les critiques signalent le plus : espacement, typographie, signes de template IA, easing, cycles de marche, rythme vidéo.

Pour tout ce qui est animé, faites du temps une entrée explicite : une ligne de temps que vous pouvez parcourir, ou un hook window.frameJudgeSeek(ms). Cela rend la capture image-exacte, et cela transforme le HTML en vidéo gratuitement.

2. Rendre et capturer

Pages et UI (nécessite Playwright ; configuration dans references/capture.md) :

node <skill>/scripts/capture-page.mjs http://localhost:5173 --out .frame-judge/cap/page

Les valeurs par défaut sont desktop 1440×900, tablette 768×1024 et mobile 390×844, capturées écran par écran. Options :

• --actions states.json pour les états de survol, de menu et d'erreur
• --color-scheme dark
• --reduced-motion
• les fichiers locaux fonctionnent aussi bien que les URLs

Animation sur une page. Ceci est image-exacte (horloge simulée plus recherche d'animations Web) et encode en MP4 :

node <skill>/scripts/capture-page.mjs scene.html --out .frame-judge/cap/anim --animate 3000 --fps 30 --selector "#hero"

N'importe quelle vidéo, y compris ce MP4 :

node <skill>/scripts/video-frames.mjs .frame-judge/cap/anim/animation.mp4 --out .frame-judge/cap/anim-views --as motion

Ce que vous obtenez :

• Tranches de fenêtre au lieu d'une seule image pleine page géante, qui serait réduite en bouillie.
• Instantanés d'état à partir de votre fichier d'actions.
• Une planche contact horodatée.
• Films fixes : trames échantillonnées à 12 images par seconde par défaut, plus des bandes à pleine vitesse autour de tout saut ou blocage soudain détecté par le script (--motion-fps source donne chaque image partout). L'échantillonnage signifie qu'un défaut d'une seule image peut tomber entre les tuiles, d'où l'existence de la détection d'événements.
• Traînées de mouvement : ce qui doit rester immobile reste net, et ce qui glisse s'étale.
• Chiffres objectifs : durée, images par seconde, segments noirs ou gelés, débordement horizontal, images cassées.

Capturez ce que l'utilisateur vivra : chaque fenêtre qu'il utiliserait, les états qui comptent, l'animation entière. Le critique ne peut pas signaler ce que vous ne lui avez pas montré. Omettre les parties laides est exactement la tricherie que ce skill existe pour empêcher.

3. Auto-vérification mécanique

Avant de dépenser un round de critique, vérifiez et corrigez les choses binaires :

• le rendu fonctionne
• pas d'images vides ou noires
• rien dans builder_only dans chaque capture.json (erreurs console, requêtes échouées)
• la bonne durée et la bonne taille
• horizontal_overflow_px et broken_images sont à zéro

C'est toute la liste. Vous n'avez pas le droit de décider que ça a l'air bien et de sauter le critique.

4. Emballer

node <skill>/scripts/judge.mjs bundle .frame-judge/cap/page .frame-judge/cap/anim-views

Ceci écrit .frame-judge/round-N/bundle/. Il contient uniquement des fichiers visuels (png, jpg, webp, gif, plus la vidéo si vous passez --include-video) et ces fichiers texte :

• brief.md, avec les blocs de code supprimés
• les grilles d'évaluation
• CRITIC.md, les instructions du critique
• manifest.json, avec les IDs d'artefacts pouvant être cités
• prior.json, à partir du round 2 : constatations ouvertes sans vos affirmations "corrigé", afin que le critique vérifie par lui-même

Le script n'ouvrira pas un nouveau round tant que les constatations de correction obligatoire sont sans réponse, ou passé la limite de rounds. Il imprime le message exact à envoyer au critique.

Budget d'images : visez 20 images ou moins par round. Claude resserre les limites par image au-delà de 20 images dans une seule requête. Chaque image coûte environ ⌈l/28⌉×⌈h/28⌉ tokens ; une capture 1440×900 représente environ 1,7k. Les planches contact et les films fixes regroupent 12 à 16 images en une seule, alors appuyez-vous sur elles. --slices 3 réduit les longues pages.

5. Choisir le modèle du critique (uniquement là où la plateforme le supporte)

Demandez uniquement si votre plateforme vous permet de choisir le modèle d'un sous-agent, et une seule fois, avant le round 1. Passez si l'utilisateur en a déjà nommé un. Sauvegardez la réponse avec judge.mjs set critic-model <alias> et réutilisez-la à chaque round.

Plateforme	Demander ?	Comment
Claude Code, applications Claude	Oui	AskUserQuestion, dans le même prompt que la question unslop : Sonnet (équilibré, recommandé), Opus (œil le plus affûté, le plus de quota), Haiku (le moins cher, manque les problèmes subtils), Le même que moi
Application Codex, Codex CLI	Oui	Demandez dans le chat, puis passez le choix lorsque vous générez le critique
Antigravity	Non	Il n'y a pas de choix de modèle par génération. Le critique tourne sur le réglage de son fichier d'agent ; dites-le à l'utilisateur.
Autre chose	Non	Sauf si cela supporte clairement les modèles par sous-agent. Utilisez la valeur par défaut et dites à l'utilisateur quel modèle a révisé le travail.

Lorsque vous demandez, soyez honnête sur le compromis. Un critique plus faible est moins cher, mais il hallucine plus de défauts et en manque de subtils. La porte attrape les fausses preuves ; elle ne peut pas attraper le mauvais goût.

Syntaxe exacte par plateforme : references/platforms.md.

6. Exécuter le critique

Utilisez un critique frais à chaque round, afin qu'il n'ait aucune mémoire au-delà de prior.json et aucun intérêt dans ses appels précédents. Envoyez-lui le message que bundle a imprimé, et rien d'autre :

Vous êtes le critique d'images. Votre dossier est <chemin abs>. Lisez <chemin abs>/CRITIC.md et suivez-le exactement. N'ouvrez rien en dehors de ce dossier. Répondez uniquement avec le JSON de révision.

• N'ajoutez rien. Pas de résumé de ce que vous avez construit, pas de "concentrez-vous sur l'en-tête", pas de "j'ai corrigé les jambes". Votre opinion est la seule entrée que le critique ne doit jamais recevoir. Si l'utilisateur veut que quelque chose soit vérifié, c'est déjà dans le brief, dans ses mots.
• Pas de forks. N'exécutez jamais le critique en tant que fork ou quoi que ce soit d'autre qui hérite du contexte. Il verrait toute votre conversation, code compris.
• Préférez l'agent installé. Utilisez frame-critic s'il existe, car il est limité à la lecture de fichiers. Son nom est frame-judge:frame-critic lorsque le skill est arrivé en tant que plugin Claude Code, et frame_critic dans Codex. Sinon, utilisez un sous-agent à usage général avec le même message.
• Claude Code : exécutez le bac à sable si vous le pouvez. Si le CLI claude est dans le PATH, exécutez node <skill>/scripts/critic-sandbox.mjs au lieu de générer un sous-agent. Il exécute le critique comme un processus séparé sans tête sur une copie privée du dossier. Ce processus n'a que l'outil Read, plus un hook qui bloque toute lecture en dehors de la copie, et le script contrôle la révision lui-même (passez l'étape 7). C'est le seul chemin où l'aveuglement au code est imposé plutôt que demandé.
• Partout ailleurs : utilisez le sous-agent dans la session, et l'aveuglement au code repose sur les instructions du critique. Sur Claude Code, l'audit de transcription à l'étape 7 attrape toujours un critique qui a jeté un coup d'œil. Dans Codex, Antigravity et Cursor, rien ne le vérifie, alors dites-le dans votre rapport.

Sauvegardez la réponse, inchangée, dans .frame-judge/round-N/review.json.

7. Porte

node <skill>/scripts/judge.mjs gate --review .frame-judge/round-N/review.json --reviewer subagent --transcript auto

Sur Claude Code, --transcript auto trouve la transcription du sous-agent critique, afin que la porte compte les images qu'il a réellement ouvertes (pas celles qu'il prétend) et annule la révision s'il a touché à quoi que ce soit en dehors du dossier. Ailleurs, laissez le drapeau de côté ; la couverture est alors auto-déclarée, et le rapport le dit. (critic-sandbox.mjs passe sa propre transcription automatiquement.)

La porte décide, pas l'humeur du critique et pas vous. Elle :

• Rejette les constatations qui citent des ID d'artefacts qui n'existent pas ou que le critique n'a jamais ouverts, les constatations sans preuve, les citations du brief qui ne sont pas dans le brief, et les mauvaises valeurs de sévérité ou de confiance.
• Vérifie la couverture : une réussite ne compte que si le critique a ouvert chaque image, vérifié à partir de sa transcription là où elle existe, sinon à partir de sa propre liste opened.
• Vérifie l'isolement : avec une transcription, toute lecture en dehors du dossier annule la révision (RERUN_CRITIC).
• Trie le reste :
  • must-fix : bloquant ou majeur, confiance 0,6 ou plus
  • verify : bloquant ou majeur en dessous de 0,6. Recadrez plus près ; ne corrigez pas à l'aveugle.
  • polish : mineur
  • ignored : broutilles
• Vérifie que CRITIC.md et les grilles d'évaluation n'ont pas été modifiés, afin que personne n'ait adouci le juge.
• Met à jour le registre et imprime une décision :

Décision	Signification	Vous
PASS	Plus de must-fix, rien du brief manquant	Rapport (étape 9)
SELF_PASS	Idem, mais d'un repli d'auto-révision	Rapport, et dites que ce n'était pas indépendant
REVISE	Des éléments must-fix existent	Étape 8, puis un nouveau round
RETHINK	Le critique dit que l'approche est fondamentalement erronée	Dites-le à l'utilisateur avant de reconstruire
STOP_MAX_ROUNDS	Limite atteinte, échoue toujours	Rapportez ce qui est ouvert, demandez s'il faut continuer
STOP_PLATEAU	Ce round n'a rien résolu	Arrêtez de tourner en rond. Rapportez, demandez
RERUN_CRITIC	Révision inutilisable (pas de JSON, preuves en grande partie fausses), une réussite d'un critique qui a sauté des images, ou un critique qui a lu en dehors de son dossier	Exécutez un nouveau critique sur le même dossier
STOP_CRITIC_UNRELIABLE	Deuxième révision inutilisable	Suggérez un modèle de critique plus fort ou un repli

8. Réviser

Travaillez sur les éléments must-fix par ID, bloquants en premier. Répondez à chacun avant le round suivant :

node <skill>/scripts/judge.mjs respond R1-F2 fixed "pied de contact planté pendant 4 trames"
node <skill>/scripts/judge.mjs respond R1-F4 disputed "les gouttières sont égales des deux côtés" --evidence crop.png
node <skill>/scripts/judge.mjs respond R1-F6 wont-fix "l'utilisateur a demandé ce dégradé" --quote "dégradé violet à bleu"

• disputed nécessite une preuve visuelle, comme un recadrage ou des trames supplémentaires. Elle va dans le dossier suivant et le prochain critique statue dessus. "Le CSS dit 16px" n'est pas une preuve ; les pixels le sont.
• wont-fix nécessite une citation textuelle du brief que la correction violerait.
• Corrigez les causes, pas les captures. Ne modifiez jamais la capture pour éviter une constatation : pas de recadrage du pied de page cassé, suppression de la fenêtre mobile ou rognage du clip.
• Éléments Verify et demandes du critique : capturez ce point plus précisément (une action avec clip, une fenêtre --motion plus dense) afin que le prochain critique puisse confirmer ou les tuer.
• Ne régressiez pas ce que le critique a listé sous keep.

…

[Le reste du contenu original après le point 8 n'est pas fourni pour la traduction.]