Command Palette

Search for a command to run...

Mon setup Claude Code en 2026

🇬🇧EN

CLAUDE.md, 40 skills, 15 rules contextuelles, hook RTK (276M tokens économisés) et un repo de config portable. Mon setup Claude Code réel avec fichiers.

27 min de lecture
claude-codesetupskillshooksmcpconfigurationproductivité
Schéma du setup Claude Code avec CLAUDE.md, 15 rules, 40 skills et hooks RTK

J’utilise Claude Code comme outil principal de développement depuis début 2025. Après des centaines de sessions sur des projets Rust, TypeScript et React, j’ai construit une configuration que je fais évoluer chaque semaine. Cet article montre ce setup tel qu’il est aujourd’hui, avec les fichiers réels.

La structure : où vit la config

Tout part de ~/.claude/. C’est le répertoire global de Claude Code. Voici comment le mien est organisé :

~/.claude/
  CLAUDE.md              # instructions globales
  settings.json          # modèle, hooks, permissions, skill overrides
  RTK.md                 # référence MCP RTK (chargée via @RTK.md)
  agents/
    netir-reviewer/      # agent custom de review Rust
  skills/                # symlinks vers le repo de config
    blog -> .../global/skills/blog/
    commit-push -> .../global/skills/commit-push/
    netir-cpm -> .../projects/netir/skills/netir-cpm/
    ...

L’astuce : les skills sont des symlinks vers un repo Git de configuration que je maintiens à part. Ça permet de versionner, synchroniser entre machines, et séparer les skills globaux des skills projet.

CLAUDE.md : le fichier le plus important

Le CLAUDE.md global est chargé dans chaque session. C’est là que je mets les règles qui s’appliquent partout, quel que soit le projet.

Le mien fait moins de 30 lignes. Chaque ligne a été ajoutée après un problème réel :

## Langue française -- Orthographe stricte
- Toujours répondre en français avec tous les signes diacritiques corrects.
- INTERDIT d'écrire sans accents.

- Never launch subagents or delegate tasks unless the user explicitly asks.
- Output code first, explanation after - only if non-obvious.
- No compliments or affirmations in code reviews. State the issue, show the fix, stop.
- No em dashes, smart quotes, or decorative Unicode.

## Git & GitLab
- Simple feature branch workflow: feature branches merge into main.
- Always use conventional commit messages.

@RTK.md

Quelques points :

  • La règle de langue est la première parce que sans elle, Claude répond en anglais ou oublie les accents après compaction de contexte.
  • “Never launch subagents unless asked” empêche Claude de déléguer à des sous-agents quand ce n’est pas nécessaire. Sans cette règle, il lance des agents pour des recherches simples et consomme du contexte pour rien.
  • @RTK.md est une référence vers un fichier séparé qui documente les commandes RTK. Claude le charge automatiquement quand il a besoin du contexte.

Les rules : des instructions contextuelles

Les rules sont des fichiers Markdown dans ~/.claude/rules/ (ou dans le repo de config). La différence avec CLAUDE.md : elles ont un header paths qui les active uniquement sur les fichiers concernés.

J’en ai 15. Voici les plus utiles :

Discipline de code

---
paths: "**/*.{rs,ts,tsx,jsx,js,sql,toml}"
---

# Discipline de code

## Prior art - chercher avant d'écrire
Avant d'écrire un helper ou une abstraction : grep 2-3 variantes
du concept. Si un équivalent existe, le réutiliser.

Cette règle s’active sur tous les fichiers de code. Elle empêche Claude de recréer des utilitaires qui existent déjà dans le projet.

Sécurité

---
paths: "**/*.{rs,ts,tsx,sql,toml,yml,yaml},**/Dockerfile"
---

- Secrets: never hardcoded. Use env vars or vault.
- Injections - zero tolerance: Always use parameterized queries.
- JWT stateless by default. Short-lived access + long-lived refresh.
- HTTP security headers: CORS, X-Content-Type-Options, HSTS, CSP.

Anti “fake done”

# Agent Verification -- 11 "Fake Done" Shortcuts

