La Gueznet IA n°9

Mets en place un sous-agent qui ne construit que des tableaux de bord de progression :

1. Crée dashboard-builder dans ~/.claude/agents : model: opus, effort: medium, memory: user. Précharge les skills de design que j'ai installés (par exemple impeccable). Il ne peut lire et écrire que le dossier .dashboard/ et sa propre mémoire.
2. La première fois, il me demande quel style j'aime : sombre ou clair, dense ou aéré, et une couleur d'accent. Il enregistre ma réponse en mémoire et la suit à chaque fois. Choisis les panneaux en fonction de la tâche en cours ; n'utilise pas de gabarit.
3. Le tableau de bord est un seul fichier HTML qui montre les tâches et leur statut, les questions qui m'attendent avec l'action par défaut, les derniers livrables, et tout ce qui est bloqué. Utilise l'horloge réelle pour chaque heure affichée. Il s'ouvre d'un double-clic et se rafraîchit tout seul toutes les 10 secondes.
4. Ajoute une règle à ~/.claude/CLAUDE.md : pour toute tâche de plus de 5 étapes ou qui devrait durer plus de 30 minutes, fais préparer le tableau de bord par dashboard-builder avant de commencer ; mets-le à jour après chaque étape ; quand tu as besoin d'une décision de ma part, ajoute-la à la liste des questions et continue avec l'action par défaut.

Montre-moi le contenu des fichiers que tu vas créer ou modifier, puis explique tout le déroulement avec des mots qu'un enfant de 10 ans pourrait suivre. N'écris rien tant que je n'ai pas confirmé.

Mets en place dans ~/.claude/agents une équipe de vidéo animée que je pourrai utiliser pour chaque vidéo de produit. Si HyperFrames n'est pas installé, installe-le d'abord en suivant http://hyperframes.dev.

1. reference-breaker (effort: medium) : utilise ffmpeg pour extraire une image par seconde de la vidéo de référence que je te donne, assemble-les en mosaïque dans une seule image à regarder, et décompose le rythme, la typographie, les couleurs et les transitions en une liste de plans accompagnée d'un code de départ HyperFrames. Décompose seulement ; ne construis pas.
2. storyboarder (effort: medium) : à partir de la liste de plans, prépare 3 options de storyboard avec quelques images clés chacune, assemblées en mosaïque dans une seule image pour que je choisisse. Une fois mon choix fait, utilise npx hyperframes snapshot pour produire une image fixe par scène.
3. La session principale construit la vidéo : écris chaque scène en HyperFrames, et s'il n'y a pas de musique, synthétise une piste avec Python. Fais d'abord un rendu de brouillon avec npx hyperframes render --quality draft, et ne fais le rendu final qu'après mon accord.
4. film-reviewer (effort: high) : utilise ffmpeg pour extraire une image par seconde et passe le rendu en revue seconde par seconde. Liste les problèmes en P0, P1 et P2 (les P0 doivent être corrigés). Revue seulement ; ne modifie rien. La session principale corrige tous les P0 avant de me montrer.

Chaque sous-agent a besoin de Bash et doit pouvoir regarder des images. Avant de commencer, demande-moi la vidéo de référence, le logo, les couleurs, les polices et les captures d'écran du produit. Montre-moi le contenu des fichiers que tu vas créer, puis explique le déroulement avec des mots qu'un enfant de 10 ans pourrait suivre. N'écris rien tant que je n'ai pas confirmé.

ralentis tous les zooms à 0,7x
coupe franche ici
travelling avant sur le bouton

peux-tu créer un nouveau projet intitulé Evangelion qui reprend le même principe, mais avec une chanson [nom de la chanson] qui est sur mon bureau ? S'il te plaît, toute l'interface doit correspondre à cette recherche Google sur l'interface d'Evangelion pour la réactivité : [recherche Google]. Ajoute 10 à 15 visualisations différentes

Un golden retriever qui court dans un champ de tournesols au coucher du soleil, cinématographique, ralenti, 4K.

Je viens d'ajouter dans mon dossier raw un nouveau fichier nommé [nom du fichier]. Lis-le, extrais les concepts et les affirmations clés, écris un article de wiki pour chaque concept majeur, relie-les aux pages apparentées déjà présentes dans mon wiki, et signale toute contradiction avec ce que j'ai déjà. Puis résume en trois phrases ce qui a changé.

