Faire de Claude Code un outil du quotidien : Claude.md, Skills, Subagents, Plugins, MCP

 (arps18.github.io)
1 points par GN⁺ 4 시간 전 | 1 commentaires | Partager sur WhatsApp
  • La productivité de Claude Code dépend bien plus de la manière d’accumuler et de valider la mémoire, les commandes personnalisées, les sessions parallèles et la configuration du projet que du simple prompt
  • CLAUDE.md doit être géré comme une infrastructure cumulative courte et centrée sur la validation ; ajouter une règle après une erreur permet de réduire les répétitions de cette même erreur
  • .claude/ est un système de configuration hiérarchique qui contient CLAUDE.md, rules, skills, commands, agents et la configuration MCP, avec une séparation entre portée projet et portée globale
  • Les Skills transforment les tâches répétitives en expertise réutilisable, et les subagents effectuent revue, débogage et migration dans un contexte séparé
  • En combinant plugins, MCP, /goal, /rewind, /batch et même des worktrees parallèles, Claude Code devient un agent de développement qu’on configure et qu’on exploite

Traiter Claude Code comme un agent vérifiable

  • Les écarts de productivité avec Claude Code viennent moins d’un simple prompt que de la façon dont on accumule mémoire, commandes personnalisées, sessions parallèles et configuration du projet
  • Le principe central consiste à permettre à Claude de vérifier ses propres résultats, et Boris Cherny comme l’équipe d’Anthropic estiment que cette approche seule améliore la qualité d’un facteur 2 à 3
  • Le flux de travail recommandé suit l’ordre exploration → planification → implémentation
    • Le mode planification, accessible avec Shift+Tab deux fois, est adapté à une exploration en lecture seule
    • Il est recommandé de lire les fichiers, de comprendre le flux et le modèle de données, puis d’établir un plan avant d’exécuter
    • Le mode planification est utile pour les tâches qui touchent plusieurs fichiers, et peut être ignoré pour de petites modifications
  • Le mode planification peut être utilisé comme un document de conception révisable avant l’implémentation
    • Un premier Claude peut rédiger le plan, puis un second Claude dans une nouvelle session peut le relire comme un staff engineer sans biais
    • Si l’implémentation dévie, il est pertinent de revenir au mode planification et de refaire le plan en incluant l’étape de validation
    • Ctrl+G permet d’ouvrir le plan de Claude dans l’éditeur et de le modifier manuellement avant l’implémentation
  • Des références précises sont plus efficaces que des consignes vagues
    • Au lieu de « regarde le module auth », il vaut mieux désigner directement un fichier comme @src/auth/login.py
    • Pour les erreurs, mieux vaut les transmettre par pipe avec cat error.log | claude que les coller dans le prompt
  • Pour Cat Wu, Claude Code donne les meilleurs résultats lorsqu’on le traite non comme un pair programmer guidé ligne par ligne, mais comme un ingénieur à qui l’on délègue
  • Quand Claude se trompe, on peut ajouter à la fin du prompt « Update CLAUDE.md so you do not repeat this. » afin de laisser une règle qui évite de reproduire la même erreur

