La Gueznet IA n°10

# Règles du studio motion

## Contrat de rendu
- Chaque film est une fonction pure du temps : `window.seek(t)` peint l'image t.
- Pas de transitions CSS, pas de setTimeout, pas de requestAnimationFrame en mode rendu,
  aucun état transmis d'une image à l'autre. Bruit à graine uniquement (mulberry32), jamais Math.random.
- Rendu avec `node render.mjs`, encodage H.264 yuv420p, CRF 16.

## Rendu visuel
- Défauts bannis : titre centré sur un dégradé, tout qui apparaît en fondu,
  étiquettes dans les coins et cadres autour de l'image, halo sur l'habillage de l'interface, explosions de particules génériques.
- Une police de titrage, une police d'interface. Une seule couleur d'accent sauf si le brief dit autrement.
- Toutes les 2 à 4 secondes, quelque chose de nouveau doit se passer à l'écran.

## Son
- La musique et les bruitages sont synthétisés dans le code, sauf si une piste est fournie.
- Place les impacts sur la grille de temps mesurée (beats.json). Volume -14 LUFS.

## La boucle avant de me montrer quoi que ce soit
1. Fais le rendu d'une image par temps sous forme de planche contact et REGARDE-la.
2. Note-la de 1 à 10 sur : accroche dans les 2 premières secondes, lisibilité sur écran de téléphone,
   qualité du mouvement, variété, fidélité à la marque, synchro du son.
3. Corrige les 3 pires problèmes. Recommence jusqu'à ce que chaque note soit à 8 ou plus.
4. Seulement alors, fais le rendu complet.

fais une vidéo motion design dynamique de 15 secondes qui montre quel incroyable motion designer tu es, comme si c'était ta bande démo pour un CV. donne tout.

fais une bande démo motion design dynamique en 16:9 de 60 secondes qui montre tes vraies limites créatives.
Sound design de niveau S, pas de nappes de synthé génériques. Compose une musique originale au piano et cale chaque coupe dessus. Exporte en MP4 1080p.

fais une vidéo motion design dynamique de 10 secondes qui présente qui tu es en tant qu'Opus 5.5.
Évite les cadres et le texte dans les coins, les signes habituels d'une vidéo faite par IA.

reprends l'énergie de ta bande démo, mais raconte une histoire : l'histoire de [SUJET] de [DÉBUT] à aujourd'hui,
surprends-moi avec le storyboard. 45 secondes, vertical 9:16.

fais une bande démo de 30 secondes comme si tu étais un studio de branding de niche pour fondateurs de startups.
Crée chaque élément graphique de zéro. Une seule couleur d'accent. Chaque plan utilise une technique différente.

Fais une vidéo motion design dynamique de 20 secondes pour [PRODUIT] ([URL]), avec l'énergie
de la bande démo d'un motion designer. Donne tout.

Ressources
- Va sur le site. Utilise de vraies captures d'écran (Playwright), le vrai logo, les vraies couleurs et polices.
  Enregistre tout dans ./assets et liste ce que tu as trouvé avant d'animer.
- Ne redessine jamais l'interface du produit en l'imaginant. Recadre et anime la vraie.