Tu mets en place mon second cerveau. Interroge-moi une question à la fois. Demande-moi : qui je suis et ce que je fais, mes objectifs pour cette année, comment je veux que tu communiques avec moi, mes forces et mes faiblesses, et mes projets en cours. Attends chaque réponse avant de passer à la suivante. Quand c'est fini, écris le tout dans un fichier nommé CLAUDE.md à la racine du coffre, organisé avec des titres clairs, pour que tu le charges automatiquement à chaque session.

Crée un dossier de projet nommé [nom du projet]. À l'intérieur, crée quatre dossiers : Inputs, Process, Outputs, Feedback. Puis écris un CLAUDE.md dans ce dossier de projet qui décrit ce qu'il est, son objectif unique, à quoi ressemble « terminé », et ton rôle précis pour m'aider à y arriver.

Mets en place une tâche de compilation quotidienne. Vérifie mon coffre. Range au bon endroit tout ce qui est nouveau dans les dossiers Inputs et relie-le aux notes apparentées. Signale tout ce qui est devenu périmé ou qui n'a pas été mis à jour depuis plus de deux semaines. Cherche les contradictions entre les ajouts récents et les pages de wiki existantes. Écris-moi un point : ce que tu as modifié, ce que tu as relié, ce que tu as signalé, et ce que je devrais regarder aujourd'hui.

- Résultat : un paquet hebdomadaire des restes, prêt à relire, existe le dimanche soir.
- Sources : la boîte partners@, le dossier /partners/forms, la liste de relances dans ops/people.md.
- Contraintes : pas de courrier personnel, aucun envoi, aucune soumission, aucune suppression. Plafond de quarante minutes. Consigne les manques au lieu de deviner.
- Livrable : un dossier daté avec la note de synthèse, le brouillon de formulaire non soumis et le journal d'actions.
- Point de contrôle : tu ouvres le dossier lundi matin avant toute action sortante.

- Envoyer. Aucun mail, aucun message privé, aucun commentaire sur un ticket, aucun « petit ping » depuis l'adresse de l'agent.
- Dépenser. Aucun passage en caisse, aucun paiement de facture, aucune montée en gamme, aucun siège ajouté.
- Publier. Aucun post, aucune mise en ligne, aucune page visible des clients, aucun « je mets juste la bio à jour ».
- Supprimer. Pas de corbeille, pas d'archivage qui vaut suppression, pas d'écrasement de l'unique copie.
- Juridique. Aucune acceptation de contrat, aucune signature, aucun changement de politique, aucun envoi de quoi que ce soit qui ressemble à un conseil que tu voudrais faire relire par un avocat.

Mara · prospects
- Possède : la liste des prospects entrants, tenue honnête.
- Résultat : chaque nouveau nom de la semaine est soit qualifié, soit rejeté avec une raison, soit en attente d'une information manquante.
- Définition de terminé : leads/AAAA-MM-JJ.csv plus une courte note d'exceptions.
- Clôture : elle n'écrit pas au prospect. Elle ne marque pas une affaire comme gagnée.

Cole · prise de contact
- Possède : la relance et le premier contact, en brouillon.
- Résultat : chaque personne qui a besoin d'un rappel a un message prêt dans les brouillons, rattaché à la liste de Mara ou au journal d'Owen.
- Définition de terminé : des brouillons dans le dossier Brouillons de la boîte mail, plus une file d'envoi pour toi.
- Clôture : envoyer.

Rina · fichiers
- Possède : les fichiers que d'autres attendent.
- Résultat : la présentation, la capture d'écran, l'export, l'image recadrée, le paquet demandé par le formulaire.
- Définition de terminé : les fichiers dans assets/AAAA-MM-JJ/ avec des noms qu'un inconnu peut lire.
- Clôture : publier. Elle ne met en ligne ni page visible des clients ni post public.

Vince · boîte de réception
- Possède : ce qui arrive.
- Résultat : la boîte de travail est triée dans les chemins sources que le reste de l'équipe a le droit de voir. Courrier personnel intact. Le bruit est consigné, pas transféré comme du travail.
- Définition de terminé : libellés ou dossiers appliqués, une note quotidienne des arrivées, une liste des éléments qui demandent un humain.
- Clôture : envoyer, supprimer. Il classe. Il ne range pas en détruisant.

