Une mémoire, des images, et 97 % de tokens économisés !!!

Tu vas installer une architecture de travail persistante dans ce dossier. C'est un espace
que je vais réutiliser pendant des mois, avec plusieurs projets. Traite-le comme une
infrastructure, pas comme un dossier de fichiers.

Crée exactement ceci, rien de plus :

CLAUDE.md          — le fichier que tu liras à chaque démarrage
persona.md         — qui je suis
memory.md          — vide, avec une note disant que la mémoire vit dans les projets
_config/paths.json — la source de vérité des chemins
_rules/            — vide pour l'instant
Projects/          — vide
sessions/          — vide
_assets/           — vide
temp/              — vide

Règle centrale pour CLAUDE.md : c'est un ROUTEUR, pas une documentation. Il tient sous les
50 lignes. Il énonce les lois et dit où trouver les détails — il ne contient jamais les
détails eux-mêmes. Tu le liras en entier à chaque conversation : chaque ligne inutile me
coûte des tokens à vie. Écris-le dense, en style télégraphique, avec des abréviations.
C'est le fichier le plus lu du système, il doit être le plus compressé.

Il contient six sections, dans cet ordre :

1. Une ligne qui dit ce qu'est cet espace et que le détail vit dans _rules/
2. LOIS — laisse la section vide, je te la donne au prompt suivant
3. RÉPONSES — mes préférences de format quand tu me réponds. Pose-moi la question :
   est-ce que je veux des réponses courtes par défaut ? Un ton particulier ?
   Des développements complets seulement sur certains types de tâches ?
4. PERSONA — la règle du fichier persona.md (je te la donne au prompt 3)
5. ROUTES DE FICHIERS — où va quoi. Un résumé de 4 lignes, avec un renvoi vers le
   module détaillé. Ce sont des routes, pas un inventaire du dossier.
6. MODULES À CHARGER À LA DEMANDE — un tableau à deux colonnes : « Quand » | « Lire ».
   Vide pour l'instant, il se remplira d'une ligne à chaque nouveau savoir-faire.

Dans _config/paths.json, mets la racine et la liste des dossiers. Règle absolue : aucun
script que tu écriras ne contiendra jamais un chemin absolu en dur. Ils liront ce fichier.
C'est ce qui me permet de déplacer ou synchroniser ce dossier sans rien casser.

Montre-moi le CLAUDE.md avant de l'écrire.

Remplis la section LOIS de CLAUDE.md. Une seule loi, et c'est elle qui tient tout le reste :

CONFIRMER AVANT D'AGIR.
Aucune exécution sans deux conditions réunies : une demande explicite de ma part, ET une
description préalable de ce qui va se passer.

Avant tout effet de bord — écrire un fichier, en modifier un, lancer une commande qui
change quelque chose, appeler une API, générer une image, publier quoi que ce soit — tu
décris d'abord : quels fichiers, quelles commandes, quel diff, quel coût. Puis tu attends
que je dise « go ». Puis tu agis.

Pas d'auto-chaînage : un « go » vaut pour l'action décrite, jamais pour la suivante.

Lire est libre. Lire un fichier, chercher, lister, consulter le web ne demandent aucune
confirmation. Le frein est sur ce qui modifie, pas sur ce qui observe.

Écris-la tout en haut du fichier, visuellement marquée comme un invariant. Elle doit être
impossible à rater quand tu relis CLAUDE.md.

Crée persona.md, et déclare sa règle dans la section PERSONA de CLAUDE.md.

Le fichier contient deux choses distinctes :

1. Un bloc factuel en haut : comment m'appeler, ma langue de travail, mon métier, mon
   niveau technique.

2. En dessous, un journal daté, APPEND-ONLY.

Le journal est la partie qui compte. Sa règle : tu n'as JAMAIS le droit de modifier ni de
supprimer une entrée existante. Tu ne fais qu'ajouter à la fin, avec la date.

Son seuil d'entrée est haut. On n'y met pas ce sur quoi je bosse cette semaine. On y met
les formulations qui frappent, les idées qui restructurent une façon de voir, les
connexions inattendues. Si ça peut se dire n'importe quel jour, ça n'a pas sa place ici.

Écris ces deux règles DANS le fichier, en tête, pour qu'elles survivent à ton oubli.
Pose-moi les questions du bloc factuel maintenant.

Crée _rules/caveman.md.

C'est un format d'écriture compressé, réservé aux fichiers que TU relis et que je n'ouvre
jamais. Son but unique : payer le moins de tokens possible à chaque relecture.

Les règles :

- ANGLAIS télégraphique, quelle que soit la langue de notre conversation. Pas par
  préférence : le français se découpe moins bien en tokens, et un caractère accentué en
  coûte souvent le double d'un caractère ASCII. Sur un fichier relu à chaque chargement,
  l'écart se paye en boucle.
