Trois espaces de stockage, quatre niveaux, un seul nom de dossier. Une fois le motif repéré, tout le modèle de configuration tient en une idée.
Nous le construisons couche par couche. Chaque image reprend la précédente avec un élément de plus.
Il n'y a ni base de données de mémoire ni profil au niveau du compte. Trois choses portent le nom de mémoire, elles ont des auteurs différents, et toutes les trois sont du texte brut sur votre propre machine.
Stockage local ne veut pas dire traitement local. La copie durable reste sur le poste de travail, mais quand une session charge l'un de ces fichiers, son contenu part vers l'API avec le prompt, exactement comme n'importe quel fichier source que Claude lit.
Dans votre dossier personnel, il y a un dossier nommé .claude. C'est là que se trouve votre version de tout : vos instructions, vos procédures, et la mémoire que Claude conserve pour chaque dépôt.
Un dossier par dépôt sous projects\, donc chaque worktree et chaque copie du même dépôt partage une seule mémoire. Deux développeurs sur le même code construisent des mémoires séparées, et aucun ne voit celle de l'autre.
Pas une illustration. Un portable qui tourne, débarrassé du bazar d'exécution.
$ ls -R ~/.claude ~/.claude/ ├── CLAUDE.md vos préférences permanentes ├── projects/ un dossier par dépôt │ ├── -home-vous-Projects-alpha/ memory/ la mémoire automatique est ici │ │ └── *.jsonl transcriptions │ └── -home-you-Projects-beta/ permissions, hooks └── skills/ vos procédures ├── agent-guardrails/
Tout ce qui figurait sur la diapositive précédente est ici. Rien de caché, rien que vous ne puissiez ouvrir.
Un second .claude vit dans le code lui-même, et il est commité. C'est toute la différence entre une habitude que vous avez et une norme que votre équipe a.
L'emboîtement parle d'audience, pas de disque. Un dépôt n'est pas à l'intérieur de votre dossier personnel. Il est dessiné à l'intérieur parce qu'il touche moins de monde, et c'est là la variable à lire sur cette image.
Il existe deux autres niveaux, un à l'extérieur du vôtre et un à l'intérieur du dépôt. Quatre au total, et la seule chose qui les distingue, c'est l'endroit où le dossier est posé.
Les fichiers d'instructions s'additionnent au lieu de se remplacer, lus de l'extérieur vers l'intérieur.
Concept cléL'endroit où un fichier est posé décide à qui il s'applique. Même nom de dossier, quatre audiences.
Certains de ces fichiers sont lus au début de chaque session et vous coûtent du contexte, qu'ils soient pertinents ou non. Les autres restent sur le disque jusqu'à ce que Claude aille les chercher.
C'est tout l'argument pour garder un CLAUDE.md court. Un skill ne contribue que sa description d'une ligne tant que Claude ne s'en sert pas : une longue procédure est donc gratuite jusqu'au moment où on en a besoin.
Un skill est un dossier qui contient un SKILL.md : une procédure écrite. Rien de nouveau à apprendre sur son emplacement, puisqu'il va exactement là où va tout le reste.
Mettez une procédure dans le dépôt et chaque développeur qui le clone l'a. Mettez le même fichier dans votre dossier personnel et elle ne sert qu'à une personne. Ce choix, et rien d'autre, est votre mécanisme de diffusion.
La distinction qui évite le plus d'ennuis. Les deux vivent dans les mêmes quatre dossiers, et un seul est un contrôle.
On prend celui de gauche quand il faudrait celui de droite, puis on s'étonne que ça tienne neuf fois sur dix au lieu de dix. Si ce doit être impossible et non déconseillé, ce n'est pas une consigne écrite.
Vérifiez tout cela vous-même : /memory liste les fichiers, /context montre ce qui est réellement chargé, /doctor vous dit pourquoi quelque chose ne prend pas effet.
tutto.one/praxis · daniel@tutto.one