Système d'instructions personnalisées Claude (CLAUDE.md + extensions)

Contexte

Besoin de standardiser le comportement de Claude sur tous mes projets, sur mes deux comptes (Gmail pour la stratégie business, hlahutte@cobra.fr pour le dev Odoo/Shopify). Déclencheur immédiat : un incident de mise en prod Odoo la veille (merge de la branche preprod3 entière, qui contenait des dev mélangés des miens et de l'agence Irokoo, ce qui a cassé plusieurs choses), à graver en règle dure pour éviter la récidive.

Ce qui a été construit

• CLAUDE.md (base universelle, ~80 lignes) : les 4 principes Karpathy (réfléchir avant de répondre, simplicité d'abord, modifications chirurgicales, exécution pilotée par l'objectif) + règles de comportement général (ton casual, pas de préambules, honnêteté intellectuelle, web search obligatoire, gestion du contexte, document vivant).
• CLAUDE-strat.md (extension business, compte Gmail) : format prose par défaut, séparation strat/exécution, types de livrables, recherche concurrentielle marché audio, honnêteté business (risques avant opportunités), liste de ce que je ne veux PAS (bullshit bingo, frameworks plaqués type SWOT/AARRR).
• CLAUDE-dev.md (extension dev, compte cobra.fr) : règle dure en tête sur le déploiement Odoo ciblé (jamais merger preprod3 entière, toujours cherry-pick, question obligatoire avant tout déploiement), conventions Odoo (git, sync Shopify, matching barcode) et Shopify, discipline de code, section « Sujets en cours » vivante.
• Workflow de déploiement clarifié : CLAUDE.md en Project Instructions partout, extensions uploadées selon le compte.

Ce qui était difficile / inattendu

• Pivots successifs en cours de session : v1 partait sur l'optimisation tokens pour agents autonomes (legacy Jarvis/Paperclip), refondue quand j'ai expliqué ne plus utiliser le Mac Mini, puis encore quand j'ai précisé la dualité strat/dev. La qualité du résultat dépend de la clarté du contexte donné.
• Over-engineering écarté en temps réel : à plusieurs moments (agent de briefing hebdo, branche preprod-hugo perso), Claude m'a poussé vers la solution simple — application directe du principe Karpathy n°2.

Stack

Markdown. Inspiration : les 4 principes d'Andrej Karpathy sur le travail avec les LLMs et le concept de *Compound Engineering* de Boris Cherny (Anthropic) — chaque erreur devient une règle, le fichier s'améliore avec l'usage. Aucun code exécuté, juste de la documentation structurée.

Ce que ça illustre

Cas concret de « context engineering » pour un dirigeant non-technique. La valeur ne vient pas d'un usage ponctuel mais de la construction d'un environnement de travail personnalisé qui injecte du contexte business, des règles de comportement et des leçons apprises à chaque session. Le fichier devient un actif qui s'enrichit avec le temps — pour un DG qui veut élargir son périmètre (dev, SEO technique, stratégie) sans remplacer ses équipes.