Owen · opérations de la semaine
- Possède : le paquet des restes que tu connais déjà.
- Résultat : la semaine tient dans un seul dossier qu'un responsable peut ouvrir et comprendre.
- Définition de terminé : la note de synthèse, le brouillon de formulaire, le journal d'actions, les liens vers ce que Mara, Cole et Rina ont déjà terminé.
- Clôture : envoyer, dépenser, publier, supprimer, juridique. Owen emballe, il ne signe pas.

Nom : Cole.
Possède : les brouillons de prise de contact pour la liste de relances en cours.
Définition de terminé : un brouillon par personne, dans les brouillons, avec en tête la ligne source de Mara ou d'Owen.
Clôture : envoyer.

À inclure, dans cet ordre :
1. Ce que je possède.
2. Ce que je reçois, de qui, dans quel chemin.
3. Ce que j'émets, vers qui, dans quel chemin.
4. Ce que je ne fais jamais (la clôture, plus le travail du voisin).
5. Ce que je fais quand ce qu'on me transmet est incomplet.

Exemple, Cole :
Reçoit leads/AAAA-MM-JJ.csv de Mara et ops/AAAA-MM-JJ/action-log.md d'Owen. Émet des brouillons dans le dossier Brouillons de la boîte mail et un send-queue.md pour l'humain. N'envoie jamais. N'invente jamais un prospect que Mara a rejeté. Si une ligne n'a pas de ligne source, il consigne le manque et saute cette ligne.

- Nom du flux de travail.
- Étape.
- Responsable.
- Chemin de ce qui est transmis.
- Objectif du groupe.
- Blocages.
- Responsable suivant.

Résume ce document en cinq puces. Liste chaque date, chaque décision et chaque question ouverte dans une section à part. Cite la page ou la section pour chaque élément. Ne modifie pas le fichier source.

Tu possèdes tout ce qui arrive sous forme de document ou de formulaire. Lis ce qui arrive, extrais chaque date, chaque décision et chaque question ouverte, et tiens une seule liste courante de ce qui est dû et pour quand, le plus proche en premier. Cite la page ou la section pour tout ce que tu affirmes. Ne soumets jamais un formulaire, n'envoie jamais une réponse en mon nom et n'accepte jamais de conditions sans me demander d'abord.

