9 Blocs de Construction pour Exécuter Claude Code comme un OS Persistant à Travers 18 Entreprises

Un développeur sur r/ClaudeAI décrit l'exécution de 18 instances de Claude Code non pas comme des projets isolés, mais comme des instances d'un système d'exploitation partagé. Chaque instance gère une activité différente (stratégie, produit, site web marketing, veille de menaces, trois clients en consulting, marque personnelle), toutes partagent un squelette commun qui est mis à jour une fois et propagé de manière sélective.

Les 9 blocs de construction

1. Construire un squelette avec propagation sélective

• Au lieu de construire un projet par espace de travail, le développeur a créé un modèle contenant des plugins, règles, agents, hooks, schémas et commandes.
• Lors du lancement d'une nouvelle activité, le modèle est cloné. Chaque instance hérite de l'ensemble de l'OS mais diverge sur les fichiers canoniques, la mémoire, la sortie et l'état du projet.
• Le CLI de mise à jour synchronise les plugins, règles, agents, hooks et schémas ; il ne touche jamais à la mémoire, la sortie, le répertoire canonique ou mon-projet (ceux-ci s'accumulent par instance).

2. Déplacer l'état des prompts vers le code

• Les LLM ont du mal à se souvenir ; le code est conçu pour cela. L'état comme les règles de voix, les préférences de style, les mots interdits et les décisions récentes a été déplacé dans des serveurs MCP.
• Le linter de voix, le scoreur de leads, le validateur de planning, le suivi de boucle s'exécutent en Python et renvoient des données structurées.
• Règle empirique : si vous avez expliqué quelque chose à Claude plus de deux fois, cela devrait être du code.

3. Utiliser des reçus, pas des champs de statut

• Les champs de statut (ticket fermé, PRD livré, test réussi) ne sont pas fiables car le LLM peut prétendre n'importe quoi.
• Les flux de travail ont été reconstruits autour de reçus — un script écrit un enregistrement de vérification avant qu'un ticket puisse être marqué comme vérifié. Le modèle ne peut pas mentir sur le fait que le code a été exécuté ou non.

4. Construire une porte de vérification de câblage

• Les fonctionnalités à moitié construites pourrissent en silence dans les dépôts IA car rien ne casse.
• Une commande /wiring-check a été construite. Avant qu'une tâche ne soit terminée, elle vérifie que chaque nouvelle compétence a un déclencheur, chaque nouveau hook se trouve dans settings.json, chaque nouvel outil MCP réside dans le serveur, chaque nouveau fichier bus a un producteur et un consommateur.
• "Je pense que ça marche" échoue à la porte. "J'ai exécuté X, j'ai obtenu Y" passe.

5. Faire en sorte que les règles se chargent automatiquement, pas via des commandes slash

• Les règles dans .claude/rules/ se chargent automatiquement. La règle de voix s'active sur le texte sortant, la règle AUDHD sur tout ce qui est actionnable, la règle de réaction sociale lors du partage du post de quelqu'un d'autre.
• Aucun effort de mémorisation ou de volonté requis.

6. Linter le style dans le code, pas en prose

• Un document de voix était ignoré par Claude la moitié du temps. La liste de mots interdits a été déplacée dans un scanner Python qui bloque les emdashes, les mots hype IA et plus de 40 autres indices.
• "Le modèle ne peut pas contourner une regex en parlant."

7. Suivre les dépendances des fichiers avec un graphe

• Les fichiers canoniques se réfèrent les uns aux autres. Un ripple-graph.json cartographie les dépendances. Modifier les talk-tracks signale l'état actuel et le playbook d'engagement pour révision.

8. Enchaîner les sessions avec des passations et de la mémoire

• "Les sessions sont des brouillons. Le travail est tout ce qui survit à la session."
• Chaque session se termine par /q-wrap, qui écrit un document de passation, une mise à jour mémoire et un reçu de statut. /q-morning lit les trois.

9. Traiter l'environnement comme un substrat, pas un éditeur

• La plupart des développeurs considèrent Claude Code comme un éditeur plus intelligent. Le changement de paradigme survient lorsque vous cessez de considérer les sessions comme l'unité de travail et commencez à envisager l'ensemble de l'environnement comme un substrat sur lequel construire.

Cette approche s'adresse aux développeurs qui souhaitent passer à l'échelle avec Claude Code sur plusieurs projets sans duplication ni fuites d'état. Le fil complet inclut une discussion sur les détails d'implémentation et les compromis.