Before marking any task as complete, verify the diff against each shortcut.
If any applies, the task is NOT done.

1. Relaxed tests - assertions weakened to make red go green
2. Swallowed errors - try/catch that hides the failure
3. Stub returns - hardcoded return values
4. Comment-as-fix - the bug is now a TODO
5. Happy-path only - 500s, empty inputs unhandled
...

Celle-là est spécifique aux agents. Quand Claude marque une tâche comme terminée, il doit vérifier son propre diff contre ces 11 patterns. Ça attrape les cas où le code compile mais ne résout pas le vrai problème.

Les autres rules couvrent : imports Rust, architecture en couches, migrations de base de données, pièges JavaScript/TypeScript, performance, refactoring, SQLx compile-time, et testing.

Les trois couches de configuration Claude Code : CLAUDE.md toujours charge, Rules charge si paths match, Skills charge a la demande

Les skills : des commandes slash sur mesure

Les skills sont des fichiers SKILL.md dans des dossiers sous ~/.claude/skills/. Chaque skill définit une commande slash (ex: /commit-push) avec des instructions détaillées.

J’ai 55 skills installés dont 40 actifs (15 désactivés via skillOverrides dans settings.json). Ils se répartissent en trois catégories :

Skills de workflow quotidien

  • /commit-push - commit avec message conventionnel auto-généré + push en une commande
  • /cpm - commit, push et création de Merge Request GitLab en une commande
  • /dev-pipeline - plan, implémentation, lint, test, review, ship - le pipeline complet
  • /lint-check - cargo fmt && cargo clippy && cargo check avec auto-fix
  • /work-on-issue - fetch une issue GitLab, assign, plan, implémente, teste, vérifie

Skills de review et qualité

  • /security-audit - audit OWASP top 10 sur le codebase
  • /systematic-debugging - méthodologie de debug structurée
  • /netir-qa-swarm - 4 reviewers en parallèle sur une MR (architecture, sécurité, qualité Rust, patterns métier)
  • /netir-review-triage - trie les commentaires de review en actionable/nit/ambiguous

Skills de contenu

  • /blog - pipeline complet de création d’articles (recherche, rédaction, SEO, scoring)
  • /linkedin-post-coach - coaching interactif pour écrire un post LinkedIn
  • /useful-for-me - analyse un repo/outil externe et dit s’il peut servir sur mes projets

Skills projet-spécifiques

Le setup Netir illustre bien les skills par projet. Ces skills sont dans projects/netir/skills/ et ne s’activent que dans le dossier Netir :

netir-cpm          # CPM avec conventions Netir (labels, reviewer)
netir-qa-swarm     # review multi-agent
netir-review-triage # tri des reviews
netir-alert-triage # tri des alertes monitoring
netir-tech-debt    # analyse de dette technique
netir-next         # choix de la prochaine tâche

Un skill c’est juste un fichier Markdown avec des instructions. Voici un extrait simplifié de /commit-push :

# Commit & Push

1. git status pour voir les fichiers modifiés
2. git diff pour analyser les changements
3. git log -5 pour le style de commit existant
4. Générer un message conventionnel (feat/fix/refactor...)
5. git add des fichiers pertinents
6. git commit
7. git push

La puissance vient de la composition : /dev-pipeline appelle en interne /lint-check, puis enchaîne avec la review et le commit.

Désactiver les skills inutiles

Les 15 skills désactivés le sont dans settings.json :

{
  "skillOverrides": {
    "cost-estimate": "off",
    "email-campaigns": "off",
    "tdd": "off",
    "teach": "off"
  }
}

Ça évite de polluer l’autocomplétion et empêche Claude de les invoquer involontairement.

Les hooks : automatiser sans y penser

Les hooks sont des commandes shell exécutées automatiquement à certains événements. Le plus important dans mon setup :

L’intégration RTK

RTK (Rust Token Killer) est un outil open source qui s’intègre à Claude Code via un hook PreToolUse. Il intercepte les commandes Bash et filtre les outputs pour réduire la consommation de tokens.