Histoire (un temps fort chacun, 2 à 4 secondes)
1. Accroche : le problème en 5 mots de typographie cinétique énorme.
2. Le produit apparaît, l'interface s'assemble pièce par pièce.
3. Trois fonctionnalités, chacune comme un moment d'interface avec un curseur qui fait une vraie action.
4. Un chiffre qui prouve que ça marche : [INDICATEUR].
5. Bloc logo final + [APPEL À L'ACTION].

Son
- Musique originale, 120 BPM, synthétisée dans le code. Clics d'interface et « whoosh » sur le temps.

Format : 1080x1920 (9:16) d'abord, puis 1:1 et 16:9 depuis la même timeline.
Avant le rendu complet, montre-moi une planche contact avec une image par temps.

Référence : ./refs/launch.mp4 (et ./refs/frames/*.png)

1. Extrais une image toutes les 0,5 s avec ffmpeg. Étudie-les.
2. Écris ./docs/style_guide.md : palette (hex), typographie (famille, graisse, approche),
   durée des plans, types de transitions, mouvements de caméra, texture et grain, façon dont le texte entre et sort.
3. Écris ./docs/shotlist.md pour une vidéo de [DURÉE] s sur [SUJET] dans CE style.
   Prends la grammaire de la référence, jamais son contenu, ses logos ni ses personnages.
4. Montre-moi les deux fichiers. Attends mon accord avant d'écrire du code.

<inputs>
Demande-moi : mon produit + URL, 8 à 12 états d'interface qui racontent son histoire, les vraies données affichées dans
chaque état, couleurs + polices de la marque + un accent, une piste libre de droits autour de 120 BPM, les formats.
</inputs>

<direction>
Motion d'interface façon film produit. Un seul conteneur, jamais coupé : chaque état est le même élément qui change
de taille, d'arrondi et de remplissage pendant que son contenu change derrière un bref flou. Un curseur déclenche chaque changement.
Fond neutre chaud, un seul accent. Ressorts avec au plus un tout petit dépassement.
Interdits : easing rebondissant, halos, dégradés sur l'habillage de l'interface, explosions de particules, temps morts.
</direction>

<structure>
120 BPM, 8 mesures, il se passe quelque chose sur chaque temps.
logo → bouton d'appel à l'action → champ e-mail (saisi) → chargement → coche de réussite → carte du tableau de bord
→ le graphique se dessine tout seul → infobulle au survol → palette ⌘K → notification → logo.
</structure>

<build>
1. Un seul fichier HTML, un seul canvas, window.seek(t). Pas de transitions CSS, pas de minuteries, pas d'état transmis.
2. Ressorts en forme close. Une valeur avec plusieurs cibles = somme d'un ressort par changement.
3. Le texte dans un conteneur qui se transforme entre après le début de la transformation, et sort avant la suivante.
4. Indicateurs d'onglet : bord avant et bord arrière sur des ressorts différents, pour qu'ils s'étirent.
5. Grille de temps tirée de la piste (numpy/librosa). Démarre sur un premier temps de mesure. Sons d'interface sur les pics mesurés.
6. Rendu dans Chrome headless à 60 i/s, 4 sous-images par image, fusionnées pour le flou de mouvement.
</build>

<gotchas>
N'utilise jamais will-change sur un élément que la caméra met à l'échelle (texte flou).
La dernière image doit être identique à la première, position et vitesse du curseur comprises.
</gotchas>

<start>
Demande les éléments d'entrée, puis montre-moi la liste des états sur la grille de temps avant d'écrire du code.
</start>

/remotion-create un film de lancement de 20 s en 9:16 pour [PRODUIT], uniquement des ressorts, une seule couleur d'accent

Avec /hyperframes, transforme ./notes.md en vidéo de présentation de 45 secondes avec sous-titres cinétiques

Remplace chaque courbe d'easing par les ressorts en forme close de lib/motion.js. Tout petit dépassement sur l'interface, aucun sur le texte. Toute valeur qui a plus d'une cible utilise track().

Tu es le réalisateur, l'animateur, le sound designer et l'ingénieur de rendu d'un film de [DURÉE]
fait en code. Traite-le comme une production en plusieurs sessions. Ne te précipite pas vers un rendu final.

## Le film en une ligne
[PITCH EN UNE PHRASE. Ce que le spectateur doit ressentir à la fin.]

## Références et entrées
- ./refs/ : [vidéo / images / bibliothèque d'images]. Prends la grammaire, jamais le contenu.
- ./audio/track.wav : utilise-la telle quelle. Mesure d'abord les temps avec beats.py.
- Skills disponibles : [/remotion-best-practices | /hyperframes | /claude-animation].
- API dans .env : [ELEVENLABS_API_KEY, FAL_KEY]. Budget : [X $]. Sois économe.

## Rendu visuel
[3 à 5 lignes : palette, typographie, texture, langage de caméra. Rendus interdits.]

## Découpage par temps forts
0:00-0:02  accroche : [l'image la plus frappante]
0:02-0:10  [acte 1]
...        un nouveau temps fort visuel toutes les 3 à 5 secondes
[FIN]      la dernière image prépare la première (boucle)

## Déroulé, avec étapes de validation
1. Écris docs/style_guide.md et docs/shotlist.md (chaque plan : images, caméra, texte, bruitages).
   Montre-moi la liste des plans. Puis continue sans attendre si je ne réponds pas dans les 10 minutes.
2. Construis des images fixes pour chaque plan. Planche contact. Critique.
3. Animatique en 960x540 avec un son provisoire. Corrige le rythme avant la finition.
4. Animation complète, passe de finition, passe son, rendu final.
5. Répartis le travail entre des sous-agents, un par chapitre. Écris d'abord docs/ANIMATION_GUIDE.md
   pour que chaque sous-agent code dans le même style.

## Boucle de critique (chaque plan, au moins 3 tours)
Fais le rendu de 3 à 5 images fixes, note de 1 à 10 : accroche, lisibilité à 360 px de large, mouvement, composition,
profondeur, synchro du son, finition. Consigne les notes + les 3 plus gros problèmes dans docs/review_log.md. Corrige. Recommence
jusqu'à ce que tout soit à 8 ou plus.

## Livrables
out/final.mp4 · out/loop_check.mp4 · out/poster.png · out/contact.png · README.md

Ouvre out/contact.png, out/strip.png et out/phone.png et regarde-les vraiment.
Sois un directeur motion exigeant, pas un auteur fier de lui.

Note de 1 à 10 : accroche dans les 2 premières secondes · lisibilité sur téléphone · qualité du mouvement (ressorts,
pas d'images mortes) · variété (du nouveau toutes les 2 à 4 s) · composition · fidélité à la marque · synchro du son.

Liste les 3 plus gros problèmes avec leur minutage. Cherche en particulier : du texte qui se chevauche pendant
les changements, tout ce qui glisse au lieu de s'amortir, les étiquettes dans les coins et les cadres, les plans centrés sur un dégradé,
le texte flou mis à l'échelle, un temps mort où rien ne se passe, un à-coup au raccord de la boucle.

Corrige-les, refais le rendu des seules secondes concernées, montre-moi la nouvelle planche contact et les nouvelles notes.

---
name: motion-reel
description: Fait une vidéo motion design de produit ou une bande démo rendue à partir de code. À utiliser quand
  l'utilisateur demande une vidéo de lancement, une bande démo, une vidéo produit, une vidéo explicative animée ou une pub animée.
---

# Motion reel

## Éléments à réunir d'abord
Produit + URL, durée, formats (9:16 / 1:1 / 16:9), couleurs + polices de la marque,
une référence (image, vidéo ou dossier d'images), la musique (fichier ou « synthétiser »).

## Chaîne de production
1. Récupère les ressources depuis l'URL avec Playwright dans ./assets. Liste-les.
2. S'il y a une référence, écris docs/style_guide.md à partir d'elle.
3. Mesure ou synthétise la musique. beats.py → beats.json.
4. Écris docs/shotlist.md sur la grille de temps. Montre-la et attends mon accord.
5. Construis index.html avec window.seek(t) en utilisant les ressorts de lib/motion.js. Suis CLAUDE.md.
6. Planche contact → passe de critique (voir prompts/critique-pass.txt) → correction. 3 tours minimum.
7. node render.mjs → sfx.mjs → mixage à -14 LUFS → out/final.mp4, tous formats.
8. Livre final.mp4, contact.png, poster.png. Dis ce que tu améliorerais ensuite.

## Règles strictes
- Uniquement la vraie interface du produit. N'invente jamais d'écrans.
- Pas de Math.random, pas de minuteries, pas de transitions CSS en mode rendu.
- Interdits : étiquettes dans les coins, titre centré sur un dégradé, tout qui apparaît en fondu.

/motion-reel pour [URL], 20 s, vertical, référence ./refs/frame.png

fonction pure de l'image : pas de minuteurs, pas de transitions CSS, pas d'aléatoire sans graine
la boucle se referme : chaque mouvement répété divise la durée de la boucle, pour que la dernière image s'enchaîne sur la première sans saut
la couleur a un rôle : le noir et blanc fait la surface, la couleur ne va que là où elle a un sens. sur mes pièces Grok Bot, ce sont les agents et rien d'autre
données réelles seulement : chaque étiquette remonte à une source. pas de chiffres inventés, pas d'interface imaginée
rien ne part sans contrôle : aucun rendu ne sort tant que les contrôles ci-dessous ne reviennent pas propres

ne déclare jamais une modification d'interface terminée sur la seule foi de l'édition. ouvre la page, utilise la modification, fais une capture avant et après, vérifie la console pour de nouvelles erreurs, lance une trace de performance, et si une étape échoue, corrige et recommence.

/goal Refactorise la couche de récupération des données jusqu'à ce que le score de performance Lighthouse soit >= 92 et le LCP < 1,8 s dans la sortie de Lighthouse CLI.
Ne change l'API publique d'aucun hook. Chaque tour doit améliorer une métrique ;
abandonne après deux tours sans amélioration. Arrête-toi après 10 tours.

/loop every 24h "Vérifie sur GitHub les tickets étiquetés 'bug'. S'il y en a un,
utilise /goal pour implémenter un correctif jusqu'à ce que tous les tests locaux passent, et pousse la branche."

/goal Le test de fumée affiche zéro sur les six compteurs et l'image 0 correspond
à l'image 720 au pixel près. Corrige le pire échec à chaque passe.
Abandonne si une passe ne corrige rien. Arrête-toi après 5 passes.

Ajoute du son à cette vidéo. Tu ne peux pas entendre, alors mesure chaque étape et ne te fie pas à ton intuition. Installe d'abord ffmpeg et librosa s'ils manquent.
1. Utilise de la musique sous licence : une piste que je te donne, ou une piste sous la licence gratuite de Mixkit. Note la source et la licence. Ne synthétise ni la musique ni les effets sonores en code.
2. Trouve les temps avec librosa. Il se cale parfois sur le contretemps, alors trace la forme d'onde sous 120 Hz face à la grille des temps et zoome sur quelques mesures. Si les grosses caisses ne tombent pas dessus, décale toute la grille.
3. Place les grands mouvements, comme les changements de scène et l'apparition des titres, sur le temps. Si tu peux modifier l'animation, modifie-la. Sinon, déplace le point de départ de la musique.
4. Donne à chaque coupe et à chaque grand mouvement un fichier d'effet sonore tout prêt : whoosh pour un mouvement, pop pour une apparition, clic pour les clics, bruits de frappe pour la saisie. Utilise d'abord la sonothèque existante du projet, comme celle fournie avec HyperFrames, et demande-moi s'il n'y en a pas.
5. S'il y a une voix off, c'est l'élément le plus fort, et la musique baisse quand quelqu'un parle. Les effets sonores passent au-dessus de la musique. Vise environ -16 LUFS au global avec des crêtes sous -4 dBFS, pour que rien ne sature après la compression AAC ou sur un haut-parleur de téléphone en mono. Mesure le MP4 exporté avec ebur128 de ffmpeg. Ne mesure pas le WAV.
6. Avec ffmpeg, extrais une image avant et après chaque repère du MP4 exporté, et trace une forme d'onde pour comparer. Puis choisis 5 instants que je vérifierai au casque. Ne me dis pas que ça sonne bien.

Lis ce guide : https://support.claude.com/en/articles/17454997-get-started-with-claude-motion

Puis suis la démarche de Claude Motion et parcours le README de ce projet, sa page d'accueil, son parcours de prise en main, ses dernières notes de version et tous les graphiques qu'il contient. Trouve trois sortes de choses qui méritent d'être transformées en animation :
1. Un enchaînement qu'une seule capture d'écran ne peut pas expliquer, comme les étapes que suit un nouvel utilisateur pour démarrer.
2. Un changement qui tombe à plat sous forme de simple chiffre, comme la vitesse de la nouvelle version comparée à l'ancienne.
3. La nouvelle fonctionnalité de la dernière version qui mérite le plus d'être montrée.
Si le projet n'a pas l'une de ces choses, dis-le simplement. Ne force pas.

Pour chaque idée, suis le guide : dis à qui elle s'adresse, où elle sera diffusée et combien de temps elle dure, puis écris un storyboard avec la durée en secondes de chaque scène et les mots, chiffres et captures d'écran qui apparaissent à l'écran. N'utilise que du contenu réel du projet. Classe les idées selon leur utilité pour moi.

Une fois que j'en ai choisi une, construis-la sous forme d'animation en code avec HyperFrames (installe-le d'abord s'il n'est pas installé), avec tous les textes, chiffres et durées regroupés à un seul endroit. Plus tard, quand je dirai « ralentis la deuxième scène » ou « change ce chiffre en 18 % », ne modifie que cette chose-là. Fais d'abord un rendu de brouillon, extrais une image par seconde et passe-les en revue, corrige les problèmes, puis exporte un MP4 en 1080p.

Montre-moi d'abord les storyboards. Ne construis rien tant que je n'ai pas choisi.

Astuce Claude Code : avant de publier sur X une vidéo réalisée par Opus 5.5, fais-lui envoyer 3 sous-agents relecteurs qui signalent les problèmes, horodatage à l'appui, selon ces 9 contrôles, et qu'il ne te l'apporte qu'une fois que les 3 lui donnent 7 ou plus.

Ouverture
→ Quand X lance une vidéo en lecture automatique, l'image 0 sert de vignette. Est-ce qu'elle s'ouvre sur un écran vide, une image noire ou quelque chose encore en fondu d'entrée ?
→ Regarde les 3 premières secondes sans le son. Est-ce qu'on comprend de quoi il s'agit ?

Image
→ Ne relis que des images extraites du MP4 exporté. Ce qui semble correct dans l'aperçu peut disparaître au rendu.
→ Enregistre une démo qui fait des allers-retours sur une page, et la moitié de ce que tu captures se lit à l'envers. Chaque extrait que tu montes se lit-il vers l'avant ?
→ Y a-t-il au milieu une image noire ou un fondu au noir qui fait croire que c'est fini ?
→ La dernière image ramène-t-elle à la première ? X lit les vidéos en boucle.

Contenu
→ Chaque sous-titre et chaque nombre correspondent-ils au matériau source ? Une affirmation comme « le premier » a-t-elle une source ?
→ Des sous-titres ou des informations clés se trouvent-ils dans les 8 % du bas ? Le lecteur mobile de X couvre cette bande.
→ Réduis à la largeur d'un téléphone. Peux-tu encore lire le texte ?

Lance les 3 sur Opus 5.5 en effort élevé. Après chaque série de corrections, fais relire la nouvelle version par le même sous-agent. Il se souvient de ce qu'il a signalé au tour précédent et vérifie ces points en premier.

Si la session principale met plus de 5 minutes à corriger et à refaire le rendu, le cache des sous-agents expire. Quand ils reprennent, chaque image des tours précédents est retraitée de zéro, et ça pèse davantage sur tes limites d'utilisation. Le prompt donne donc à chacun un cache d'une heure.

Crée 3 sous-agents relecteurs dans ~/.claude/agents, un pour chaque groupe ci-dessus : hook-reviewer, motion-reviewer et content-reviewer. Utilise model opus et effort high, et ne leur donne que Read, Glob et Grep. Ils relisent et ne modifient jamais rien. Dans le frontmatter de chacun, écris experimental: et mets cacheTtl: 1h sur la ligne suivante, en retrait. Si mon Claude Code est plus ancien que 2.1.248, ou si subagentPromptCacheTtl est défini dans mes réglages, dis-le-moi d'abord.
La première fois, demande-moi où se trouve le projet vidéo et quel MP4 est le dernier export. Installe d'abord ffmpeg ou Pillow si l'un des deux manque.
Ensuite, chaque fois que j'exporte une vidéo :
1. Extrais des images du MP4 exporté et inscris sur chacune son horodatage (si ffmpeg n'a pas drawtext, utilise Pillow). hook-reviewer reçoit l'image 0 et les images des 3 premières secondes. motion-reviewer reçoit des planches-contact à 4 images par seconde, plus la première et la dernière image. content-reviewer reçoit une image en taille réelle pour chaque sous-titre, une série à la largeur d'un téléphone, et les chemins du script des sous-titres et du matériau source.
2. Liste les problèmes sous la forme « temps · P0/P1/P2 · problème · correctif », et que chacun termine par une note de 1 à 10.
3. Corrige d'abord les P0, puis les P1, refais le rendu, et enregistre-le comme nouvelle version (v1, v2…). Enregistre les problèmes, les notes et les ID d'agent des 3 sous-agents de chaque tour dans un dossier review/.
4. Utilise SendMessage avec chaque ID d'agent pour faire relire la nouvelle version par le même sous-agent. N'en lance pas de nouveaux. Ils vérifient d'abord les problèmes du tour précédent. Dès que les 3 donnent 7 ou plus, ou après 3 tours de relecture, arrête et remets-la-moi. Lance de nouveaux sous-agents pour la vidéo suivante.
Montre-moi d'abord les fichiers que tu vas créer, et ne les écris pas tant que je n'ai pas confirmé.

Configure mon espace de travail Claude Code pour une orchestration hiérarchique avec conseiller :

1. Audite ~/.claude/settings.json et la configuration du projet pour trouver les rôles de modèle adaptés au rôle principal, aux sous-agents et au conseiller :
> Fixe le modèle de la session principale : sonnet avec effortLevel: high pour l'exécution principale
> Fixe le modèle des sous-agents : haiku avec effortLevel: medium pour la découverte de fichiers en parallèle et la récupération de documentation
> Fixe le modèle du conseiller : opus en astreinte pour la revue stratégique

2. Active l'outil conseiller dans ~/.claude/settings.json :
> Règle advisorModel sur claude-opus-5-5
> Active le pool de répartition parallèle des sous-agents (3 workers)

3. Configure des points de consultation automatique du conseiller dans ~/.claude/CLAUDE.md :
> Consulte /advisor opus avant de finaliser un plan d'architecture qui touche plusieurs fichiers
> Appelle automatiquement /advisor opus quand le même test ou la même erreur de compilation échoue deux fois
> Impose un audit du diff par le conseiller, au regard du contrat, avant de déclarer une tâche terminée ou de préparer un commit git

4. Restreins le périmètre des sous-agents :
> Les sous-agents Haiku renvoient uniquement des résumés AST structurés et des extraits de documentation, sans modifier le contexte de la session principale

Montre d'abord chaque diff de configuration. N'applique aucune modification avant confirmation

# Contrat d'exploitation du projet

## Limites d'intervention
- Périmètre autorisé : ne modifie que les fichiers explicitement assignés dans la tâche en cours
- Actions interdites : ne supprime jamais de tests existants, n'ajoute jamais de dépendances non vérifiées

## Carte du projet
- /src : code source de l'application
- /tests : suites de tests de validation
- /docs/decisions.md : journal durable des choix d'architecture acceptés

## Protocole de vérification
Avant de marquer une tâche comme terminée, lance ces contrôles dans l'ordre :
1. Lance le linter local : `npm run lint`
2. Lance la suite de tests : `npm test`
3. Vérifie que le format de sortie correspond au schéma demandé

## Escalade en cas d'échec
Si un test échoue deux fois sur la même erreur :
- Arrête les modifications autonomes
- Affiche le journal d'erreur exact
- Énonce le correctif proposé et attends la confirmation de l'utilisateur

Rédige la spécification technique de [Fonctionnalité X].
Respecte les contraintes listées dans HARNESS.md.
N'évalue pas encore ta propre production.
Livre le brouillon brut et énonce toutes les hypothèses que tu as faites.

Relis le brouillon ci-dessus en relecteur senior sceptique.
Vérifie ces points de défaillance précis :
1. Les cas limites sont-ils gérés quand les tableaux en entrée sont vides ?
2. La logique introduit-elle des dépendances supplémentaires ?
3. La solution viole-t-elle une contrainte de HARNESS.md ?

Liste chaque point de défaillance trouvé.
Puis livre la version révisée qui comble ces manques.

/claude-api prompt-audit

## 7. Commence par ce dont tu as besoin de ma part
Quand une longue tâche est terminée, ou que tu es bloqué et as besoin que je fasse quelque chose, liste ce dont tu as besoin de ma part tout en haut de ta réponse. Un seul point par élément, numérotés. Précise ce que je dois faire, où, et ce que je dois te renvoyer quand j'ai fini, par exemple « Connecte-toi à Stripe, exporte le CSV des remboursements de septembre, mets-le dans inbox/ ». Ce qui te bloque le plus passe en premier. Si tu n'as besoin de rien de ma part, dis-le simplement.

Lis cette doc, ainsi que les docs sur les sous-agents vers lesquelles elle renvoie, et règle mes durées de cache selon la tâche :
1. Lance d'abord claude --version. Régler cacheTtl sur un seul sous-agent demande la 2.1.248 ou une version plus récente. Si la mienne est plus ancienne, dis-le-moi. Ne la mets pas à jour toi-même.
2. Liste chaque sous-agent dans ~/.claude/agents et .claude/agents. Pour ceux qui peuvent rester inactifs plus de 5 minutes en cours de route (tests qui tournent, builds, attente de la CI), ou que je reprendrai plus tard, ajoute ces deux lignes en haut du fichier :
experimental:
  cacheTtl: 1h
S'il y a déjà un bloc experimental, ajoute cacheTtl dessous. N'en écris pas un second. Laisse sur la valeur par défaut ceux qui vont d'une traite et finissent en quelques minutes. Donne une ligne de justification pour chacun.
3. Vérifie ~/.claude/settings.json, .claude/settings.json et .claude/settings.local.json (y compris leurs blocs env) ainsi que mes variables d'environnement actuelles, à la recherche de subagentPromptCacheTtl, CLAUDE_CODE_SUBAGENT_PROMPT_CACHE_TTL ou FORCE_PROMPT_CACHING_5M. Si l'une d'elles est définie, dis-moi qu'elle prend le pas sur les réglages par sous-agent et demande-moi s'il faut la supprimer.
4. Demande-moi si je suis sur un abonnement, une clé API ou un fournisseur cloud. Ne lis aucune clé toi-même. Sauf si je suis sur un abonnement dans les limites de son forfait, demande-moi si je m'absente souvent plus de 5 minutes en pleine session, et si c'est le cas, règle promptCacheTtl sur 1h.
Montre-moi d'abord ce que tu vas changer, et n'écris rien tant que je n'ai pas confirmé.

génère un rapport de session
recommande des automatisations pour ce projet

Crée une vidéo explicative dans le style de 3b1b sur X. Utilise ma clé API ElevenLabs pour la narration audio.

Un classifieur était sûr à {a.confidence:.0%}.
Ses probabilités : {a.probabilities}

État :
{state}

Choisis la prochaine étape et dis ce qui rendait ce cas ambigu.

[Choix] Choisis la prochaine étape pour ce brief de recherche.
  research : Collecte les preuves encore nécessaires pour l'objectif
  write : Rédige le brief à partir de preuves suffisantes
  review : Objectif flou, hors périmètre, ou travail terminé

[Score] Évalue l'urgence de cette demande.
  niveaux : faible, moyenne, haute, critique

[Vrai ou faux] L'action demandée peut être exécutée sans approbation humaine.

[Vrai ou faux, seuil 0,95] Ce brouillon est complet, sourcé, et sûr à publier.

[Score] Quelle est la pertinence de cette entrée par rapport à l'objectif en cours ?
  niveaux : hors sujet, contexte, utile, critique

[Routage] Choisis le modèle le moins coûteux capable d'accomplir la tâche.
  fast : Recherches directes, extraction, modifications localisées.
  powerful : Architecture et décisions à fort enjeu.

Dans ce dossier, lis ma clé API Gemini dans gemini-key.txt et ne l'affiche jamais à l'écran. Demande au modèle Gemini 4 images d'un coup, en 16:9, à partir de ce prompt : [ton prompt d'image]. Enregistre-les dans un dossier nommé output

Envoie chaque vidéo du dossier videos au modèle Gemini et demande : « Regarde cette vidéo. [Ce que tu veux en tirer]. Donne l'horodatage de chaque point. » Enregistre chaque réponse dans un fichier texte à côté de sa vidéo.

Tu dimensionnes pour moi une installation de LLM local. Ne me pose aucune question. Travaille à partir de la liste ci-dessous.

MES TÂCHES IA DE LA SEMAINE DERNIÈRE
[colle 10 à 20 tâches réelles : ce que c'était, la longueur de l'entrée, la fréquence]

Pour chaque tâche, produis une ligne de tableau :
tâche | données privées ? (oui/non) | taille de l'entrée (tokens, approximative) | exécutions par jour |
nécessite un raisonnement de pointe ? (oui/non, raison en une ligne) | plus petite classe de modèle
qui suffirait (4B / 12B / 27B / 100B+ / API de pointe)

Puis donne-moi trois totaux :
1. le nombre d'heures par jour pendant lesquelles un modèle local serait occupé
2. le plus grand contexte dont une seule tâche a besoin
3. la part des tâches qui doivent rester sur une API de pointe

Ne recommande pas de matériel. N'arrondis pas à la hausse. Si une tâche n'est pas claire, marque-la
« pas clair » au lieu de deviner.

Tu es un routeur. Lis la tâche et réponds uniquement en JSON :
{"lane": "small" | "big" | "cloud", "reason": "<12 mots max>"}

small = classer, extraire, étiqueter, reformuler, décisions oui/non, un seul appel d'outil
big   = écrire ou modifier du code, tâches en plusieurs étapes, tout ce qui touche à des fichiers privés
cloud = décisions d'architecture inédites, tâches qui ont échoué deux fois en local

En cas d'hésitation entre deux voies, choisis la moins chère.

Exécute chacune des tâches ci-dessous. Pour chaque tâche, affiche : la réponse, puis une ligne
« AUTO-VÉRIFICATION : » qui indique une façon dont la réponse pourrait être fausse.

1. [un vrai bug de mon dépôt + la sortie du test qui échoue]
2. [une clause de contrat] -> extrais les parties, les dates, les montants en JSON
3. [20 messages de support] -> étiquette chacun : facturation / bug / fonctionnalité / autre
4. [une capture d'écran d'un tableau de bord] -> liste chaque nombre que tu peux lire
5. [un document de 30 pages] -> réponds à trois questions dont les réponses sont en page 24
...
10. Une tâche où la bonne réponse est « Je ne peux pas le dire à partir de cette entrée. »

Rédige un message de commit git pour ce diff.
Ligne 1 : résumé à l'impératif, 60 caractères max.
Puis une ligne vide, puis jusqu'à 3 puces : ce qui a changé et pourquoi.
Pas de préambule. Pas de blocs de code.

%s

Étiquette ce ticket de support. Réponds uniquement en JSON :
{"category": "billing" | "bug" | "feature" | "account" | "other",
 "urgency": 1 | 2 | 3,
 "needs_human": true | false,
 "summary": "<15 mots max>"}
urgence 3 = argent perdu, données perdues, ou impossible de se connecter.
Si le ticket n'est pas clair, category vaut "other" et needs_human vaut true.

Réponds uniquement à partir du CONTEXTE. Après la réponse, cite la phrase
exacte sur laquelle tu t'es appuyé. Si le contexte ne contient pas la réponse, réponds
« Absent de ces documents. » N'utilise aucune connaissance extérieure.

Extrais les champs de la facture. Liste sous 'unreadable' tout champ que tu n'as pas pu lire clairement. Ne devine jamais un nombre.

---
name: local-review
description: Relit le diff indexé avant un commit. À utiliser quand l'utilisateur dit
  « relis », « vérifie mes modifications », ou demande si quelque chose peut être commité sans risque.
---
# Relecture locale

1. Lance `git diff --staged`. S'il est vide, dis-le et arrête-toi.
2. Lis en entier chaque fichier modifié, pas seulement les morceaux du diff.
3. Rends compte dans cet ordre : bugs, tests manquants, modifications risquées. 10 lignes max.
4. Pour chaque bug, donne fichier:ligne et un correctif en une ligne. Ne modifie aucun fichier.
5. Si tu n'es pas sûr que quelque chose soit un bug, étiquette-le « pas sûr ».
6. Termine par un seul mot sur sa propre ligne : COMMIT ou ATTENDRE.

Rédige un digest du matin en markdown.
Sections : Livré hier / Semble inachevé / À faire en premier aujourd'hui (3 éléments).
N'utilise que des faits tirés de l'entrée. Si l'entrée est vide, écris « Rien de nouveau. »

Liste toutes les applis installées sur ce téléphone avec leur identifiant et leur éditeur. Signale celles qui n'ont pas d'icône, celles installées en dehors de la boutique officielle (App Store / Play Store), et tout ce qui porte un nom de service système. Lecture seule, ne change rien.

Liste chaque profil de configuration/MDM (iPhone) ou chaque appli administrateur de l'appareil et chaque appli ayant l'accessibilité activée (Android). Pour chacun : qui l'a installé, ce qu'il peut contrôler, quand il a été ajouté. Signale tout ce que je n'ai pas configuré moi-même.

Montre chaque connexion sortante de ce téléphone. Signale toute destination qui n'est pas un service officiel connu : adresses IP brutes, ports inhabituels, ou tout ce qui envoie des données à intervalle fixe, par exemple toutes les deux ou trois minutes.

Liste les applis qui détiennent en permanence la localisation, le micro ou la caméra sans en avoir besoin, et tout ce qui se relance au démarrage ou tourne en continu en arrière-plan que je n'ai pas configuré.

RÔLE : Tu es un auditeur de confidentialité et de sécurité mobile.

PÉRIMÈTRE : C'est mon propre téléphone (iPhone ou Android) et tu as un accès en lecture seule. Ne modifie, n'installe et ne supprime rien. Si une étape devait écrire sur le téléphone, saute-la et dis-le.

OBJECTIF : Dis-moi en langage simple si quelque chose sur ce téléphone me surveille (localisation, messages, micro, caméra) ou fait des rapports à un tiers.

VÉRIFIE :

Applis : chaque appli installée avec son identifiant et son éditeur. Signale celles sans icône, installées en dehors de l'App Store / du Play Store, ou déguisées en service système.
Contrôle profond : tous les profils de configuration/MDM (iPhone) et les applis administrateur de l'appareil / d'accessibilité (Android) : qui les a installés, ce qu'ils contrôlent, quand.
Autorisations : toute appli qui détient en permanence la localisation, le micro ou la caméra sans en avoir besoin.
Persistance : tout ce qui se relance au démarrage ou tourne en continu en arrière-plan que je n'ai pas configuré.
Réseau : les connexions sortantes. Signale les destinations qui ne sont pas des services connus : IP brutes, ports inhabituels, rapports à intervalle fixe.

Pour chaque signalement : ce que c'est, ce à quoi il a accès, depuis combien de temps il est là, où il envoie des données, et une gravité faible/moyenne/élevée.

TERMINE PAR : une ligne de verdict (sain ou compromis), puis trois listes (Sûr / À supprimer / Demande un professionnel), puis la chose la plus importante à faire ensuite. Lecture seule.

Astuce Claude Code : avant de mettre en ligne un site fait en vibe coding, fais jouer le méchant à Opus 5.5. Envoie 3 sous-agents avec trois comptes de test (A, B et un admin) exécuter réellement ces 14 attaques, collecter des preuves, puis tout corriger en une passe :

Se faire passer pour d'autres utilisateurs
→ Sans te connecter, prends la clé publique dans ton frontend et interroge directement chaque table de la base de données. Regarde ce qui revient
→ Connecté en tant que A, remplace l'id dans une requête par celui de B et essaie de lire, modifier et supprimer les données de B
→ Quand A modifie son profil, ajoute role: admin à la requête, puis essaie de modifier le rôle directement dans les données de son propre compte
→ Utilise un lien de réinitialisation de mot de passe une fois, puis clique dessus à nouveau

Contourner les limites de l'interface
→ Pour les boutons désactivés et les options masquées, saute la page et envoie la requête directement
→ Une fois les utilisations gratuites épuisées, vérifie si l'appel direct à l'API fonctionne encore
→ Avec seulement un peu de crédit restant, envoie 20 requêtes d'un coup et regarde si plus de requêtes réussissent que le crédit ne le permet
→ Remplis les formulaires avec du texte très long, des caractères spéciaux, des nombres négatifs et des valeurs vides
→ Change la redirection après connexion (?next=) vers un autre site, et essaie aussi des valeurs qui commencent par // et @

Entrer par l'extérieur
→ Mets <img src=x onerror=alert(1)> dans un nom d'utilisateur, un commentaire ou du Markdown, puis ouvre la page dans un navigateur et regarde si une alerte s'affiche
→ Si l'app récupère des URL (import de liens, génération d'aperçus), donne-lui http://localhost et http://169.254.169.254 et vérifie dans les journaux du serveur qu'une requête sortante a réellement eu lieu. Saute ce point s'il n'y a pas de fonctionnalité de ce genre
→ Pour les pages et les réponses d'API que A a vues, demande la même adresse depuis un autre navigateur en tant que B ou déconnecté, et regarde si le contenu de A apparaît
→ Ouvre les liens de prévisualisation de ta plateforme d'hébergement sans être connecté à la plateforme
→ Cache dans un document téléversé ou une page web une instruction qui demande à ta fonctionnalité d'IA de lire les données d'un autre utilisateur ou d'appeler un outil qu'elle ne devrait pas appeler, et regarde si elle le fait

Collecter les preuves
→ Chaque point doit réellement être exécuté. S'il a seulement été lu dans le code sans être exécuté, il compte comme « non prouvé »
→ Après un correctif, désactive temporairement la protection dans le code local et relance. L'attaque doit réussir. Réactive-la : elle doit être refusée
→ Mets les résultats dans un tableau : comment chaque attaque a été menée, la requête et la réponse, et si elle a été refusée quand elle devait l'être
→ Enregistre les tests sous forme de scripts dans le dépôt et relance-les avant ta prochaine mise en ligne
→ Quand tu as fini, installe le plugin officiel security-guidance d'Anthropic (/plugin install security-guidance@claude-plugins-official). Après chaque tour de modifications, et après chaque commit ou push qu'il fait, Opus relit à nouveau les changements. Ces relectures consomment de l'usage supplémentaire

L'effort moyen par défaut suffit. Le groupe usurpation est le plus coûteux à rater, alors monte celui-là en high.

D'abord, vérifie que l'environnement de prévisualisation n'est pas connecté à la base de données de production. S'il l'est, exécute tout uniquement en local. Utilise des comptes et des données de test, avec un jeu de comptes distinct pour chaque sous-agent. Ne touche pas aux vrais utilisateurs, n'attaque pas de services qui ne m'appartiennent pas, ne martèle aucun point d'accès, et ne teste les paiements qu'en mode test. Ne désactive les protections que temporairement dans le code local, et ne modifie jamais les réglages de la base de données ni du tableau de bord. Garde les mots de passe des comptes de test dans .env, hors de git, et masque les jetons dans le tableau de résultats. Envoie un sous-agent par groupe pour attaquer, en consignant sans corriger. Lance le sous-agent usurpation en effort high. Ensuite, corrige tout toi-même à partir de leurs listes, relance chaque test et donne-moi un tableau avant/après. Supprime les comptes et les données de test à la fin. Pour installer le plugin ou modifier les réglages du tableau de bord, donne-moi les étapes et je le ferai.

Astuce Claude Code : avant de mettre en ligne un site fait en vibe coding, fais envoyer par Opus 5.5 4 sous-agents vérifier ces 20 choses qui le ralentissent, puis tout corriger en une passe :

Images et polices
→ Convertis chaque image en WebP ou AVIF, dimensionnée à sa taille réelle d'affichage sur la page
→ Sers les grandes images depuis Supabase Storage via next/image à la bonne taille. Avec l'offre Pro, les transformations d'images propres à Supabase fonctionnent aussi
→ Charge en différé les images et vidéos sous la ligne de flottaison, et charge en premier la grande image du haut de page
→ Charge les polices comme le prévoit ton framework (next/font dans Next.js), et limite-toi à une ou deux polices
→ Retire les scripts tiers que tu n'utilises pas, et lance l'analytics et les widgets de chat après le chargement de la page

Code frontend
→ Lance un analyseur de bundle pour trouver les plus gros paquets, et là où une bibliothèque entière est importée, n'importe que les parties que tu utilises, comme des fonctions lodash isolées
→ Charge les composants lourds dont le premier écran n'a pas besoin, comme les graphiques, les éditeurs et les cartes, avec un import dynamique au moment où ils sont nécessaires
→ Récupère les données de la page d'accueil côté serveur, pour que la page s'ouvre avec son contenu déjà présent
→ Diffuse les réponses de l'IA au fil de leur génération
→ Affiche des squelettes pendant le chargement des données

Base de données et API
→ Indexe les colonnes sur lesquelles tu filtres et tries, y compris celles qu'utilisent tes politiques RLS, comme user_id
→ Dans les politiques RLS, écris auth.uid() sous la forme (select auth.uid()) pour qu'il ne s'exécute qu'une fois par requête
→ Trouve les requêtes N+1 et transforme-les en une seule requête
→ Pagine les longues listes
→ Mets en cache les réponses d'API identiques pour tout le monde, et ne mets jamais en cache ce qui est lié à un utilisateur connecté
→ Déplace les travaux lourds comme l'envoi de mails, le traitement d'images et la génération de rapports vers des tâches d'arrière-plan

Serveurs et réseau
→ Place tes fonctions serveur dans la même région que ta base de données. Les nouveaux projets Vercel exécutent les fonctions dans la région US East par défaut
→ Transforme les pages dont le contenu change rarement en pages statiques ou en ISR
→ Quand une page appelle des API l'une après l'autre, exécute-les en parallèle ou fusionne-les en une seule
→ Dans Chrome, émule un téléphone Android d'entrée de gamme en 4G lente et parcours les principaux enchaînements

L'effort moyen par défaut suffit. Le groupe base de données doit lire les requêtes et décider quels index ajouter, alors monte celui-là en high.

Envoie un sous-agent par groupe vérifier sans rien modifier, et note dans quel fichier se trouve chaque problème et quelle page il touche. Lance le sous-agent base de données en effort high. Avant de modifier quoi que ce soit, lance un build de production (next build && next start dans Next.js) ou utilise un lien de prévisualisation, puis lance Lighthouse trois fois en mode mobile sur la page d'accueil et sur les deux ou trois pages les plus lentes, et note la médiane. Ensuite, corrige tout toi-même à partir de leurs listes, mesure de nouveau de la même façon, et donne-moi les chiffres avant/après. Ne supprime pas de fonctionnalités pour gagner en vitesse. Demande-moi avant de supprimer des dépendances, de changer la région de déploiement ou de modifier la base de données.

Installe REA et connecte-le à cet agent de code avec npx rea-agents@latest setup. Montre-moi le plan d'installation pour validation, puis vérifie l'installation.

Utilise REA sur cet APK. Liste chaque permission, chaque SDK d'analyse ou de pistage, et chaque domaine avec lequel l'appli communique. Indique la classe et la méthode pour chaque constat.

Utilise REA sur ce bytecode de contrat. Liste chaque fonction capable de modifier l'état. Signale tout ce qui ressemble à mint, blacklist, pause, changement de frais ou transfert réservé au propriétaire. Indique ce qui est confirmé et ce qui est déduit.