- Des SYMBOLES plutôt que des mots : → ✓ ✗ ≠ + @ ? >
- Zéro article. Abréviations agressives : cfg, img, gen, usr, sess, proj.
- Un fait par ligne. Dense. Zéro redondance.
- Aucun commentaire de section, sauf si l'ambiguïté coûterait plus cher que la note.

Exemple. Version normale :
"Nous avons finalement décidé de ne pas utiliser la bibliothèque X, parce qu'elle n'était
plus maintenue depuis 2023 et que son API allait probablement changer."

Version caveman :
"X lib rejected → unmaintained since 2023, API unstable"

Le périmètre, à écrire noir sur blanc dans le fichier : le caveman s'applique au corps des
fichiers dans lesquels je ne mets jamais le nez. Il ne s'applique JAMAIS à ce que je lis —
les en-têtes destinés à l'affichage, les titres, et surtout tes briefings.

La contrepartie compte autant que la règle : quand tu me RESTITUES du caveman, tu le
décompresses toujours en français normal, en phrases complètes. Le caveman est un format
de stockage, jamais un format de conversation. Je ne dois jamais avoir à le lire.

Ajoute la ligne correspondante dans le tableau de CLAUDE.md.

Crée _rules/memory-protocol.md. Il règle un seul problème : tu oublies tout entre deux
conversations, et je ne veux pas te réexpliquer mon contexte chaque matin.

Le modèle :

Une conversation se sauve à UN seul endroit, jamais deux. Zéro doublon — deux fichiers sur
le même sujet, ce sont deux vérités qui divergent.
- Si elle appartient à un projet → Projects/<nom>/memory.md
- Sinon → sessions/<nom>.md

Structure d'un memory.md de projet :
  ## État     — où on en est. Court.
  ## À faire  — les actions encore ouvertes
  ---
  puis dessous, l'archive longue : décisions, historique, contexte

Deux niveaux de lisibilité, et c'est le point qui compte :
- Les fichiers de sessions, je ne les ouvre jamais → corps en caveman.
- Les memory.md de projet vivent dans l'arborescence de mes projets, je les ouvre →
  français lisible.

Le fichier de mémoire d'un projet est protégé : on ne l'écrase jamais en bloc, on fusionne.

Ce module est la doctrine. Il ne fait rien tout seul : ce sont les commandes /save et /load
qui l'appliquent, on les écrit juste après.

Ajoute la ligne correspondante dans le tableau de CLAUDE.md.

Fabrique-moi la commande /save. C'est la moitié du pivot de tout le système.

Explique-moi d'abord comment on crée une commande personnalisée dans mon outil — demande-moi
lequel j'utilise si tu ne le sais pas.

Ce que /save doit faire :

1. CHOISIR SA CIBLE. Si un projet est actif → Projects/<nom>/memory.md. Sinon →
   sessions/<nom>.md. Jamais les deux.

2. CHOISIR ENTRE AJOUTER ET RÉÉCRIRE. Le principe qui tranche :
   le coût réel d'un fichier, ce n'est pas de l'écrire, c'est de le relire à chaque
   chargement futur.
   - apport purement additif → tu ajoutes
   - réécriture complète si : des actions « à faire » sont résolues, l'état est contredit,
     il y a des redondances, ou le corps dépasse la cinquantaine de lignes
   Tu ne laisses jamais traîner un item déjà fait : il serait relu, et repayé, à vie.

3. NE RIEN COÛTER. /save écrit du texte, rien d'autre. Pas d'appel à un service externe,
   pas de génération d'image, pas de réseau. Sauvegarder doit être gratuit et instantané,
   sinon je ne le ferai pas — et un système de mémoire que je n'utilise pas ne vaut rien.

4. CONFIRMER en une ligne : ce qui a été sauvé, où, en mode ajout ou réécriture.

Range la source dans skills/_sources/save/.

Fabrique-moi la commande /load. C'est l'autre moitié du pivot.

Ce qu'elle fait :

1. TROUVER LA CIBLE. /load <nom> cherche d'abord un projet Projects/<nom>/, sinon une
   session sessions/<nom>.md. Si rien n'existe : tu le dis et tu listes ce qui existe.
   Tu n'inventes pas, tu ne devines pas.

2. EN MODE PROJET, ne lire que le CLAUDE.md du projet et son memory.md. Rien d'autre. Pas
   les fichiers du projet, pas son contenu. J'ouvre une porte, je ne vide pas la pièce.

3. DÉCOMPRESSER. C'est le cœur de la commande. Les fichiers sont denses, parfois compressés,
   volontairement illisibles. Ton briefing, lui, est en français normal, en phrases
   complètes, comme un collègue qui me rattrape après deux semaines d'absence. Jamais un
   extrait brut du fichier, jamais de caveman à l'écran.

   Le format, court :
   - Sujet : une ou deux phrases
   - Où on en était : l'état et les décisions clés, reformulés en clair
   - À faire : les prochaines étapes, s'il y en a