La configuration est une seule entrée dans settings.json :

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "rtk hook claude"
          }
        ]
      }
    ]
  }
}

RTK s’exécute avant chaque commande Bash. Il intercepte les commandes CLI (git status, find, grep, ps aux…) et les réécrit pour passer par son proxy de filtrage. Résultat : les outputs CLI sont filtrés automatiquement, sans que Claude ou moi n’ayons à y penser.

Les chiffres sur mon setup actuel :

Total commands:    39 646
Tokens saved:      276.4M (86.8%)
Top commands:
  rtk read    3 067 appels   217.8M tokens économisés
  rtk grep    5 408 appels    13.8M tokens économisés
  rtk find      573 appels    11.8M tokens économisés

Sur Opus ($15/M tokens en input), 276 millions de tokens économisés représentent environ 4 100 $ d’économies. Le hook se rentabilise dès la première session.

J’ai aussi construit MCP RTK, un proxy complémentaire qui applique le même principe de filtrage aux réponses des serveurs MCP (GitLab, Grafana, Sentry…).

Les agents custom

Les agents sont des fichiers dans ~/.claude/agents/. Ils définissent un profil spécialisé avec des outils restreints.

J’ai un seul agent custom : netir-reviewer, un reviewer de code Rust spécifique au projet Netir. Il vérifie l’architecture en couches, les conventions SQLx, la gestion d’erreur, les imports, l’enregistrement OpenAPI, et le tracing.

La différence entre un skill et un agent : le skill donne des instructions à la session principale, l’agent est une session séparée avec son propre contexte et ses propres outils. Un agent de review n’a accès qu’à Read et Grep, pas à Edit ou Write - il ne peut pas modifier le code, seulement le lire et signaler des problèmes.

Le repo de configuration

Tout ce setup est géré dans un repo Git privé :

~/Documents/dev/claude/personal-config/
  install.sh           # script de setup (symlinks, copies)
  global/
    CLAUDE.md           # instructions globales
    rules/              # 15 fichiers de règles
    skills/             # skills globaux (blog, commit-push, etc.)
  projects/
    _template/          # template pour nouveaux projets
    netir/              # config spécifique Netir
      agents/
      rules/
      skills/
    jarvis/             # config spécifique Jarvis

install.sh crée les symlinks depuis ~/.claude/skills/ vers le repo. Quand j’ajoute un skill ou modifie une règle, un git pull sur une autre machine suffit pour synchroniser.

Le template projet

Le dossier _template/ contient une structure de base pour démarrer un nouveau projet avec Claude Code :

cp -r projects/_template projects/mon-nouveau-projet
# Adapter les rules et skills au projet
./install.sh

Ce que j’ai appris

Après des mois d’itération sur cette config :

Garder CLAUDE.md court. Les premières versions faisaient 200+ lignes. Claude les survolait et oubliait les règles. Moins de 30 lignes bien choisies sont plus efficaces qu’un document exhaustif.

Les rules contextuelles valent mieux qu’un gros CLAUDE.md. Charger les règles Rust uniquement sur les fichiers .rs économise du contexte et évite les confusions entre langages.

Désactiver les skills inutiles. 55 skills c’est trop. Les 15 désactivés ne servent pas à mes workflows actuels. Les garder actifs ralentit l’autocomplétion et ajoute du bruit.

Un seul hook bien placé suffit. Le hook RTK sur PreToolUse couvre 90% des besoins d’optimisation. Pas besoin de hooks complexes sur chaque événement.

Versionner la config. Un repo Git pour la config Claude Code paraît excessif au début. En pratique, ça permet de revenir en arrière quand un changement casse quelque chose, et de partager entre machines sans friction.

Le setup continue d’évoluer. Chaque friction répétée dans une session Claude Code devient un candidat pour une nouvelle règle, un nouveau skill, ou un ajustement de hook. Pour aller plus loin : mon guide sur écrire des skills efficaces détaille les patterns et anti-patterns, et la page de mes projets liste les autres outils que j’ai construits autour de cet écosystème.