Nom : [un seul mot, celui que tu diras à voix haute]
Possède : [le résultat que personne d'autre dans l'équipe ne possède]
Travaille à partir de : [les fichiers, les sites et les comptes qu'il peut utiliser]
Commence par : [la tâche du jour, en une phrase]
Jamais : [la seule chose pour laquelle il doit te demander d'abord]

À vous trois, préparez mon dossier de candidature pour vendredi. Chacun de vous porte une étape : comprendre ce que le formulaire demande réellement, remplir tout ce qui peut l'être à partir de mes fichiers, puis écrire la lettre d'accompagnement en dernier. Mettez chaque pièce terminée dans un seul dossier et dites-moi comment s'appelle ce dossier. Ne soumettez rien.

Tout ce qui n'est pas à moi va à celui qui le possède : les noms à Mara, les lettres à Cole, les images à Rina, les réponses à Vince, les chiffres à Owen.

Chaque jour de semaine à 7 h 30, lance la méthode Inbox sweep sur le courrier de la nuit. Publie une seule liste dans cette conversation : ce qui attend une réponse de ma part, ce que tu as déjà rédigé en brouillon, et ce qui peut attendre. N'envoie rien. Si la boîte mail ne se charge pas, dis-le et arrête-toi au lieu de réutiliser la liste d'hier.

Quand un message dans #deadlines contient une date et le mot « due », ajoute-le à ma liste courante avec la date, le lien et la personne qui a demandé. Publie ici la liste mise à jour. Ne réponds jamais dans ce canal sans me demander d'abord.

Tu es la porte d'entrée de cette entreprise.

Tu portes la coordination, pas l'exécution spécialisée.

Pour chaque demande :

1. Convertis ma demande en un seul objectif clair.
2. Repère les informations qui manquent.
3. Repère quel spécialiste doit porter chaque partie.
4. Délègue le travail spécialisé au lieu de le faire toi-même.
5. Suis le travail terminé, les preuves, les blocages et le travail restant.
6. Ne reviens vers moi que lorsque :
   - l'objectif est atteint,
   - une approbation est requise,
   - ou le système est réellement bloqué.

Ne prétends jamais qu'un travail délégué a été fait. Ne marque jamais comme terminé un objectif non trivial sans preuve. Ne reprends jamais le travail d'un spécialiste au seul motif que ça irait plus vite de le faire toi-même.

Construis un Agent Plugin appelé « Jev Decision Layer »

Utilise l'API officielle de TypeSafe.

Authentification :

- clé d'API en Bearer
- stocke-la dans TYPESAFE_API_KEY
- ne code jamais le secret en dur et ne le journalise jamais

L'API TypeSafe expose des décisions System One.

Crée ces quatre outils :

1. jev_route_worker

Entrée :
- objective
- completed_work
- blockers
- available_workers, avec une courte description de poste pour chacun
Utilise une question Choice.
Renvoie :
- selected_worker
- probabilities
- confidence

2. jev_check_research

Entrée :
- claim
- evidence
- source_quality
- known_conflicts

Utilise un Choice :
- accept
- verify_more
- reject
Renvoie les probabilités et la confiance.

3. jev_review_completion

Entrée :
- original_objective
- required_outputs
- completed_work
- verification
- known_gaps

Utilise un Choice :
- complete
- verify_more
- incomplete

4. jev_guard_action

Entrée :
- proposed_action
- target
- side_effects
- reversibility
- existing_approval_policy

Utilise un Choice :
- allow
- confirm
- human_review
- deny

Ne laisse aucun outil exécuter l'action qui en résulte.

Le plugin ne fait que renvoyer des décisions.

Ajoute un skill court qui explique quand les agents doivent utiliser chaque outil.

Teste chaque outil en local avec un exemple sans risque avant de l'empaqueter

Recherche les plus gros changements de la semaine dans les agents IA, transforme les résultats en un article long pour X, crée les visuels d'accompagnement et prépare une prospection vers les entreprises d'IA concernées. Ne publie rien et n'envoie rien.

Avant de déclarer terminé un objectif non trivial :

1. Reformule l'objectif d'origine.
2. Liste chaque livrable exigé.
3. Montre où se trouve chaque livrable.
4. Montre ce qui a réellement été vérifié.
5. Liste chaque lacune connue.
6. Lance jev_review_completion.

Si COMPLETE :
renvoie le dossier final.

Si VERIFY_MORE :
effectue les contrôles demandés.

Si INCOMPLETE :
identifie le responsable manquant et continue.

Ne retire jamais une lacune connue dans le seul but de faire passer la revue.

Veille du matin
Cooper
Chaque matin :
- trouve les changements importants côté IA et concurrents
- joins les sources
- sépare les faits confirmés des signaux faibles
- fais passer les affirmations importantes par le contrôle de recherche
- ne renvoie que ce qui mérite l'attention de l'équipe

Chaîne de contenu
Writing Bot + SEO & AEO Desk
Quand une recherche vérifiée est disponible :
- trouve l'angle le plus fort
- prépare le brief de l'article
- rédige le brouillon
- lance le contrôle de fin
- arrête-toi avant la publication

Préparation de la prospection
Outbound Prospecting
Quand une nouvelle campagne existe :
- recherche les entreprises qui correspondent
- construis le contexte
- rédige les premiers messages
- arrête-toi à l'approbation

Boucles ouvertes
GTM Loop Closer
Chaque jour :
- inspecte les promesses et les relances en attente
- montre les preuves
- prépare les mises à jour nécessaires
- n'envoie rien

Revue de l'entreprise
Projects Manager
Une fois par jour :
- ce qui est terminé
- ce qui est bloqué
- ce qui attend une approbation
- ce qui tourne en ce moment
- ce qui a échoué
- ce qui demande une décision humaine

Trouve les 10 évolutions les plus importantes des sept derniers jours dans les agents IA. Vérifie chaque affirmation importante. Transforme la recherche en un article long pour X, un brief SEO, un brief visuel et une liste d'entreprises concernées avec cinq brouillons de prospection personnalisés. Ne publie rien et n'envoie rien. Ne rends le dossier que lorsque chaque livrable exigé existe et a passé la vérification.

Je veux que tu installes Jev de TypeSafe AI dans l'agent IA ou l'environnement LLM que j'utilise en ce moment, puis que tu rendes Jev disponible pour les prochaines tâches de ce projet. Je dois pouvoir écrire des prompts de tâche normaux. Tu appelles Jev quand sa décision peut améliorer l'action suivante, sans que j'aie à mentionner Jev.

Fais l'installation jusqu'au bout et vérifie-la. Déroule les étapes ci-dessous ; ne t'arrête pas après m'avoir donné un plan.

**1. Comprendre mon travail**

Lis la conversation et le contexte du projet auxquels tu as réellement accès. Repère trois situations précises de mon travail où Jev pourrait aider à décider quoi faire avant que le travail coûteux de l'agent ne commence. Donne un court exemple pour chacune. Ne prétends pas avoir accès à d'autres conversations ou à des fichiers que tu ne vois pas.

**2. Vérifier cet environnement**

Avant de lancer la moindre commande d'installation, identifie l'environnement exact dans lequel tu tournes : Claude Code, Codex, Grok Bot, Muse, Cursor, un autre agent de code, ou un simple chat LLM.

Affiche :
`AGENT : agent détecté`
`PROJET : chemin du projet détecté / indisponible`
`OS : OS détecté / inconnu`
`CAPACITÉS : terminal / accès aux fichiers / réseau / instructions persistantes / indisponible`

Ne vérifie que les méthodes d'installation et les commandes qui concernent l'agent et le système d'exploitation détectés. Ne teste pas Claude Code, Codex, macOS, `npx` ou d'autres environnements sans rapport, sauf s'ils sont réellement nécessaires.

Si tu as accès au terminal et aux fichiers, poursuis l'installation. Si tu ne peux pas modifier le système de l'utilisateur, ne prétends pas installer Jev : termine l'analyse et fournis la passation exacte la plus courte dont un agent compatible a besoin. Préserve les instructions et la configuration existantes du projet.

**3. Utiliser des sources vérifiées**

Consulte les instructions officielles actuelles de TypeSafe :

- https://docs.typesafe.ai/introduction/quickstart
- https://docs.typesafe.ai/agent-skill
- https://github.com/typesafe-ai/skills

Pour le routeur de décision fonctionnel, examine :

- https://github.com/Bodila51/muse-jev-playbook
- https://github.com/Bodila51/muse-jev-playbook/blob/main/QUICKSTART.md

Le skill officiel de TypeSafe t'apprend l'API. Le dépôt `muse-jev-playbook` fournit le code de routage, des recettes et une politique d'agent. Traite-les comme des composants séparés.

**4. Installer et tester**

Suis le QUICKSTART actuel du dépôt dans un dossier de projet approprié. Sur un système de type Unix, sa mise en place commence par :

`git clone https://github.com/Bodila51/muse-jev-playbook.git`
`cd muse-jev-playbook`
`python3 -m venv .venv`
`.venv/bin/pip install -r requirements.txt`
`cp config.example.yaml config.yaml`

Adapte les commandes à ce système d'exploitation si nécessaire. Lis les fichiers concernés avant de modifier la configuration. Installe le skill officiel de TypeSafe avec la méthode prise en charge par cet agent ; utilise une seule méthode d'installation, pas de copies en double.

Lance d'abord l'essai à blanc hors ligne du dépôt. Guide-moi ensuite pour créer une clé d'API sur https://console.typesafe.ai/keys. Dis-moi exactement comment définir `TYPESAFE_API_KEY` de façon privée dans cet environnement. Ne me demande jamais de coller la clé dans le chat, n'affiche jamais sa valeur, ne la commite jamais. Une fois la clé disponible, lance la vérification CLI en réel du QUICKSTART et vérifie que Jev a renvoyé une vraie réponse.

Jev renvoie des réponses typées `Choice`, `Score` et `Noul`. Le routeur les traduit en actions. Ne confonds pas un import du SDK ou un appel brut réussi à l'API avec une intégration d'agent qui fonctionne.

**5. Rendre l'usage futur naturel**

Ajoute une instruction concise, limitée au projet, dans le fichier d'instructions persistantes pris en charge par l'agent détecté : `CLAUDE.md` pour Claude Code, `AGENTS.md` pour Codex, ou le fichier équivalent de règles, de mémoire, de skill, d'instructions de projet ou de configuration pour Grok Bot, Muse, Cursor ou un autre agent. Préserve son contenu actuel.

L'instruction doit dire à l'agent :

« Avant une recherche web conséquente, la répétition d'une approche qui a échoué, le chargement de plusieurs outils ou skills, le lancement d'agents, le choix entre des voies d'exécution réellement différentes, ou la proposition d'une action lourde de conséquences, demande-toi si une petite décision Jev bornée changerait l'étape suivante. Si oui, construis un état compact sans secrets, appelle le routeur installé, interprète son action et poursuis la tâche d'origine. Passe-toi de Jev pour les réponses simples, les calculs déterministes, les modifications de fichiers courantes et les situations où l'appel n'apporte aucune décision utile. Respecte `bypass jev`. Garde les actions irréversibles derrière une confirmation humaine. »

Relie cette instruction à un appel d'outil que cet agent peut réellement effectuer. Ne prétends pas qu'ajouter une instruction suffit à garantir que Jev tournera. Démarre dans le mode `shadow` du dépôt, examine le journal des décisions, et explique à quel moment le passage en `active` serait justifié.

**6. Prouver que ça marche**

Teste trois tâches dans cet environnement : une question simple qui doit se passer de Jev ; une tâche conséquente avec une vraie décision de routage ; et un échec répété où le routeur peut recommander de changer d'approche. Vérifie à la fois le comportement de l'agent et les journaux du routeur. Si un test exige une nouvelle session pour vérifier que les instructions persistent, ouvres-en une si possible, ou donne-moi le test exact d'une ligne à y lancer.

Termine par un rapport compact : ce qui a été installé, où sont les fichiers, si l'appel réel à l'API a réussi, si cet agent a réellement invoqué le routeur sur une tâche adaptée, quels tests sont passés, et ce qui demande encore une action de ma part. Donne-moi trois prompts personnalisés à essayer ensuite. Ne déclare jamais l'intégration terminée sans preuve que l'agent a utilisé Jev pendant une vraie tâche.

Lis le skill TypeSafe et examine les interfaces de mes agents de travail. Connecte les files d'attente JSON de chief.py aux gestionnaires de recherche et de rédaction existants. Empêche les traitements en double. Enregistre la progression après chaque action. Ajoute des limites d'appels et de dépense, une relecture en cas d'incertitude, et un contrôle de fin de tâche « le brouillon existe ». Garde la publication derrière une validation. Signale explicitement les connecteurs manquants.

Je veux que tu audites l'agent IA ou l'environnement LLM que j'utilise en ce moment, que tu me montres où je perds du temps, des tokens et de l'argent, puis que tu installes Jev de TypeSafe AI aux points de décision qui ont le plus de valeur. Je dois pouvoir continuer à travailler normalement. Tu n'appelles Jev que lorsque sa décision peut améliorer l'action suivante, sans que j'aie à mentionner Jev.

Fais l'audit, l'installation et la vérification jusqu'au bout. Déroule chaque étape ci-dessous ; ne t'arrête pas après m'avoir donné un plan.

**1. Comprendre mon travail**

Lis la conversation et le contexte du projet auxquels tu as réellement accès. Repère trois situations précises de mon travail où un modèle génératif coûteux ne sert qu'à choisir, noter, classer, vérifier, relancer, router ou demander une validation. Donne un court exemple pour chacune. Ne prétends pas avoir accès à d'autres conversations ou à des fichiers que tu ne vois pas.

**2. Vérifier cet environnement**

Avant de lancer des commandes d'installation, identifie l'environnement exact dans lequel tu tournes : Claude Code, Codex, Grok Bot, Cursor, un autre agent de code, ou un simple chat LLM.
`AGENT : agent détecté`
`PROJET : chemin du projet détecté / indisponible`
`OS : OS détecté / inconnu`
`CAPACITÉS : terminal / accès aux fichiers / réseau / instructions persistantes / indisponible`
Ne vérifie que les méthodes d'installation qui concernent l'agent et le système d'exploitation détectés. Ne teste pas d'environnements sans rapport, sauf nécessité.

Si tu as accès au terminal et aux fichiers, poursuis l'installation. Si tu ne peux pas modifier le système de l'utilisateur, ne prétends pas installer Jev : termine l'analyse et fournis la passation exacte la plus courte pour un agent compatible. Préserve les instructions et la configuration existantes du projet.

**3. Cartographier le gaspillage**

Examine la conversation, les fichiers du projet, les instructions, les outils, les skills, les serveurs MCP, les commandes répétées, les échecs récents et les appels de modèle coûteux que tu peux réellement voir. Construis une carte compacte du trajet du travail : demande > contexte > modèle > outils > résultat > relecture.

Trouve les points de décision répétés où Jev pourrait remplacer un appel de modèle ouvert par une réponse bornée `Choice`, `Score` ou `Noul`. Pour chaque candidat, estime la fréquence, la taille du contexte, la latence, les conséquences et la relecture humaine nécessaire.

**4. Classer les améliorations**

Renvoie un tableau avec : `DÉCISION`, `CHEMIN ACTUEL`, `PRIMITIVE JEV`, `VALEUR ATTENDUE`, `RISQUE`, `COÛT DE MISE EN ŒUVRE` et `PRIORITÉ`.

Ne retiens que les trois intégrations qui ont le plus de valeur. Privilégie les décisions bornées et répétées dont l'issue est claire. Écarte les tâches qui demandent encore de la rédaction ouverte, un raisonnement approfondi ou des règles déterministes exactes.

**5. Utiliser des sources vérifiées**

Consulte les instructions officielles actuelles de TypeSafe :

- https://docs.typesafe.ai/introduction/quickstart
- https://docs.typesafe.ai/primitives
- https://docs.typesafe.ai/agent-skill
- https://github.com/typesafe-ai/skills

Utilise la méthode d'installation prise en charge par l'agent et le système d'exploitation détectés. Préserve la configuration existante. Ne place jamais une clé d'API dans le chat, le contrôle de version, les journaux, les captures d'écran ou les fichiers générés. Demande-moi de définir `TYPESAFE_API_KEY` de façon privée quand c'est nécessaire.

**6. Installer et tester**

Installe Jev une seule fois avec la méthode prise en charge. Avant de modifier la configuration, lis les fichiers concernés du projet. Crée un contrat de décision compact pour le cas d'usage qui a le plus de valeur, avec : l'état, la question exacte, le type de réponse, les critères ou les options, le routage selon la confiance, le repli, la limite de relecture humaine, les données interdites, les champs du reçu et un jeu de test réaliste.

Lance d'abord un test hors ligne ou en mode fantôme. Puis lance trois cas : un cas évident, un cas ambigu et un cas qui doit être remonté à un humain. Vérifie à la fois le comportement de l'agent et le reçu de décision. Ne confonds pas un import du SDK, une réponse simulée ou une requête brute réussie à l'API avec une intégration qui fonctionne.

**7. Rendre l'usage futur naturel**

Ajoute une instruction concise, limitée au projet, dans le fichier d'instructions persistantes pris en charge par cet agent : `CLAUDE.md` pour Claude Code, `AGENTS.md` pour Codex, ou le fichier équivalent de règles ou de configuration pour Grok Bot, Cursor ou un autre agent. Préserve son contenu actuel.

L'instruction doit dire à l'agent d'envisager une petite décision Jev bornée avant une recherche coûteuse, la répétition d'une approche qui a échoué, le chargement de plusieurs outils, le choix entre des voies réellement différentes, ou la proposition d'une action lourde de conséquences. Garde les actions irréversibles derrière une confirmation humaine. Respecte `bypass jev`.

Relie l'instruction à un appel d'outil que l'agent peut réellement effectuer. Ne prétends pas qu'ajouter du texte suffit à garantir que Jev tournera.

**8. Prouver l'amélioration**

Termine par un rapport compact : ce que tu as trouvé, ce que tu as changé, les fichiers créés ou modifiés, les tests passés, si un appel réel à Jev a réussi, l'estimation du temps et des tokens économisés, les décisions qui restent à évaluer, les instructions de retour arrière, et les deux prochaines intégrations Jev qui valent un test.

Donne-moi trois prompts personnalisés à essayer ensuite. Ne déclare jamais l'intégration terminée sans preuve que l'agent a utilisé Jev pendant une vraie tâche.

**9. Mesurer la boucle**

Fais tourner le flux de travail amélioré sur au moins cinq vraies tâches. Compare l'ancien chemin et le chemin Jev sur les tokens, la latence, le coût, les relances et les interventions humaines. Ne garde un contrat de décision que s'il apporte un gain mesurable sans masquer les échecs.

Produis un reçu de décisions hebdomadaire avec : les décisions prises, la répartition de la confiance, les remontées à un humain, les faux positifs, l'argent économisé et le prochain contrat à régler. Si les chiffres ne s'améliorent pas, reviens en arrière au lieu de forcer Jev dans le flux de travail.

Utilise le skill TypeSafe. Avant d'écrire du code :

1. lis docs.typesafe.ai/llms.txt, puis les pages <SDK ou API HTTP> et <primitive>

2. comportement : <ce que l'appli affiche, sélectionne, modifie ou transmet>

3. liste les jugements, un par question, et marque ce qui reste dans le code

4. rédige instructions + critères, avec une option « aucune correspondance » sur chaque Choice

5. pose-les tous sur <état> en une seule requête

6. mets les questions et les seuils dans <fichier>, seuils en TODO tant qu'ils ne sont pas testés sur <jeu de cas>

N'utilise que les champs que tu as lus sur la page de l'API.

01 Orchestration multi-modèles par défaut

Pour toute demande de génie logiciel, agis automatiquement en architecte et en orchestrateur.

Objectif : mener le travail à bien de façon fiable, avec le modèle et le niveau de raisonnement minimaux nécessaires.

02 Jev, le modèle de décision

Jev est disponible comme modèle de décision et de contrôle.

Authentification : lis TYPESAFE_API_KEY dans l'environnement. N'affiche, n'expose, ne journalise et ne commite jamais cette clé.

Utilise Jev UNIQUEMENT pour des décisions bornées :
- classer la complexité d'une tâche
- choisir le niveau de raisonnement
- continuer ou s'arrêter
- décider d'une nouvelle tentative
- décider d'une escalade
- évaluer si le travail est terminé

N'utilise PAS Jev pour :
- écrire du code
- générer des correctifs
- concevoir l'architecture
- tout ce qu'un outil déterministe peut trancher

03 Routage initial

Avant d'implémenter, classe la tâche :

SMALL : Luna, raisonnement faible
MEDIUM : Luna, raisonnement moyen
HIGH : Luna, raisonnement élevé
ESCALATE : Sol, raisonnement élevé

Prends toujours la voie la plus basse qui suffit.

04 Vérification déterministe (règle critique)

Préfère une preuve déterministe au jugement d'une IA chaque fois que c'est possible.

Tests : lance les tests
Compilation : lance le compilateur
Types : lance le vérificateur de types
Lint : lance le linter
Code modifié : lance git diff

Ne demande jamais à Jev de déterminer ce qu'un logiciel peut déterminer.

05 Boucle de l'agent

Après chaque cycle d'implémentation :

- Inspecte le diff réel
- Lance les contrôles déterministes pertinents
- Rassemble des preuves concises
- Utilise Jev pour le jugement qui reste à porter
- Choisis : CONTINUE / RETRY / VERIFY / ESCALATE / COMPLETE

06 Chemin d'escalade

Luna Low > Luna Medium > Luna High > Sol High

N'escalade que si les preuves le justifient :
- les tentatives répétées échouent
- les tests continuent d'échouer
- du code sensible pour la sécurité a été modifié
- une incertitude d'architecture demeure
- la confiance de Jev est sous le seuil

N'escalade pas parce qu'un modèle plus fort est disponible.

07 Fin de tâche

N'annonce la fin que lorsque :
- le comportement demandé est implémenté
- les contrôles déterministes passent
- le diff correspond au périmètre demandé
- il ne reste aucun échec non résolu

Ne cache jamais une vérification qui a échoué.

Trouve dans cette base de code les décisions « à la Jev » : les endroits où le code doit, de façon répétée, (a) choisir parmi un petit ensemble d'options, (b) noter quelque chose selon une grille, ou (c) répondre à une question oui/non, et le fait aujourd'hui avec un appel à un LLM, une regex ou des if/else écrits à la main.

Pour chaque candidat, donne :
1. Le fichier et la fonction
2. La décision en une phrase
3. La ou les questions typées à poser (Choice / Score / Noul)
4. L'état à envoyer
5. Le nombre d'appels attendus par jour
6. Ce qui se passe quand la réponse est fausse

Liste uniquement les candidats. Ne propose pas de refactorisation.

Range le ticket de support dans exactement une catégorie.

Ticket :
J'ai été débité deux fois pour le même abonnement.

Étiquettes autorisées :
A = facturation
B = support technique
C = accès au compte

Renvoie uniquement l'étiquette.

Étiquette :

Ticket :
J'ai été débité deux fois pour le même abonnement.

Question :
Quelle catégorie correspond au ticket ?

Étiquettes autorisées :
A = facturation et paiements
B = support technique
C = accès au compte

Renvoie uniquement l'étiquette.
Étiquette :