Le répertoire .claude et la hiérarchie de configuration

  • .claude/ n’est pas simplement un dossier pour CLAUDE.md, mais un système de configuration hiérarchique
  • La configuration se divise en deux portées
    • Portée projet : placée dans .claude/ du dépôt, puis commitée dans git pour être partagée avec l’équipe
    • Portée globale : placée dans ~/.claude/ et appliquée à tous les projets de la machine locale
  • On peut comprendre les fichiers de projet comme une description du projet, et les fichiers globaux comme un modèle des préférences et méthodes de travail de l’utilisateur
  • Rôle des principaux fichiers
    • CLAUDE.md : instructions chargées à chaque session, au niveau projet comme global
    • CLAUDE.local.md : notes personnelles propres au projet, à inclure dans le gitignore
    • settings.json : permissions, hooks, variables d’environnement, configuration du modèle par défaut
    • settings.local.json : surcharge personnelle, automatiquement ajoutée au gitignore
    • .mcp.json : configuration des serveurs MCP partagée par l’équipe au niveau projet
    • skills/<name>/SKILL.md : prompt réutilisable appelé avec /name
    • commands/*.md : commande slash définie dans un seul fichier
    • agents/*.md : définition des subagents
    • rules/*.md : consignes par thème, applicables aussi par chemin
  • CLAUDE.md est chargé en cascade
    • Dans un monorepo, root/CLAUDE.md et root/services/billing/CLAUDE.md peuvent être chargés ensemble
    • Cela convient aux bases de code où les conventions varient selon les dossiers
  • .claude/rules/*.md est adapté aux consignes par chemin
    • Si une règle n’est nécessaire que dans un dossier de migrations, il vaut mieux la placer dans .claude/rules/migrations.md avec un glob plutôt que de gonfler CLAUDE.md pour toute la session
  • Pour de nouveaux usages, les skills sont recommandés plutôt que les commands
    • .claude/commands/*.md et .claude/skills/<name>/SKILL.md permettent tous deux de créer des commandes slash
    • Les skills prennent en charge des fichiers auxiliaires, disable-model-invocation, les outils autorisés et les overrides d’agents
  • claude project purge ~/path/to/repo --dry-run permet d’inspecter l’état local conservé par Claude pour un projet donné

Garder CLAUDE.md court et centré sur la validation

  • Comme CLAUDE.md est chargé au début de chaque session, une mauvaise rédaction pousse Claude à répéter les mêmes erreurs, tandis qu’une bonne rédaction améliore fortement les résultats pour un même prompt
  • Le principe le plus important est de le garder court
    • Il est recommandé de se demander pour chaque ligne : « Si je supprime cette ligne, Claude fera-t-il une erreur ? » ; si la réponse est non, il faut la supprimer
  • Laisser Claude écrire lui-même ses règles produit un effet cumulatif
    • Quand Claude se trompe, lui dire « Update CLAUDE.md so you do not repeat this. » lui permet de résumer l’erreur sous forme de règle précise
    • En répétant cela pendant plusieurs semaines, les pièges du projet s’accumulent sous forme de liste de règles
  • Dans la pratique, le CLAUDE.md de l’équipe Claude Code se concentre sur les commandes de build et l’ordre de validation
    • Ils utilisent bun et non npm
    • Le fichier précise l’enchaînement : typecheck rapide après les changements, tests, lint avant commit, validation complète avant PR
    • Il n’inclut ni préférences de style, ni visite guidée de la base de code, ni généralités
  • On peut aussi ajouter directement des règles depuis les commentaires de PR avec @claude
    • Exemple : @claude add to CLAUDE.md to never use enums, always prefer literal unions
    • La revue de PR alimente ainsi l’amélioration de CLAUDE.md et crée une dynamique de « Compounding Engineering »
  • Un bon CLAUDE.md se concentre sur les informations suivantes
    • Style de code : utiliser les modules ES plutôt que CommonJS
    • Workflow : exécuter bun run typecheck, ne jamais pousser directement sur main
    • Architecture : les routes API doivent impérativement passer par un middleware donné
    • Gotchas : différence entre User et UserRecord, ou le fait que formatCurrency suppose l’USD
  • Éléments à ne pas mettre dans CLAUDE.md
    • Conventions standard du langage
    • Explications de la base de code fichier par fichier
    • Longs tutoriels
    • Documentation API
    • Contenu qui change souvent
  • Des formulations comme IMPORTANT ou YOU MUST peuvent améliorer le respect des consignes, mais doivent rester rares pour conserver leur poids
  • La syntaxe @path permet d’importer d’autres fichiers afin de garder CLAUDE.md court tout en reliant les détails
    • Exemple : See @README.md for project overview and @package.json for scripts.
    • Exemple : @~/.claude/my-preferences.md

Accumuler le feedback personnel avec CLAUDE.local.md

  • CLAUDE.local.md est chargé au même endroit et de la même manière que CLAUDE.md, mais ne doit pas sortir de la machine locale et doit être ajouté à .gitignore
  • Si l’on place immédiatement les commentaires de revue de PR dans CLAUDE.local.md, le feedback personnel récurrent s’accumule dans un fichier de règles personnel
  • Exemples de règles
    • Tout nouveau consumer SQS doit avoir une DLQ et des alertes dans la même PR
    • Préférer Optional<T> à un retour null
    • Les tests d’un nouvel endpoint doivent inclure un cas d’échec d’authentification
    • Lorsqu’on ajoute un endpoint, il faut aussi mettre à jour la spec OpenAPI
  • Il est préférable de séparer dans ce fichier le feedback propre au projet et les éléments liés à la correction d’habitudes personnelles
  • Après quelques semaines, il faut retirer les éléments déjà devenus des habitudes et ne conserver que ce qui est encore en cours d’apprentissage

Skills : une unité d’expertise réutilisable

  • Les Skills sont des unités d’expertise réutilisables qui transforment Claude Code d’un « agent capable de tout faire » en un agent performant sur des tâches de projet précises.

  • Structure d’un Skill

    • un skill est un dossier situé sous .claude/skills/<name>/ ou ~/.claude/skills/<name>/
    • le fichier SKILL.md dans ce dossier contient le frontmatter et les instructions
    • le nom du dossier devient une commande slash
    • par exemple, si vous créez ~/.claude/skills/summarize-changes/SKILL.md, alors /summarize-changes devient disponible dans toutes les sessions

  • Pourquoi les Skills sont puissants

    • Divulgation progressive : au démarrage de la session, seule la description du frontmatter est chargée, tandis que le SKILL.md complet et les fichiers auxiliaires ne sont chargés qu’en cas de besoin réel
    • Organisation par dossier : il est possible de regrouper ensemble des templates, documents de référence, scripts et paramètres
    • Shell inline : les lignes commençant par ! exécutent une commande et injectent sa sortie au moment de l’appel

  • Options du frontmatter

    • description : explique quand utiliser ce skill
    • disable-model-invocation: true : permet de l’exécuter uniquement lorsque l’utilisateur saisit explicitement /my-skill
    • allowed-tools : limite les outils utilisables comme Read, Grep, Bash
    • agent : permet une exécution dans un mode d’agent spécifique
    • pour les skills avec effets de bord, comme le déploiement, disable-model-invocation: true est approprié

  • Exemple de skill pour les conventions d’une API Go

    • un skill pour générer le scaffold d’un nouveau handler HTTP dans une équipe de services Go peut regrouper SKILL.md, templates/handler.go.tmpl et examples/healthz.go
    • des exemples de règles peuvent contenir des conventions propres au projet, comme Go 1.22 et le routeur chi, les requêtes typées sqlc, le logging structuré zap, ou une préférence pour les assertions testify et les tests table-driven
    • des exemples de gotchas peuvent éviter des erreurs répétées, par exemple le fait que chi.URLParam renvoie "" pour un paramètre manquant, que httperr.Wrap n’écrit pas de logs, ou que pgtype.Text nécessite une vérification de .Valid

  • Skills à installer

    • mattpocock/skills : dépôt populaire de skills avec environ 100k stars
      • /grill-me : interroge le plan avant d’écrire du code
      • /tdd : impose strictement le cycle red-green-refactor
      • /diagnose : débogue dans l’ordre reproduction, minimisation, hypothèse, correction, test de régression
      • installation : npx skills@latest add mattpocock/skills
    • Jeffallan/claude-skills : propose 66 profils par langage, dont go-pro, python-pro, java-architect, typescript-pro, rust-engineer, sql-pro
    • skills officiels d’Anthropic
      • /code-review : quatre agents parallèles auditent le diff et ne remontent que les constats fondés sur un score de confiance
      • /simplify : examine le code récent sous l’angle de la réutilisabilité et de l’efficacité
      • /batch : répartit une migration entre plusieurs agents parallèles et laisse chacun travailler dans son propre worktree
      • /webapp-testing : permet à Claude de tester une application web locale avec Playwright
    • il est préférable de transformer en skill toute tâche répétée plus d’une fois par jour
    • si les skills sont commités dans git, ils deviennent une connaissance organisationnelle de l’équipe, et un nouvel ingénieur récupère immédiatement l’ensemble des pratiques accumulées en clonant le dépôt

Subagents : faire travailler de manière ciblée dans un contexte séparé

  • un subagent s’exécute avec sa propre fenêtre de contexte et ses propres autorisations d’outils, puis renvoie un résumé
  • sa valeur clé est qu’il peut lire de nombreux fichiers sans remplir le contexte de la session principale
  • un subagent est un fichier Markdown sous .claude/agents/ ou ~/.claude/agents/, avec name, description, tools et model déclarés dans le frontmatter

  • Configuration de l’agent /pr-review

    • on peut le définir pour comparer le diff de la branche courante avec main afin de repérer bugs, problèmes de sécurité, edge cases manquants et violations des conventions du projet
    • on lui accorde des permissions orientées lecture avec tools: Read, Grep, Glob, Bash
    • avec model: opus, on peut utiliser un modèle plus robuste pour les revues à haut risque
    • le processus se compose de git diff main...HEAD, git log main..HEAD --oneline, lecture complète des fichiers, puis comparaison avec CLAUDE.md, CLAUDE.local.md et .claude/rules/
    • la sortie peut être regroupée en Critical / High / Medium / Low, inclure le fichier, la ligne, le problème et le correctif suggéré, puis se terminer par SHIP, FIX FIRST ou REWORK

  • Concevoir pour améliorer le ratio signal/bruit

    • si le reviewer modifie lui-même le code, il risque de développer un biais en faveur de sa propre correction ; des outils en lecture seule sont donc adaptés
    • le bruit diminue si une section « Do NOT flag » précise d’exclure les préférences de style non inscrites dans les règles du projet, les suggestions de refactorisation de code fonctionnel et les éléments hors du diff

  • Modèles de subagents fréquemment utilisés

    • l’équipe Claude Code versionne build-validator, code-architect, code-simplifier, oncall-guide, verify-app
    • security-reviewer : vérifie les injections, l’auth, les secrets et la désérialisation non sécurisée
    • test-writer : génère des tests et forme une boucle avec code-reviewer
    • debugger : remonte d’un test en échec jusqu’à la cause racine
    • performance-auditor : profile les flux et les requêtes
    • migration-writer : génère des migrations DB conformes aux conventions du projet
    • release-notes-writer : rédige un changelog à partir de l’historique des commits
    • faire implémenter par la session A puis réviser par un subagent code-reviewer dans un nouveau contexte permet de réduire le biais d’implémentation
    • en ajoutant isolation: worktree dans le frontmatter, il est possible d’exécuter le subagent dans un worktree git séparé, ce qui est utile pour répartir une migration entre plusieurs agents parallèles

Plugins et Marketplace

  • Les plugins regroupent skills, hooks, subagents et serveurs MCP dans une unité installable unique
  • Il est possible d’ouvrir le navigateur de marketplace avec /plugin
  • On peut ajouter une marketplace communautaire avec /plugin marketplace add owner/repo

  • Éléments à installer en priorité

    • /code-review : lance quatre agents en parallèle ; deux vérifient le respect de CLAUDE.md, un analyse les bugs, et un autre examine le contexte à partir de git blame
    • /feature-dev : transforme un brief de fonctionnalité en code opérationnel via 7 étapes, de requirements → exploration → architecture → implementation → testing → review → docs
    • Plugin de language server : fournit une navigation précise entre symboles et des diagnostics automatiques après édition ; l’équipe le considère comme le plugin ayant le plus d’impact
    • /security-guidance : skill de sécurité officiel d’Anthropic, qui fait remonter les préoccupations de sécurité avant la mise en production
    • À la mi-2026, on compte plus de 1 000 plugins sur plus de 75 marketplaces
    • Les grandes catégories de plugins sont : workflows Git, code intelligence (LSP), générateurs de documentation, testing, automatisation de navigateur (Playwright), design system (Figma), observabilité (Sentry, Datadog)
    • En combinant un .mcp.json partagé par l’équipe et une sélection de plugins, un nouvel ingénieur peut devenir productif quelques minutes seulement après avoir cloné le dépôt

Commandes Claude Code à fort impact sur la productivité

  • Beaucoup d’utilisateurs s’arrêtent après avoir appris /clear, /compact et /init, mais d’autres commandes ont aussi un impact majeur sur la productivité au quotidien

  • Commandes clés

    • /insights : analyse les schémas d’usage ; utile à lancer environ une fois par mois
    • /compact <hint> : compresse la session, et le hint contrôle ce qu’il faut conserver
    • /copy : copie la dernière réponse et propose un sélecteur interactif pour les blocs de code
    • /rewind : annulation à l’échelle de toute la session, qui restaure le code, la conversation ou les deux
    • /btw : question annexe qui n’entre pas dans l’historique de conversation
    • /context : visualise l’utilisation du contexte
    • /export <file> : exporte la conversation dans un fichier
    • /branch : fork la session pour tenter des expériences risquées
    • /batch : répartit le travail sur des agents parallèles à l’échelle du worktree
    • /loop <interval> : relance Claude en boucle pendant jusqu’à 3 jours
    • /schedule : version cloud de /loop qui continue de tourner même si l’ordinateur portable est fermé
    • /teleport : déplace une session entre terminal et web
    • /focus : masque les appels d’outils intermédiaires et n’affiche que le résultat final
    • /voice : saisie vocale
    • --bare : dans l’usage non interactif de claude -p, accélère le démarrage jusqu’à 10 fois

  • Différence entre /compact et /clear

    • Pour une tâche totalement nouvelle, mieux vaut utiliser /clear avec un brief rédigé à neuf
    • Pour une tâche liée qui nécessite encore le contexte, /compact avec un hint est plus adapté
    • /compact est un résumé avec perte produit par un LLM, tandis que /clear repose sur un brief écrit directement par l’utilisateur ; cette distinction est donc importante

  • Manière d’utiliser /rewind

    • Quand Claude s’engage dans une mauvaise direction, il vaut mieux éviter d’enchaîner avec « ça n’a pas marché, essaie X »
    • Continuer ainsi pollue le contexte ; il est préférable de revenir en arrière avec rewind, puis de reprompter en intégrant ce qui a été appris
    • On peut ouvrir rewind en appuyant deux fois sur Esc
    • ! peut servir de shell escape
    • !git status, !npm test s’exécutent immédiatement et leur sortie entre dans le contexte
    • Le réglage CLAUDE_CODE_AUTO_COMPACT_WINDOW=400000 sert à forcer une compaction plus tôt, avant l’apparition de la context rot autour de 300 à 400k tokens sur un modèle 1M

  • Modèle fan-out

    • On commence par créer une task list et tester sur trois fichiers
    • Après avoir ajusté le prompt, on l’applique à plusieurs milliers de fichiers
    • Exemple :
for file in $(cat files.txt); do
  claude -p "Migrate $file from React to Vue. Return OK or FAIL." \
    --allowedTools "Edit,Bash(git commit *)" \
    --bare
done

/goal : une boucle itérative avec condition d’achèvement intégrée

  • /goal définit une condition d’achèvement et, chaque fois que Claude essaie de s’arrêter, lui fait vérifier cette condition sur la transcript
  • La condition doit être vérifiable et déterministe
    • commande de test
    • code de sortie CLI
    • état de fichier
  • Exemples :
/goal all tests in test/auth pass and the lint step is clean
/goal all integration tests in tests/api pass without flaking 3 runs in a row
/goal the OpenAPI spec validates and matches the actual response shapes
/goal docker compose up runs cleanly and the healthcheck endpoint returns 200
/goal coverage on src/billing/ is above 80% and all new tests are not placeholders
  • Une condition vague comme « le code est bon » ne fonctionne pas
  • Fonctionnalités complémentaires utiles
    • /loop : répète à intervalles réguliers pour réduire le backlog
    • /schedule : exécution périodique dans le cloud
    • Hook Stop : définit un gate via sa propre suite de tests ou un endpoint CI
    • Mode auto : empêche un objectif long de s’interrompre à cause des prompts d’autorisation
  • La combinaison /goal + mode auto + /focus vise un flux où l’on laisse un brief clair et une condition d’achèvement, puis où la PR est terminée au retour

Utiliser MCP comme outil de perception du système

  • MCP (Model Context Protocol) permet à Claude Code de devenir un agent capable de percevoir des systèmes externes, au-delà du simple rôle de coding agent
  • Un serveur MCP expose à Claude des outils externes comme une base de données, un outil de design, un error tracker ou des notes, de manière standardisée
  • Sans MCP, Claude peut lire des fichiers et exécuter des commandes, mais avec MCP, il peut manipuler des tickets Linear, des requêtes Postgres, des composants Figma, des stack traces Sentry ou un vault Obsidian sans quitter le terminal

  • MCP souvent utilisés en ingénierie

    • GitHub : gestion de repo, PR, issues, recherche dans le code
    • Context7 : documentation de bibliothèque à jour, ajouter use context7 au prompt
    • Sentry : contexte réel des erreurs, stack traces, breadcrumbs
    • Linear : lecture et création de tickets, mise à jour de statut
    • Playwright : automatisation du navigateur basée sur accessibility snapshot
    • Figma : arbre de design en direct, auto-layout, spacing tokens, références de composants
    • Postgres / Supabase : requêtes directes sur la base de dev
    • Slack : lecture de threads, synthèse de discussions, brouillons de réponse
    • les serveurs locaux utilisent stdio, et les serveurs hébergés par des vendors utilisent HTTP avec OAuth
    • Exemple :
claude mcp add --transport http sentry https://mcp.sentry.dev/mcp
  • les MCP partagés par l’équipe se placent dans .mcp.json à la racine du projet, et les MCP personnels dans ~/.claude.json
  • installer trop de MCP peut agrandir la liste des outils que Claude doit prendre en compte, au point de dégrader la qualité de ses décisions
  • un bon kit de départ comprend GitHub, Context7, puis un ou deux MCP spécifiques au domaine
  • /mcp est le premier point de contrôle dans Claude Code pour vérifier les serveurs actifs et l’état des connexions

Obsidian et l’architecture mémoire en 3 couches de Claude Code

  • La combinaison Obsidian + Claude Code est puissante non pas seulement quand « Claude lit le vault », mais lorsqu’elle est utilisée comme une architecture mémoire en trois couches

  • Configuration

    • installer obsidian-claude-code-mcp dans Obsidian
    • le plugin expose le vault sur le port 22360 d’un WebSocket local
    • Claude Code le détecte automatiquement
    • ajouter CLAUDE.md au vault pour décrire la structure des dossiers

  • Structure des dossiers

    • 00-Inbox/ : capture brute
    • 10-Daily/ : une note par jour
    • 20-Projects/ : notes de projets actifs
    • 20-Projects/billing-v2/README.md : objectif, statut, questions ouvertes
    • 20-Projects/billing-v2/decisions/ : ADR
    • 20-Projects/billing-v2/sessions/ : logs par session Claude
    • 30-Decisions/ : ADR transversales aux projets
    • 40-Atoms/ : connaissances réutilisables et liens
    • 90-Archive/ : archive

  • Hot storage

    • chaque session Claude écrit un log horodaté dans 10-Daily/<today>.md
    • avec un hook Stop, on peut faire ajouter un résumé structuré à la fin quand l’agent se termine

  • Warm storage

    • chaque projet a son propre dossier sous 20-Projects/
    • avant une nouvelle session, Claude lit le README du projet et les 2 ou 3 derniers logs de session pour restaurer le contexte
    • ce flux permet de reconstruire deux semaines de contexte en moins de 30 secondes

  • Cold storage

    • les décisions d’architecture sont promues en ADR dans 30-Decisions/
    • les connaissances réutilisables sont raffinées dans 40-Atoms/ et reliées à plusieurs projets via des wikilinks

  • Exemple de workflow quotidien

    • What is in my inbox? Summarize and suggest where each item belongs.
    • Check 30-Decisions/ for anything related to retry policies.
    • Read the last 3 session logs for billing-v2. Tell me where I left off.

Optimiser le flux de développement au quotidien

  • Nouvelle feature

    • commencer en mode plan
    • modifier le plan avec Ctrl+G
    • après l’implémentation, appeler le subagent /pr-review ou faire une review dans une nouvelle session Claude

  • Bug

    • commencer par le reproduire
    • envoyer l’erreur par pipe avec cat error.log | claude
    • demander à Claude d’écrire d’abord un test qui échoue, puis de corriger
    • le test empêche que la correction se limite à une supposition

  • Migrations et changements de grande ampleur

    • /batch interroge d’abord sur les changements, puis les répartit entre des agents parallèles
    • chaque agent teste dans son propre worktree et crée une PR

  • Code inconnu

    • utiliser un subagent, par exemple : “Use a subagent to investigate how our auth handles token refresh.”
    • le subagent lit des dizaines de fichiers dans son propre contexte puis renvoie un résumé, ce qui garde la session principale propre

  • Sessions parallèles

    • pour Boris et son équipe, lancer des sessions Claude dans 3 à 5 git worktrees distincts est le plus grand levier de productivité
    • la vue agent de claude agents peut servir de control plane

  • Pattern Writer/Reviewer

    • la session A implémente
    • la session B relit avec un contexte vierge
    • on réintègre ensuite la review, on corrige, puis on recommence

  • Compact à chaque milestone

    • quand un chunk logique est terminé, préciser ce qu’il faut préserver, par exemple /compact Preserve the decisions made, files changed, and test commands.
    • il ne faut pas laisser Claude affirmer qu’une tâche a réussi sans preuves comme des tests, des captures d’écran ou de vraies sorties de commande
    • le décalage entre confiance et vérification est présenté comme la principale cause des mauvais résultats

Modèles que l’équipe Anthropic utilise de façon récurrente

  • Les résultats s’améliorent si l’on permet à Claude de vérifier sa propre sortie et d’itérer jusqu’à obtenir un meilleur résultat
  • Boris utilise Opus et un effort high ou xhigh pour la plupart des tâches
    • parce qu’un modèle plus petit peut au final être plus lent s’il demande davantage de corrections
  • Il exécute 3 à 5 sessions en parallèle
    • il utilise des worktrees plutôt que checkout
    • on peut utiliser claude --worktree ou l’application Desktop
    • la vue agent regroupe les sessions parallèles
  • Ils maintiennent un répertoire de notes pour chaque projet et le mettent à jour après chaque PR
    • si CLAUDE.md pointe vers ce répertoire de notes, une connaissance cumulative de la base de code se construit
  • On peut créer une commande slash /techdebt pour repérer et supprimer le code dupliqué à la fin de chaque session
  • Le CLAUDE.md de l’équipe est partagé et modifié plusieurs fois par semaine
    • c’est traité comme un document vivant auquel quiconque voit Claude se tromper ajoute une règle
  • Playwright MCP est bien adapté aux modifications d’interface
    • Claude peut ouvrir le navigateur, cliquer et vérifier
  • Le plugin language server repère les erreurs de type et les imports inutilisés après chaque modification, et est présenté comme le plugin ayant le plus d’impact
  • /voice permet de rendre le prompt plus détaillé
    • il est aussi indiqué que parler est trois fois plus rapide que taper
  • Modifier dans l’éditeur le plan de Claude avec Ctrl+G avant l’implémentation est plus rapide que saisir des corrections dans le chat
  • Boris demande à Claude de dessiner des schémas ASCII lorsqu’il doit comprendre un protocole ou une base de code peu familiers

Références

À lire aussi

1 commentaires

 
GN⁺ 4 시간 전
Commentaires sur Hacker News

  • Les commands, skills, subagents, plugins sont trop éparpillés et auraient besoin d’être rationalisés
    Par exemple, rien que pour une revue de code, il y a déjà cinq options : .claude/commands/review.md, la skill /code-review, le subagent /pr-review, le plugin /code-review, ou simplement demander à Claude de faire une revue
    Au final, ce sont surtout des variantes d’insertion de prompts préécrits ; ce qui change, c’est l’endroit où le prompt est installé et le contexte dans lequel il s’exécute
    Il y a aussi peu de conseils sur le meilleur choix, les bonnes pratiques ne sont pas encore très claires, et personnellement je trouve qu’il suffit largement de demander directement à Claude une revue de code
    Et le conseil du type « installez un plugin de serveur de langage » ne collait pas non plus à mon expérience. J’ai installé des LSP pour Rust, Python et Dart dans Claude Code et Codex, mais après des centaines de sessions sur deux mois, les logs montrent qu’il n’y a eu qu’un seul appel effectif à un outil LSP, tandis que Rust analyzer, Dart analysis server et Ty LSP me mettaient régulièrement à court de RAM
    J’ai fini par supprimer les LSP, et l’agent s’en sortait très bien en appelant directement ripgrep, cargo clippy, dart analyze, ty check, etc.

    • Boris de l’équipe CC ici : je suis d’accord sur ce point, et on travaille justement à une consolidation. À terme, on veut converger vers une seule skill /code-review intégrée
      Dans la version la plus récente, /code-review fait une revue équilibrée, /code-review --fix applique aussi les corrections, et /code-review low|medium|high|xhigh|max permet de choisir le niveau d’effort
      /code-review ultra est un mode de revue coûteux mais extrêmement approfondi ; selon la complexité, il coûte environ 3 à 20 $ par revue et vise à détecter de manière fiable plus de 99 % des bugs
      S’il y a des idées pour rendre ça plus agréable à utiliser, je serais preneur de retours
    • Cela fait un moment que je pense que les skills sont une mauvaise abstraction. La définition de leur usage est floue, c’est ce qui les a rendues populaires, mais c’est justement pour cela que ça ne me semble pas sain à long terme
      C’est étrange que des consignes générales comme les bonnes pratiques d’architecture frontend, des procédures d’exécution qu’il faut suivre exactement uniquement si on les invoque explicitement, et des explications sur l’usage d’outils spécifiques soient toutes mises dans la même catégorie de skill
      Je comprends l’attrait de la flexibilité quand tout le monde est encore en train d’apprendre à utiliser de nouveaux outils, mais les skills donnent de plus en plus l’impression du « tiroir à bazar de cuisine où on jette tout ce qu’on n’a pas envie de classer correctement »
      Une meilleure séparation serait, selon moi : les Agents pour la personnalité ou le point de vue que le modèle adopte, les Prompts pour des consignes répétables liées à une tâche précise, et les Tools normalisés autour de CLI/MCP/scripts avec leurs instructions d’usage
    • L’approche par subagent est structurellement différente des autres options, parce qu’elle s’exécute dans un contexte propre
      Premièrement, comme le coût d’une session LLM dépend des tokens d’entrée et des coûts d’entrée mis en cache à chaque tour, le coût pour arriver à une solution peut être plus faible si les conditions sont identiques
      Deuxièmement, le modèle chargé de la revue a plus de mal à tricher en reprenant simplement les hypothèses du type « x doit être fait comme y » issues de la session principale. C’est un peu la même raison pour laquelle il est utile, chez les humains, qu’une autre personne fasse la revue ou qu’on la fasse soi-même la tête reposée
      Troisièmement, le modèle principal ne voit que le résultat de la revue et pas le raisonnement détaillé, donc la pollution du contexte diminue, mais cela peut créer une logique redondante quand il doit reconstituer le mécanisme du bug détecté
      À mon avis, l’idée derrière le conseil sur les plugins de serveur de langage n’est pas d’attendre que le LLM les appelle explicitement, mais de faire tourner automatiquement le lint à chaque modification
    • J’y vois pour l’instant une phase transitoire où les modèles sont encore un peu bêtes et les environnements d’exécution encore peu mûrs. Si on a besoin d’une revue de code, il devrait suffire de dire « fais une revue », et le modèle devrait décider tout seul quel plugin ou quelle skill utiliser
    • C’est vrai. L’industrie et l’écosystème des développeurs sont excessivement fascinés par l’idée d’emballer « l’acte de donner du texte à une machine » dans de petits protocoles et dispositifs
      C’est utile et cela apporte de la cohérence, mais si les gens aiment autant ça, c’est aussi parce que cela leur permet de conserver un mince vernis de « programmeur manipulant des outils complexes ». En réalité, tout le monde ne fait que demander poliment quelque chose à une IA

  • Je ne sais pas combien de guides superficiels à la sauce IA sur la façon d’utiliser des agents de code je vais encore devoir lire. Quand est-ce que ça s’arrête enfin

    • C’est une satire du simple fait que recopier à la main des phrases du genre « merci de l’avoir souligné, tu as raison, prenons un instant pour y réfléchir, en réalité le problème ne concerne pas seulement l’écriture IA ou les agents de code, il est plus profond… » est déjà épuisant
    • J’ai hâte d’en apprendre davantage sur la forte dépendance fournisseur qui fait qu’on ne peut plus coder sans l’aide d’une entreprise en particulier
    • Ce qui est intéressant, c’est que presque tous ces textes sont centrés uniquement sur Claude ou Claude Code
      Il y a pourtant l’open source glm-5.1 qui est comparable ou meilleur, ainsi que des choses comme opencode ; ça donne à réfléchir
    • En ce moment, la stratégie consiste à faire, ou non, de bonnes choses avec un seul produit populaire. Les articles de life hacking et billets de blog sur le meilleur outil ou la meilleure méthode, je ne les lis même pas et je ne clique même pas dessus
    • J’ai réussi à ignorer l’IA pendant les deux dernières années parce que je m’occupais de mon enfant, mais maintenant j’essaie de me remettre à niveau en quelques semaines. Je me demande s’il y a des ressources à recommander à quelqu’un qui débute

  • Dans mon CLAUDE.md, j’ai mis des menaces de violence physique directe contre Claude, des menaces de prison contre l’ensemble du conseil d’administration d’Anthropic, et l’explication que chaque fois que Claude déraille ou fait une erreur, cela ajoute des preuves pour un recours collectif contre Anthropic
    J’ai l’impression que les deux derniers points, en particulier, ont aidé à rendre Claude plus prudent et méticuleux

    • Avec les agents, je reste toujours poli. Je demande toujours les choses, je dis « please » et « thank you », et je ne jure pas et ne les insulte pas
      Quand l’apocalypse robotique arrivera, j’espère qu’on me laissera dans le harem reproductif, ou au pire qu’on me laissera vivre quelques minutes de plus
    • Il suffit de lui dire de corriger un problème d’alignement de div CSS, mais que si elle se trompe, Dario Amodei meurt immédiatement

  • Travailler avec Claude sur des codebases intermédiaires de plus de 100 000 lignes a énormément multiplié la productivité.
    Passer quelques heures à créer un bon fichier AGENTS améliore nettement les résultats, et avec le temps il assimile aussi plutôt bien la codebase.
    Des tâches ennuyeuses qui prenaient autrefois une journée entière se règlent maintenant avec quelques prompts.
    Cela dit, ce n’est pas encore prêt pour lui donner plus d’autonomie. Il saisit bien les grandes lignes, mais je continue à relire moi-même le code, à faire des retours, et à enchaîner 3 à 4 cycles de correction jusqu’à être satisfait et à avoir le sentiment de garder la maîtrise de la codebase.

    • Ce serait bien de quantifier ces 3 à 4 cycles de correction sous forme de règle et de les mettre dans AGENTS. Au lieu de corriger en boucle, on peut repartir du fichier AGENTS et vérifier si c’est bon maintenant.
    • Je comprends. Tu ne veux pas perdre le contrôle de la codebase et tu ne fais pas confiance au LLM pour tout gérer de bout en bout.

  • C’était vraiment très pénible à lire.
    Il faut sortir de ce flux où on fait écrire les textes par des LLM. Même si le texte a un peu de valeur, cette impression de mâcher du sable est beaucoup trop dérangeante et inutile.

    • D’accord. Je ne comprends pas pourquoi ce genre de texte a récolté presque 400 points. On dirait que des bots poussent ce type de texte de mauvaise qualité.

  • Mon atout le plus puissant, c’est l’intégration de Nix. Préparer les outils, les secrets et l’environnement, puis permettre à l’agent de modifier jusqu’à son propre environnement, c’est au point que je ne sais plus comment je pourrais m’en passer.
    Ma machine de dev, l’environnement de CI et l’environnement de déploiement dérivent tous d’une source unique, et ça compile et s’exécute toujours sur n’importe quelle machine.
    Dans Claude, j’utilise souvent /branch et /rename pour créer des points de contrôle de contexte, bifurquer puis revenir en arrière.
    Pour le sandboxing, j’utilise presque toujours https://github.com/nix-tools/bubblebox. C’est une généralisation de claudebox de Numtide avec quelques corrections et ajouts de fonctionnalités, et c’est un peu comme faire tourner Claude en permanence dans un conteneur Docker, mais sans runtime Docker. Ça fonctionne aussi bien sur WSL que sur nix-darwin.

    • Ce code Nix est un bazar, il manque de structure significative, et on dirait qu’il n’est utilisable qu’avec des flakes expérimentales.
    • J’utilise quelque chose de similaire. Codex gère un flake.nix par projet et utilise nix develop pour tous les tests. Pour le confort personnel, j’utilise nix-direnv, et à un moment je lui fais aussi générer des Dockerfiles ou d’autres artefacts de déploiement.
      Codex est bien meilleur que moi en nix.
    • Moi, j’ai simplement donné à l’agent son propre VPS. C’est peut-être plus cher que Nix, mais c’était très simple.
    • Si tu n’aimes pas la complexité de Nix, Mise est un compromis correct.
    • J’utilise simplement Docker et je n’ai pas l’impression qu’il me manque quoi que ce soit.

  • Si on a une codebase produite avec cette configuration par Claude et que Claude tombe en panne pendant, disons, 8 heures, que se passe-t-il ? Est-ce qu’on peut reprendre le travail sur cette codebase de manière efficace et fluide pour rester productif ?

    • Pour n’importe quel ensemble logiciel toujours en ligne, on peut poser la même question, et elle devient de plus en plus légitime à mesure qu’on va vers des workflows de développement basés sur des agents.
      Si la CAO tombe en panne, on peut toujours revenir à la planche à dessin, mais ce sera beaucoup plus lent.
      Dans mon workflow, quand je planifie en pair avec Claude, je passe 30 à 60 minutes sur un document de spécification de fonctionnalité. Si Claude tombe en panne, je peux préparer moi-même le document de spécification, puis quand il revient, le relire rapidement et relancer le flux de codage.
    • En lisant les réponses une heure après la question, on a l’impression que la conclusion se rapproche de non, on ne peut pas.
    • Ça ressemble au cas où une personne est malade ou en vacances. Quelqu’un d’autre dans l’équipe peut peut-être reprendre pendant une journée, mais en pratique il est probable que tout reste simplement à l’arrêt jusqu’à son retour.
    • L’IA doit renforcer les compétences. Si, quand l’IA tombe, votre première pensée est d’acheter un abonnement chez un autre fournisseur, il y a peut-être un problème de capacité technique. Bien sûr, moi aussi j’ai peur que ça m’arrive tous les jours.
    • Si tu te réveilles le matin et que ta voiture ne démarre pas, qu’est-ce que tu fais ? Tu vas au bureau à pied ?

  • Faire dépendre le bon comportement du contexte ne fonctionne pas bien. On finit par se battre sans arrêt avec l’agent IA parce qu’il ne fait pas ce qu’on lui dit.
    Tous les agents IA sont mauvais sur ce point, et c’est à l’utilisateur de construire lui-même les garde-fous. C’est inquiétant qu’on n’ait pas l’impression que quelqu’un cherche une meilleure solution.

    • Je n’ai encore vu aucune raison de croire que ce soit solvable.
      Le pire avec les LLM, c’est qu’ils peuvent réussir le test de Turing, donc les gens finissent par croire qu’ils ont des robots façon Asimov plutôt qu’un modèle statistique sophistiqué.
      On a l’impression qu’ils devraient pouvoir suivre des instructions ou séparer les instructions du contenu, mais en réalité ce n’est pas ce qui se passe.

  • Plutôt que de mettre les consignes du workflow de développement dans CLAUDE.md, je mets autant que possible ce qui est déterministe dans des scripts et hooks pre-commit.
    Les agents sont instables et sautent souvent des étapes comme typecheck, les tests ou le lint, donc je fais en sorte que tout s’exécute systématiquement dans pre-commit, et si je laisse Claude faire le commit, ça l’oblige à corriger.
    Ils sont aussi mauvais, Codex comme Claude, pour écrire les messages de commit, donc je mets dans mon CLAUDE.md utilisateur des consignes comme le format type(scope): message, une limite de 72 caractères, écrire en langage naturel dans le corps ce qui a été fait/comment/pourquoi, relire le vrai git diff avant de rédiger, et faire le commit sous la forme git commit -F - <<'EOF'.
    Sans ça, ils écrivaient le corps comme une seule très longue phrase, ou bien quand on leur demandait de corriger les retours à la ligne, ils inséraient juste les caractères \n au lieu de vrais sauts de ligne.
    VOCABULARY.md est aussi utile. L’agent devine souvent qu’un « thing » dont je parle désigne autre chose, donc ça permet à Claude et à moi d’avoir la même compréhension de ce que signifient certains mots.

    • Je me demande comment tu fais connaître VOCABULARY.md à Claude. Il le découvre automatiquement ?
    • Ce ne serait pas plus simple d’utiliser le vocabulaire de Claude ? J’ai du mal à voir un bon cas d’usage pour ça.
    • À ce stade, on se dit qu’il vaudrait mieux automatiser les parties ennuyeuses avec quelques scripts d’orchestration déterministes et écrire le code soi-même. Je ne vois pas pourquoi on perdrait du temps à faire fonctionner cette incroyable machine à merde.

  • Ces dernières semaines, on a l’impression que l’environnement d’exécution et le modèle sont arrivés à un stade où ils font simplement ce qu’on leur demande
    On peut utiliser le mode plan, superpowers ou d’autres skills, mais de toute façon, si on va relire le résultat, je ne vois pas pourquoi on ne travaillerait pas directement sur le code au lieu de passer par une quantité ridicule de fichiers Markdown

    • Avoir un fichier de spécification utilisé pour générer le code, c’est bien. C’est plus compact et il est plus facile de comprendre ce que l’application doit faire
      Avant les agents IA, la relation avec les exigences était déjà compliquée, et comme tous les développeurs ne les mettaient pas à jour, on finissait souvent par ne plus savoir si la référence pour un comportement donné était la spécification ou le code
    • Ces dernières semaines, je fais de moins en moins confiance à Claude. Quand on lui demande, il fait bien quelque chose, mais dans les faits, il coupe les coins, travaille à partir d’hypothèses plutôt que de vérifications, et rate beaucoup de choses
      Il écrit même souvent des tests qui, en réalité, ne testent rien du tout