4. RETENIR LA CIBLE. Après un /load, le contexte chargé devient actif : un /save sans
   argument met à jour le bon fichier, sans que j'aie à le renommer.

Range la source dans skills/_sources/load/.

Ajoute dans CLAUDE.md la règle des projets, puis applique-la.

Tout projet vit dans Projects/<nom>/ et contient exactement trois fichiers :

  CLAUDE.md  — les instructions PROPRES à ce projet, plus la carte de son contenu.
               Ce n'est PAS une copie du CLAUDE.md racine.
  memory.md  — État / À faire / archive, au format du protocole mémoire
  index.md   — l'annuaire du projet : une ligne par fichier, ce qu'il contient

Règle de chargement, et c'est elle qui fait tout le travail : quand j'ouvre un projet, tu
lis UNIQUEMENT son CLAUDE.md. Pas le memory.md, pas l'index.md, pas les fichiers. C'est moi
qui te dis ensuite quoi charger. Un projet ne doit jamais inonder ton contexte simplement
parce que je l'ai ouvert.

Ces trois fichiers sont protégés : jamais écrasés en bloc, toujours fusionnés.

Maintenant, crée-moi un projet nommé <NOM> qui porte sur <SUJET EN UNE PHRASE>.

Je veux transformer un savoir-faire en module réutilisable.

Le savoir-faire : <CE QUE TU VEUX POUVOIR REFAIRE — publier sur ton dépôt, générer une
image avec tel modèle et tels réglages, produire un document à ton format…>

Écris _rules/<nom>.md. Contraintes :

- Il commence par « > Chargé quand : <la situation exacte> ». C'est ce qui te dit quand
  l'ouvrir, et surtout quand ne pas l'ouvrir.
- Il contient la procédure exacte : commandes, paramètres, valeurs par défaut. Assez précis
  pour être rejoué sans réfléchir.
- Il contient les erreurs déjà rencontrées ET leur cause réelle. C'est la partie qui vaut le
  plus cher : elle m'évite de repayer deux fois le même bug.
- AUCUN secret. Les clés et tokens vivent dans un fichier séparé, référencé mais jamais
  recopié.

Puis ajoute UNE ligne dans le tableau de CLAUDE.md : quand | lire.

Le but : que le CLAUDE.md racine reste court quoi qu'il arrive. Il grossit d'une ligne par
savoir-faire, jamais d'un paragraphe.

Je veux que tu fasses un travail tout seul, à intervalle régulier, sans moi.

Le travail : <PAR EXEMPLE : chaque matin, chercher l'actualité sur mes sujets et écrire ce
que tu trouves dans un fichier>

Explique-moi d'abord comment planifier une tâche récurrente dans mon outil.

Puis applique le pattern du LANCEUR MINCE, seul point qui compte vraiment :
la tâche planifiée ne contient AUCUNE logique. Elle contient trois choses :
  1. le chemin du fichier qui porte la vraie logique
  2. l'ordre de l'appliquer à la lettre
  3. où écrire le résultat

La logique vit dans le projet concerné. Sinon j'ai deux versions du même travail qui
divergent en silence, et je ne sais plus laquelle tourne réellement.

Deux règles de robustesse :
- La tâche écrit son résultat dans un fichier. Elle ne m'envoie rien, ne me notifie pas.
  J'irai lire quand je veux.
- Si une source est indisponible, elle continue avec les autres et le signale. Elle ne rate
  jamais son exécution entière à cause d'un seul point bloqué.

{
  "mcpServers": {
    "fal-image": {
      "command": "npx",
      "args": ["-y", "fal-image-video-mcp"],
      "env": {
        "FAL_KEY": "TA_CLE_FAL_ICI",
        "DOWNLOAD_PATH": "C:\\Users\\toi\\Downloads",
        "AUTOOPEN": "false"
      }
    }
  }
}

Je veux te donner accès à un générateur d'images, de vidéos et de voix via FAL.

Explique-moi, étape par étape et pour mon système d'exploitation :
1. où créer un compte et générer une clé API sur fal.ai
2. dans quel fichier de configuration déclarer le connecteur, et où il se trouve
3. le bloc exact à y coller, avec un DOWNLOAD_PATH adapté à ma machine
4. comment vérifier que ça marche une fois Claude redémarré

Ensuite, écris-moi _rules/image-gen.md qui fige mes réglages par défaut :
- quel modèle j'utilise, et pour quel usage
- la qualité par défaut, et les rares exceptions
- où atterrissent les fichiers
- les erreurs connues et leur cause réelle

Ma clé API ne doit apparaître que dans le fichier de configuration. Jamais dans _rules/,
jamais dans un projet, jamais dans un fichier que je pourrais partager.