Aller au contenu principal

Personnaliser Claude Code pour un vrai dépôt

Intermédiaire
What you'll learn
  • Transformer un checkout tout neuf en une configuration Claude Code ajustée en une vingtaine de minutes
  • Comprendre POURQUOI chacune des quatre personnalisations gagne sa place — CLAUDE.md, permissions, un hook, une commande
  • Écrire des règles de permissions qui réduisent les interruptions sur les actions sûres et bloquent net les actions risquées
  • Vérifier que chaque pièce fonctionne réellement au lieu de le supposer

Transformons un checkout tout neuf en une configuration Claude Code qui connaît votre projet et respecte vos règles — en une vingtaine de minutes. Nous allons enchaîner les fonctionnalités clés avec le raisonnement derrière chacune.

L'état final​

Étape 1 — Générer et élaguer CLAUDE.md​

Lancez /init pour rédiger un CLAUDE.md, puis réduisez-le à ce qui est vrai : la stack, comment lancer/tester/linter, les vraies conventions et les garde-fous (« lance les tests avant de considérer terminé », « ne touche pas à /generated »). Pourquoi : c'est la personnalisation au plus fort effet de levier — Claude le lit à chaque session.

Récupérez un modèle de départ dans les Modèles CLAUDE.md.

Étape 2 — Définir les permissions​

Ajoutez un .claude/settings.json (référence) qui pré-autorise les commandes sûres et répétitives et refuse les dangereuses :

{
  "permissions": {
    "allow": ["Read", "Bash(npm run test:*)", "Bash(npm run lint)", "Bash(git diff:*)"],
    "ask": ["Write", "Bash(npm install:*)"],
    "deny": ["Read(./.env)", "Bash(git push --force:*)"]
  }
}

Pourquoi : moins d'interruptions sur les actions sûres, des arrêts nets sur les actions risquées. Voir Permissions.

Étape 3 — Ajouter un hook de formatage​

Formatez automatiquement après chaque édition (hooks) :

{ "hooks": { "PostToolUse": [ { "matcher": "Edit|Write",
  "hooks": [ { "type": "command", "command": "f=$(jq -r '.tool_input.file_path'); npx prettier --write \"$f\" 2>/dev/null || true" } ] } ] } }

Pourquoi : un formatage cohérent, garanti — pas un « pense à le faire ».

Étape 4 — Ajouter une commande /commit​

Déposez la recette /commit de la Bibliothèque de commandes slash dans .claude/commands/. Pourquoi : un seul mot pour un workflow répétable.

Étape 5 — Utiliser le mode Plan pour la première vraie tâche​

Donnez un vrai objectif en mode Plan, passez le plan en revue, puis laissez-le s'exécuter. Pourquoi : construire la confiance en séparant la réflexion de l'action.

Vérifiez que ça marche​

Ne supposez rien — testez chaque pièce indépendamment. Chaque test isole une personnalisation, donc un échec vous dit exactement quel fichier corriger.

Guided walkthrough1 of 4
  1. Démarrez une NOUVELLE session et donnez une tâche normale. Claude devrait faire référence à vos conventions spontanément, sans que vous les colliez.

Lancer la première vraie tâche en mode Plan

Add pagination to the users list endpoint. Plan it first — I want to review before you touch anything.
Key takeaways
  • CLAUDE.md est la personnalisation au plus fort effet de levier parce que Claude le lit à chaque session — générez-le avec /init, puis réduisez-le à ce qui est réellement vrai
  • Les permissions sont un outil à double tranchant : pré-autorisez les commandes sûres et répétitives pour réduire les interruptions, et refusez les dangereuses pour obtenir des arrêts nets
  • Un hook rend le formatage garanti plutôt qu'un « pense à le faire » — un comportement imposé par le harness l'emporte sur un comportement demandé dans un prompt
  • Une commande slash transforme un workflow répétable en un seul mot
  • Le mode Plan sépare la réflexion de l'action, ce qui est la façon de construire la confiance avant de céder plus d'autonomie
  • Vérifiez chaque personnalisation avec son propre test pour qu'un échec pointe vers un seul fichier

Testez-vous

0/3
  1. Pourquoi CLAUDE.md est-il appelé la personnalisation au plus fort effet de levier ?
  2. Vous voulez que le formatage automatique soit garanti, pas simplement demandé. Quel est le bon mécanisme ?
  3. Dans l'exemple settings.json, pourquoi certaines commandes sont-elles dans « allow » et d'autres dans « ask » ?

Suite​