SpyBara
Go Premium

best-practices.md 2026-10-26 22:57 UTC to 2026-10-27 22:59 UTC

This page contains 417 additions and 355 deletions.

2026
Fri 2 22:59 Sun 4 23:58 Tue 6 23:59 Tue 20 23:00 Thu 22 22:58 Fri 23 22:59 Tue 27 22:59 Fri 30 23:01

Bonnes pratiques pour Claude Code

Tirez le meilleur parti de Claude Code : dites à Claude ce qu'il ne peut pas voir, donnez-lui une vérification à exécuter et imposez les règles qui ne tolèrent aucune exception.

Claude Code est conçu de telle sorte que, dans la plupart des cas, votre premier prompt tout simple dans une nouvelle session fait déjà ce qu'il faut, sans aucune configuration de votre part.

Par exemple :

  • Pour que les commandes s'exécutent en toute sécurité sans que vous ayez à approuver chacune d'elles, les nouvelles sessions de terminal et VS Code démarrent en mode auto, où un classifieur examine tout ce qui est risqué avant son exécution.
  • Pour que votre conversation principale reste concentrée pendant que du travail indépendant se déroule en parallèle, Claude délègue à des sous-agents et ne vous sollicite que lorsque c'est nécessaire.
  • Pour qu'une longue session se poursuive sans que vous ayez à la gérer, votre conversation est compactée automatiquement avant que la fenêtre de contexte ne se remplisse.

Cette page couvre ce qu'il faut faire lorsque les valeurs par défaut ne suffisent pas. Cela arrive généralement lorsque votre projet comporte des connaissances, des règles ou des contraintes que Claude ne peut pas voir à partir du seul code :

  • Un processus de déploiement qui n'existe que dans la tête de quelqu'un
  • Un fichier qui ne doit jamais être lu
  • Une vérification qui doit réussir avant que quoi que ce soit soit considéré comme terminé
  • Un budget que vous devez respecter

Aucune valeur par défaut ne peut connaître ces éléments de votre projet, et c'est donc là qu'un petit effort de configuration de votre part porte ses fruits.

Lorsqu'une session ne se déroule pas comme prévu, c'est presque toujours pour l'une de ces raisons :

  • Claude a construit quelque chose de différent de ce que vous aviez en tête, ou il doit redécouvrir le même fait au début de chaque session. Il lui manque des informations qu'il ne peut pas obtenir en lisant le dépôt. Consultez Dites à Claude ce qu'il ne peut pas voir.
  • Claude a dit qu'il avait terminé alors que ce n'était pas tout à fait le cas, généralement parce qu'il n'avait aucun moyen de vérifier son propre travail. Consultez Donnez à Claude une vérification à exécuter.
  • Claude a fait quelque chose qui ne doit jamais se produire dans ce dépôt, ou a sauté une étape qui doit toujours avoir lieu. Un prompt seul ne peut garantir ni l'un ni l'autre. Consultez Imposez les règles qui ne tolèrent aucune exception.
  • Claude a bien fait les choses, mais cela a pris plus de temps, de tokens ou de demandes de permission que la tâche ne le justifiait. Consultez Modifiez une valeur par défaut.

Laissez Claude travailler sans vous applique ces quatre mêmes points aux exécutions sans surveillance, et Ce que vous pouvez arrêter de faire liste les conseils que les modèles actuels ont rendus inutiles.

[!NOTE]

La configuration pour toute une équipe se trouve sur une page distincte : Configurer Claude Code pour votre organisation.

Instructions déterministes et non déterministes

Chaque instruction que vous donnez à Claude Code appartient à l'une de ces catégories :

  1. Non déterministe : vous écrivez l'instruction, et Claude (le modèle) la lit. Il peut s'agir de votre prompt, de CLAUDE.md ou d'un skill. Le modèle décide ensuite quoi faire de cette information. Il suit généralement vos commandes, et les modèles actuels comprennent bien votre intention sans beaucoup de contexte, mais rien ne garantit qu'il suivra vos instructions. Il peut toujours décider de ne pas faire certaines choses, ou d'en faire d'autres.
  2. Déterministe : vous configurez l'instruction, et Claude Code (le harnais) doit l'exécuter. Il peut s'agir d'un hook, d'une règle de refus ou d'un paramètre géré. Claude Code l'applique à chaque fois, quelle que soit la décision du modèle.

La plupart des éléments de Claude Code existent sous ces deux formes :

Non déterministe (Claude décide) Déterministe (Claude Code impose)
Quoi faire Votre prompt, CLAUDE.md, les skills que Claude sollicite lui-même Les hooks, et les skills que vous seul pouvez démarrer
Ce qu'il peut toucher Le classifieur du mode auto Les règles de refus, le sandbox en mode strict, les paramètres gérés
Quand c'est terminé Une demande de preuves, /goal, /code-review Les tests, la vérification de types, un hook Stop, la CI
Combien il dépense Le niveau d'effort, le rythme propre de Claude --max-turns ou --max-budget-usd avec -p, une limite de dépenses que vous avez définie
Qui a le dernier mot Le résumé par Claude de ce qu'il a fait La protection de branche, une personne qui approuve la fusion

La plupart du temps, vous voulez que Claude décide. Presque toutes les directives ont des exceptions, et les modèles actuels savent bien lire le code qu'ils ont sous les yeux et juger si une directive convient à la situation. Avec le code réel sous les yeux, Claude est généralement mieux placé pour prendre cette décision qu'une règle que vous avez écrite à l'avance.

Le type déterministe sert lorsque vous voulez vous assurer que certaines choses se produisent toujours (ou jamais), quelle que soit la décision du modèle. Il n'est pas nécessaire que ce soit quelque chose de spectaculaire. Le mode auto bloque déjà les choses spectaculaires, comme un déploiement en production ou un force push par-dessus le travail de quelqu'un. Il s'agit généralement de quelque chose de propre à votre projet, et cela peut être aussi spécifique que vous le souhaitez :

  • Ne jamais modifier le client généré dans src/gen/
  • Toujours exécuter le script d'en-tête de licence après la création d'un fichier

Vous auriez pu écrire l'une ou l'autre de ces règles sous forme de ligne dans CLAUDE.md ou dans votre prompt, et Claude la suivrait presque à chaque fois. Mais quelle que soit la fermeté de votre formulation, le fait que Claude suive cette ligne lors d'un tour donné reste sa décision.

[!TIP]

Si vous ne cessez d'ajouter de l'emphase à une ligne de CLAUDE.md et que Claude la manque toujours, c'est le signe que cette ligne a sa place dans un hook. L'inverse est également vrai : si vous avez des hooks pour des choses qui ne sont que des préférences, supprimez-les et laissez Claude décider.

Dites à Claude ce qu'il ne peut pas voir

[!TIP]

N'écrivez que ce que Claude ne peut pas trouver en lisant le dépôt, ou ce qu'il passerait sinon du temps à redécouvrir à chaque session.

Claude commence chaque tâche en lisant votre code, et les modèles actuels y excellent vraiment. Ils trouveront l'organisation de vos fichiers, vos conventions, votre framework de test et la façon dont les composants existants sont construits, généralement plus vite que vous ne pourriez les expliquer. Cela signifie que Claude connaît déjà l'essentiel de ce que vous pourriez être tenté d'écrire pour lui.

Ce qu'il ne peut pas trouver, ce sont les informations qui n'ont jamais été dans le dépôt :

  • Une décision prise par votre équipe lors d'une réunion
  • Un processus de déploiement qui n'existe que dans la tête d'une personne
  • La variable d'environnement dont vos tests d'intégration ont besoin

Il y a aussi des informations qui sont dans le dépôt mais qui demandent quelques minutes de recherche, et Claude doit refaire cette recherche au début de chaque session.

Un bon test avant d'écrire quoi que ce soit pour Claude :

  1. Pourrait-il trouver cela en lisant le code ?
  2. Irait-il réellement chercher ?

Si la réponse est oui aux deux, laissez-le de côté.

Écrivez un prompt précis

Un prompt précis aide pour la même raison, car il donne à Claude des informations qu'il n'a pas déjà. Si vous nommez le fichier, décrivez le symptôme et indiquez d'emblée à quoi ressemble « corrigé », vous vous épargnez généralement une série de corrections par la suite.

Il en va de même pour une préférence entre deux approches raisonnables : Claude ne peut pas la lire dans le code, donc si vous tenez à ce qu'il choisisse l'une plutôt que l'autre, dites-le d'emblée.

Au lieu de Essayez
« corrige le bug de connexion » « les utilisateurs signalent que la connexion échoue après l'expiration de la session. regarde l'actualisation des tokens dans src/auth/, écris un test qui échoue et reproduit le problème, puis corrige-le »
« ajoute un widget calendrier » « suis le modèle de HotDogWidget.php et construis un widget calendrier qui permet de choisir un mois et de naviguer entre les années. pas de nouvelles bibliothèques »

Si vous disposez déjà de ce dont Claude a besoin, transmettez-le au lieu de le décrire :

  • Un fichier : tapez @ suivi du chemin pour inclure le contenu du fichier dans votre message.
  • Une image : collez la capture d'écran de la maquette ou de l'erreur dans le prompt.
  • La sortie d'une commande : redirigez-la depuis votre shell avec cat error.log | claude -p "what's going on here".

Des expressions comme think step by step ou be thorough sont du texte de prompt ordinaire plutôt que des mots-clés. Le principal contrôle de l'intensité de réflexion de Claude est le niveau d'effort, traité dans Changez le modèle et l'effort. Ce type de formulation peut encore orienter Claude dans les limites de son niveau d'effort, mais ne le fera pas dépasser.

Une expression qui aide encore est be ambitious. Claude a tendance à interpréter une demande de façon conservatrice et à construire la plus petite chose qui y réponde, car il ne peut pas voir à quel point vous espériez davantage. Lorsque vous voulez la version plus complète, avec les cas limites gérés et la suite naturelle incluse, dites-le :

build the settings page from the mockup. be ambitious: empty and error states, the save flow wired up, keyboard navigation, not just the layout

Cela indique à Claude la portée, que vous seul connaissez, plutôt que l'intensité de sa réflexion.

Et lorsque vous explorez plutôt que de corriger quelque chose de précis, un prompt vague comme what would you improve in this file? convient parfaitement. Vous corrigerez un peu plus au fur et à mesure, c'est le compromis.

Faites d'abord un brainstorming avec Claude

Lorsque vous ne savez pas encore exactement ce que vous voulez, vous n'avez pas à tout élaborer avant d'écrire votre prompt. Demandez plutôt à Claude de vous interviewer :

I want to add rate limiting to the public API but haven't thought it through yet. Interview me until you could write the spec, then write it to SPEC.md.

Claude revient avec des questions à choix multiples sur les points que vous n'avez pas encore fixés : limites par utilisateur ou par clé, ce qui arrive aux requêtes au-delà de la limite, ce qui est hors périmètre. Il continue de poser des questions jusqu'à ce que les réponses forment une spécification.

Une fois SPEC.md créé, démarrez une nouvelle session pour construire à partir de celui-ci, afin que la construction commence avec un contexte propre et une définition écrite de ce qu'est « terminé ». C'est aussi le fichier vers lequel vous dirigerez le relecteur plus tard, dans Donnez à Claude une vérification à exécuter.

Gardez CLAUDE.md court

Claude Code charge CLAUDE.md dans chaque session, ce qui signifie que chaque ligne qu'il contient mobilise un peu de l'attention de Claude sur chaque tâche, qu'elle soit pertinente ou non. C'est pourquoi le fichier fonctionne mieux lorsqu'il ne contient que ce que Claude ne pourrait pas déduire du code lui-même :

  • Comment valider le travail dans ce dépôt : les commandes exactes de test, de vérification de types et de lint, et comment exécuter un seul fichier de test
  • Les endroits où le code est trompeur : un ancien modèle présent partout mais que le nouveau code ne doit pas copier, ou un répertoire qui semble inutilisé mais ne l'est pas
  • Les décisions qui ne sont pas dans le dépôt : quel helper d'erreur l'équipe a retenu, comment fonctionnent les déploiements, ce qui nécessite une revue de migration
  • Tout ce que vous avez déjà dû corriger deux fois

Un CLAUDE.md qui passe ce test reste court :

# Commands
- Install: pnpm install
- Run one test file: pnpm vitest run path/to/file.test.ts
- Typecheck: pnpm tsc --noEmit

# Conventions
- Use the error helpers in src/lib/errors.ts, never throw raw strings
- src/legacy/ is still live but don't copy its patterns into new code

# Gotchas
- Integration tests need DATABASE_URL set, see .env.example

Dans une session, exécutez /context pour confirmer que Claude a chargé le fichier.

Remarquez que la ligne de vérification de types ne contient que la commande. Claude a besoin de connaître la commande pour pouvoir vérifier son propre travail au fur et à mesure. Si vous voulez aussi que Claude Code impose une vérification de types réussie avant que Claude ne termine, c'est le rôle d'un hook Stop. Une ligne comme Always typecheck before you finish dans ce fichier fonctionne la plupart du temps, pas à chaque fois.

Vous n'avez pas à écrire le fichier à partir de zéro :

  • /init génère une version de départ à partir de votre base de code. Ensuite, le travail consiste surtout à supprimer des lignes. Le guide de la mémoire recommande de rester sous les 200.
  • /doctor suggère des suppressions pour tout ce que Claude peut déjà déduire du code.
  • /doctor prompt-audit signale les instructions écrites pour des modèles plus anciens, qui pointent vers des fichiers qui n'existent plus ou qui se contredisent.

Vos préférences personnelles vont dans CLAUDE.local.md plutôt que dans CLAUDE.md, et vous ajoutez ce fichier à .gitignore pour qu'il reste hors du dépôt.

[!NOTE]

Si Claude continue d'ignorer une ligne qui se trouve dans CLAUDE.md, ajouter IMPORTANT ne résoudra probablement pas le problème. Soit le fichier est devenu assez long pour que la ligne s'y perde, soit la ligne est une règle qui ne tolère aucune exception, auquel cas elle a sa place dans un hook.

Limitez les règles à une partie de la base de code

Si une règle ne concerne qu'une partie de la base de code, placez-la dans .claude/rules/ avec un filtre paths: pour qu'elle ne se charge que lorsque Claude travaille réellement dans cette partie. Par exemple, ce .claude/rules/api.md se charge pour les fichiers TypeScript sous src/api/ :

---
paths:
  - "src/api/**/*.ts"
---
- Validate request bodies with the zod schemas in src/api/schemas/, don't hand-roll checks
- Every new endpoint needs an entry in openapi.yaml, CI fails without it

Placez les procédures d'équipe dans des skills

Un modèle plus performant en sait davantage sur l'ingénierie, mais pas sur la façon dont votre équipe réalise une release, ce que dit votre runbook d'incident ou comment vous voulez que la documentation de l'API soit rédigée. Ce type de connaissance va dans un skill : une procédure ou un élément de connaissance d'équipe enregistré dans .claude/skills/<name>/SKILL.md.

Les skills sont aussi plus légers en contexte que CLAUDE.md pour ce genre de choses. Pour un skill que Claude peut démarrer de lui-même, il voit le nom et la description dans chaque session, mais ne lit le fichier complet que lorsque la tâche l'exige. Une longue procédure de release placée dans un skill ne pèse pas sur votre correction de bug sans rapport, comme elle le ferait dans CLAUDE.md.

[!NOTE]

La règle de CLAUDE.md s'applique aussi aux skills : n'écrivez que ce que Claude ne peut pas trouver seul.

Pour un workflow avec des effets de bord, comme réaliser effectivement cette release, ajoutez disable-model-invocation: true. Claude ne peut alors pas démarrer le skill de lui-même, et celui-ci ne s'exécute que lorsque vous tapez vous-même /release. Enregistré sous .claude/skills/release/SKILL.md, il pourrait ressembler à ceci :

---
name: release
description: Cut a new release. Bumps the version, writes the changelog entry, tags it and pushes the tag so CI can publish.
disable-model-invocation: true
---
1. Make sure you're on main with a clean tree. If not, stop and ask.
2. Run `pnpm changeset version` and commit the result.
3. Summarize the PRs merged since the last tag into CHANGELOG.md, one line each, user-facing changes only.
4. Tag `v<new version>` and push the tag. CI publishes from there, never publish from your machine.

Connectez les outils dont Claude a besoin

Une partie de ce que Claude ne peut pas voir se trouve entièrement dans un autre système, comme votre outil de suivi des tickets ou votre tableau de bord d'erreurs. Si ce système dispose d'une CLI, c'est généralement le moyen d'accès le plus simple. Avec gh installé et connecté, par exemple, Claude ouvrira des pull requests et lira les commentaires de revue sans aucune explication de votre part. Pour une CLI qu'il n'a jamais vue, lui indiquer --help suffit.

Pour les systèmes sans CLI, il y a MCP. Vous ajoutez un serveur depuis votre shell :

claude mcp add --transport http notion https://mcp.notion.com/mcp

Le serveur apparaît ensuite sous /mcp dans une session. Les serveurs connectés ajoutent leurs noms d'outils et leurs instructions au contexte même lorsque vous ne les utilisez pas, il vaut donc la peine d'y désactiver ceux dont vous n'avez pas besoin.

Et si vous travaillez dans un langage typé, un plugin d'intelligence de code permet à Claude d'accéder directement à une définition au lieu de parcourir de nombreux fichiers pour la trouver.

Donnez à Claude une vérification à exécuter

Claude s'arrête lorsque le travail semble terminé. S'il n'a rien à exécuter qui lui indique si le travail est réellement terminé, « semble terminé » est tout ce sur quoi il peut s'appuyer. En pratique, c'est vous qui devenez la suite de tests, et chaque erreur reste là jusqu'à ce que vous la remarquiez.

Si vous lui donnez quelque chose qui renvoie un résultat de réussite ou d'échec, Claude peut boucler lui-même. Il effectue la modification, exécute la vérification et, si quelque chose a cassé, il lit la sortie et corrige le problème avant de relancer la vérification.

[!TIP]

Donnez à Claude quelque chose qu'il peut exécuter et qui renvoie un résultat de réussite ou d'échec. Une fois qu'il dispose de cela, il peut continuer seul et vous n'avez pas à surveiller.

La vérification peut être presque n'importe quoi, tant que Claude peut lire le résultat :

  • Un fichier de test
  • Le code de sortie d'un build
  • Un linter
  • Un script qui compare la sortie à une fixture
  • Une capture d'écran du navigateur à côté de la maquette

Si votre dépôt dispose déjà de l'un de ces éléments, la ligne la plus utile de votre CLAUDE.md est la commande qui l'exécute.

Le degré de rigueur de la vérification vous appartient. Les options vont de Claude qui décide lui-même jusqu'à Claude Code qui l'impose :

  • Dans le prompt : run the auth tests after, and keep going until they pass. Claude décide lui-même quand il est satisfait. Cela fonctionne pour n'importe quelle tâche, dès aujourd'hui, sans configuration.
  • Comme objectif : /goal all tests in tests/auth pass and lint is clean définit une condition qu'un modèle distinct vérifie par rapport à la conversation après chaque tour, et Claude continue jusqu'à ce qu'elle soit remplie. Vous en avez rarement besoin vous-même dans la session. Cela compte pour les longues exécutions en arrière-plan, où Claude termine parfois un tour par un résumé de progression alors que des éléments restent ouverts, et l'objectif le renvoie au travail.
  • Comme hook Stop : un hook Stop exécute votre script chaque fois que Claude tente de terminer son tour, et renvoie Claude au travail si le script se termine avec le code 2. Celui-ci est imposé par Claude Code (le harnais), donc le tour ne se termine pas tant que la vérification de types n'a pas réussi ou que la limite de blocages n'est pas atteinte. Il y a un exemple plus bas.
  • Par quelqu'un qui n'a pas écrit le code : dans le terminal, /code-review examine le diff dans un nouveau sous-agent qui n'a jamais vu votre conversation. Il n'est pas influencé par le raisonnement qui a produit le code.

Quelle que soit l'option utilisée, demandez à Claude des preuves : la commande qu'il a exécutée et sa sortie, ou la capture d'écran. « Tous les tests passent » à lui seul vous en dit très peu, et lire la sortie est plus rapide que de relancer la vérification vous-même. Pour une session que vous n'avez pas surveillée, c'est aussi la seule preuve dont vous disposez.

[!TIP]

Une fois que Claude dit avoir terminé, vous pouvez aussi exécuter /verify dans la session, ce qui amène Claude à compiler et exécuter l'application et à examiner le résultat. Cela détecte le genre de problème que les tests et la vérification de types manquent.

Vérifiez par rapport à votre spécification

Si vous préférez que la revue vérifie le travail par rapport à votre plan plutôt que de chercher des bugs en général, écrivez vous-même le prompt de revue :

use a subagent to review the rate limiter diff against SPEC.md, check every requirement is implemented and the listed edge cases have tests, report gaps that affect correctness and skip style

[!NOTE]

Ne supprimez pas la partie skip style de ce prompt. Un relecteur à qui l'on demande de trouver des problèmes trouvera toujours quelque chose. Si vous corrigez chaque constatation, vous vous retrouvez avec des couches d'abstraction supplémentaires et des tests pour des cas qui ne peuvent pas se produire.

Imposez la vérification avec un hook Stop

La version hook Stop de la règle de vérification de types tient en quelques lignes dans .claude/settings.json. C'est le code de sortie 2 qui bloque l'arrêt. Tout ce que la commande affiche sur stderr est renvoyé à Claude comme la raison pour laquelle il ne peut pas encore terminer, c'est pourquoi la sortie du compilateur y est redirigée :

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          { "type": "command", "command": "pnpm tsc --noEmit 1>&2 || exit 2" }
        ]
      }
    ]
  }
}

Pour le voir fonctionner, demandez à Claude une modification qui casse un type : au lieu de terminer, il reçoit les erreurs du compilateur et continue jusqu'à ce que tsc réussisse. Si le hook bloque huit arrêts d'affilée sans appel d'outil entre eux, Claude Code outrepasse le blocage suivant et termine le tour. Pour augmenter ce plafond, définissez CLAUDE_CODE_STOP_HOOK_BLOCK_CAP.

Imposez les règles qui ne tolèrent aucune exception

[!TIP]

Si quelque chose doit se produire à chaque fois, faites-en un hook, une règle de refus ou un paramètre géré. CLAUDE.md est destiné aux directives, et Claude a le droit de décider qu'une directive ne s'applique pas.

Prenez trois règles que vous pourriez avoir aujourd'hui dans CLAUDE.md : Never read .env, Always run the formatter after editing, Don't touch the migrations folder. Claude les suivra presque à chaque fois. Pour les quelques cas où « presque » ne suffit pas, sortez-les de CLAUDE.md et placez-les dans une configuration que Claude Code (le harnais) applique lui-même. Dès lors, le résultat ne dépend plus de ce dont le modèle se souvient ou de ce qu'il décide.

Imposez des étapes avec des hooks

Les hooks exécutent quelque chose qui vous appartient à des points fixes de la boucle de Claude : avant ou après un appel d'outil, lorsque Claude tente de s'arrêter, au démarrage d'une session, etc. Ce quelque chose peut être :

  • Une commande shell (le cas habituel)
  • Un POST vers un endpoint HTTP
  • Un appel d'outil sur l'un de vos serveurs MCP
  • Un hook prompt ou agent, qui laisse un modèle décider

Un hook prompt ou agent demande à un autre modèle de décider, il n'est donc pas déterministe non plus. Pour une véritable application, utilisez un hook command ou http, et ajoutez onFailure: "block" si l'action doit aussi être arrêtée lorsque le hook lui-même plante ou expire. Pour un hook qui analyse les commits à la recherche de secrets, par exemple, vous préférez bloquer le commit plutôt que de le laisser passer sans analyse pendant que le scanner est en panne.

Voici la règle du formateur sous forme de hook PostToolUse. Il s'exécute après chaque Edit ou Write, et le fait que Claude se souvienne de la règle n'a plus d'importance, car ce n'est pas Claude qui l'exécute :

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          { "type": "command", "command": "npx prettier --write --ignore-unknown \"$(jq -r '.tool_input.file_path')\"" }
        ]
      }
    ]
  }
}

Pour tester le hook, demandez à Claude d'ajouter une ligne mal indentée dans un fichier que Prettier formate. Le fichier enregistré revient avec l'indentation corrigée.

La règle des migrations devient un hook PreToolUse qui se termine avec le code 2 pour tout chemin sous migrations/. Vous n'avez pas à l'écrire vous-même : write a hook that blocks edits to the migrations folder fonctionne comme prompt, et /hooks affiche le résultat. N'en abusez pas, cependant : un hook est destiné à une règle sans aucune exception, et Prefer named exports en a beaucoup, donc celle-ci reste dans CLAUDE.md.

Limitez l'accès avec les règles de permission et le sandbox

Les règles de permission déterminent ce que Claude est autorisé à exécuter, lire et récupérer. Les règles deny s'appliquent dans tous les modes de permission, y compris auto et bypassPermissions, et c'est précisément pourquoi la règle .env y a sa place :

{
  "permissions": {
    "allow": ["Bash(pnpm tsc --noEmit)"],
    "ask": ["Bash(git push *)"],
    "deny": ["Read(./.env)", "Read(./.env.local)", "Read(./secrets/**)"]
  }
}

Une fois ceci enregistré, demander à Claude ce que contient .env échoue, aussi bien via l'outil Read que via cat .env.

Les règles correspondent à des appels d'outils, pas à des intentions, il vaut donc la peine de savoir où se situent leurs limites :

  • La règle Read intercepte bien cat .env, car Claude Code reconnaît les commandes courantes de lecture de fichiers.
  • Elle n'interceptera pas un script qui ouvre le fichier.
  • Une règle de refus WebFetch pour un domaine n'a aucun effet sur un curl vers ce même domaine, sauf si le sandbox est activé.

Pour une limite au niveau du système d'exploitation sur l'accès au système de fichiers ou au réseau, activez le sandbox avec /sandbox dans une session. Il confine les commandes shell de Claude sur macOS, Linux et WSL2 et reprend aussi vos règles de refus Read et vos règles WebFetch(domain:...), donc pour tout ce qui touche à la sécurité, vous voulez les deux.

Par défaut, Claude peut toujours demander à réessayer une commande bloquée en dehors du sandbox, et cette demande passe par le flux de permission normal. Le mode sandbox strict, dans l'onglet Overrides de /sandbox, désactive cette nouvelle tentative.

[!WARNING]

Le mode auto est un modèle classifieur qui juge chaque action plutôt qu'une règle stricte. Il le fait bien, mais comme tout jugement, il peut se tromper. Vous pouvez aussi ajuster ce qu'il considère comme risqué, et votre organisation peut le désactiver entièrement, donc vos règles « jamais » ont leur place dans des règles de refus ou des hooks.

Choisissez à qui s'applique une règle

L'emplacement d'une règle détermine à qui elle s'applique :

  • .claude/settings.local.json et ~/.claude/settings.json ne concernent que vous. Lorsque vous sélectionnez Yes, and don't ask again pour une commande, Claude Code enregistre cette règle dans le fichier local.
  • .claude/settings.json et les hooks qu'il contient appartiennent au dépôt. Une fois que vous les avez commités, ils s'appliquent à toute personne qui travaille dans le dépôt. Ses règles de refus s'appliquent immédiatement. Ses règles allow attendent que chaque personne accepte la boîte de dialogue de confiance pour ce dossier, et la confiance de l'espace de travail détermine aussi quand ses hooks commencent à s'exécuter sur sa machine.
  • Les paramètres gérés appartiennent à l'organisation. Ils proviennent de la console d'administration, d'un MDM ou d'un fichier managed-settings.json, et aucun fichier de paramètres personnel ne peut les outrepasser, ce qui en fait le seul endroit approprié pour la politique d'une équipe de sécurité. Si c'est vous qui les définissez, consultez Configurer Claude Code pour votre organisation.

Quelle que soit la portée, gardez l'ensemble imposé restreint. Chaque hook et chaque règle de refus se déclenchera parfois alors qu'il ne le devrait pas, et quelqu'un doit maintenir chacun d'eux. Si vous vous retrouvez un jour avec quarante d'entre eux, la plupart sont probablement des préférences que Claude aurait pu évaluer lui-même.

Modifiez une valeur par défaut

[!TIP]

Les valeurs par défaut sont assez bonnes pour ne pas y toucher jusqu'à ce qu'une tâche coûte plus de temps, de tokens ou d'interruptions qu'elle ne le devrait. Lorsque cela arrive, exécutez /usage dans la session pour voir où cela est passé.

Une nouvelle session prend déjà plusieurs décisions pour vous :

  • Les sessions interactives de terminal et VS Code démarrent en mode auto.
  • Elle exécute Claude Opus 5.5 avec un effort moyen sur la plupart des plans et fournisseurs.
  • Elle délègue du travail à des sous-agents lorsqu'elle voit une raison de le faire.
  • Elle compacte la conversation à mesure qu'elle grandit.

La plupart du temps, vous n'y pensez jamais. Lorsqu'une tâche coûte plus qu'elle ne le devrait, c'est généralement à cause de l'un de ces quatre points.

Changez le mode de permission

Les deux extrémités de l'éventail des permissions ont un coût :

  • Mode Manuel : vous approuvez vous-même chaque modification et chaque commande qui n'est pas en lecture seule. C'est sûr, mais après la dixième demande vous commencez à approuver sans lire, et rien n'avance lorsque vous êtes loin du clavier.
  • bypassPermissions : approuve tout ce que vos règles de refus et de demande ne couvrent pas, ce qui n'a de sens que dans un conteneur jetable.

Le mode auto se situe entre les deux, et c'est le mode dans lequel démarrent les sessions interactives de terminal et VS Code. Claude travaille sans s'arrêter pour les approbations de routine, et un modèle classifieur distinct vérifie les actions dans un ordre fixe avant leur exécution. Il se concentre sur les choses qu'une personne voudrait arrêter :

  • curl | bash
  • Les déploiements et migrations en production
  • Les force push par-dessus le travail d'autres personnes
  • Les données sensibles envoyées vers des endpoints externes
  • Les actions qui semblent dictées par du contenu que Claude a lu plutôt que par vous

Lorsqu'il bloque quelque chose, vous recevez une notification et l'action apparaît sous Recently denied dans /permissions, où vous pouvez la réessayer avec une approbation manuelle. Après trois blocages d'affilée (ou vingt au total), le mode auto se met en pause et recommence à vous demander.

Rien de tout cela ne remplace vos contrôles déterministes, car il s'exécute après eux. Les règles de refus et de demande ainsi que les hooks PreToolUse s'appliquent avant que le classifieur ne voie quoi que ce soit, donc une règle de refus bloque en mode auto exactement comme partout ailleurs. Le sandbox continue de confiner les commandes shell qu'il encapsule.

[!NOTE]

Vous pouvez aussi écrire don't push until I've reviewed dans la conversation, et le classifieur le traite comme un signal de blocage. Il s'agit toujours d'un modèle qui lit la transcription, et la phrase peut se perdre lors de la compaction de la conversation, donc tout ce qui compte a sa place dans une règle de refus.

Le problème inverse est celui d'un classifieur qui arrête à plusieurs reprises quelque chose de courant dans votre configuration. Plutôt que de l'approuver manuellement à chaque fois, ajoutez-le à autoMode.allow ou décrivez votre infrastructure de confiance dans la configuration du mode auto. Elle s'écrit en anglais courant plutôt qu'avec des motifs, et /auto-mode-setup peut rédiger pour vous la partie environment à partir de votre projet et de vos sessions récentes :

{
  "autoMode": {
    "environment": [
      "$defaults",
      "Source control: github.com/example-org and every repo under it",
      "Trusted internal domains: *.internal.example.com"
    ],
    "allow": [
      "$defaults",
      "Deploying to the staging namespace is fine, it's isolated from production and resets nightly"
    ]
  }
}

[!WARNING]

Conservez "$defaults" dans chaque liste que vous définissez, car sans lui vos entrées remplacent les règles intégrées de cette liste au lieu de s'y ajouter. Pour environment et allow, vous perdriez le contexte et les exceptions intégrés, et une liste soft_deny sans lui supprime les blocages intégrés des force push et des déploiements en production.

Le bloc autoMode doit aussi se trouver dans ~/.claude/settings.json plutôt que dans le projet, car le classifieur ignore autoMode dans les paramètres du projet.

Si vous préférez voir chaque modification et chaque commande avant qu'elles ne se produisent, Shift+Tab dans la session fait défiler les modes de permission, Manuel compris, ou démarrez avec claude --permission-mode manual depuis votre shell. Et si le mode Manuel vous sollicite alors trop souvent, /fewer-permission-prompts analyse vos transcriptions récentes à la recherche d'appels Bash et MCP courants en lecture seule et les ajoute à une liste d'autorisation dans .claude/settings.json.

Changez le modèle et l'effort

L'effort est le principal contrôle de la durée de réflexion de Claude, et il remplace la plupart de ce que l'on faisait autrefois avec la formulation des prompts. Claude Opus 5.5, Sonnet 5.5 et Haiku 5.5 utilisent medium par défaut, ce qui suffit largement pour le développement de fonctionnalités courantes avec un périmètre clair. Les moments où vous le modifieriez, avec /effort dans la session :

  • Augmentez-le avec /effort high ou /effort xhigh lorsque la réussite dépend de cas faciles à négliger. Pensez à un bug dans du code que vous n'avez pas écrit, à un test instable ou à un changement de schéma où Claude doit trouver chaque lecteur de l'ancienne forme. Claude vérifie alors davantage de cas limites et une plus grande partie de son travail avant de répondre, et c'est là que passent le temps et les tokens supplémentaires.
  • Réduisez-le avec /effort low lorsque vous faites des allers-retours rapides et examinez de toute façon chaque résultat : brainstorming, première ébauche, renommage dans quelques fichiers. Claude vous donne un point de départ plus tôt, et puisque vous pilotez chaque étape, la délibération supplémentaire n'aurait pas changé grand-chose à part l'attente.
  • Réservez max à un problème difficile que vous voulez que Claude résolve sans vous, comme la recherche d'une vulnérabilité de sécurité. Sur des tâches ordinaires, il a tendance à trop réfléchir, et vous payez donc davantage pour une réponse qui n'est peut-être pas meilleure que ce que high vous aurait donné.
  • Lorsque seul le message suivant en a besoin, comme une question délicate au milieu d'un travail par ailleurs courant, mettez ultrathink dans ce prompt au lieu de modifier le paramètre.

Pour le modèle lui-même, Opus 5.5 par défaut gère bien la plupart des tâches de code et Sonnet coûte moins cher sur le travail courant. Claude Fable 5.1 est disponible lorsque vous le sélectionnez explicitement avec /model fable, et Haiku convient bien aux sous-agents effectuant des tâches simples. Configuration du modèle présente la liste complète par plan et fournisseur.

Sachez ce que coûtent les sous-agents

Claude délègue de lui-même à des sous-agents :

  • Les recherches étendues dans la base de code vont à l'agent Explore intégré.
  • Les tâches annexes sont forkées lorsque le mode fork est activé (par défaut).
  • Les sous-agents qu'il démarre s'exécutent en arrière-plan par défaut, afin que votre conversation principale continue d'avancer.

Vous avez rarement besoin de demander quoi que ce soit de cela, mais il est utile de savoir ce que vous obtenez et ce que cela coûte.

Les sous-agents sont rentables dans ces situations :

  • Exécuter des travaux indépendants en même temps, pour que l'ensemble de la tâche se termine plus tôt
  • Garder une sortie longue, comme une exécution complète des tests ou une recherche étendue, hors de votre conversation principale, où elle resterait sinon présente pour le reste de la session
  • Obtenir un relecteur qui n'a pas vu comment le code a été écrit
  • Donner à une tâche moins d'outils que n'en a la session principale, comme un relecteur qui peut lire mais pas modifier

Ce qu'ils vous coûtent, ce sont surtout des tokens, puisque chaque sous-agent envoie ses propres requêtes et que celles-ci sont décomptées de la même utilisation que votre conversation principale. Parfois, c'est aussi du temps : un nouveau sous-agent doit d'abord rassembler un contexte que votre conversation avait déjà, et il peut donc finir par être plus lent que si vous faisiez la tâche sur place.

Et par défaut, c'est le même modèle (ou un plus petit) sur la même tâche. Vous en retirez du parallélisme ou un regard neuf, mais pas une réponse plus intelligente.

Pour dépenser moins pour eux :

  • Définissez model: haiku dans la définition d'un sous-agent si son travail est simple, comme recenser les fichiers qui importent un module ou vérifier les liens de la documentation. Ce genre de tâche n'a pas besoin du plus grand modèle, et Haiku coûte beaucoup moins cher par requête.
  • Demandez des résumés courts en retour, pour que vingt résultats ne remplissent pas votre contexte quand même.
  • Consultez /usage pour voir quelle part de votre utilisation prend chaque type de sous-agent, afin de savoir lesquels justifient leur coût.
  • Donnez à un sous-agent personnalisé dans .claude/agents/ uniquement tools: Read, Grep, Glob. C'est alors un relecteur qui ne peut rien modifier, et cette limite est imposée par Claude Code plutôt que demandée dans un prompt.

Ce relecteur tient en un court fichier, .claude/agents/reviewer.md :

---
name: reviewer
description: Reviews changed files against the spec they were built from. Use after implementing a feature, before opening the PR.
tools: Read, Grep, Glob
---
You're reviewing code you didn't write. Compare the changed files against the spec you're given,
check that every requirement is implemented and the listed edge cases have tests,
and report only the gaps that affect correctness. Skip style.

Demandez à Claude have the reviewer compare the rate limiter against SPEC.md et les lacunes reviennent dans votre session, où Claude peut les corriger.

Maîtrisez le coût et le contexte

Avec une fenêtre de 1M de tokens sur la plupart des modèles actuels et une compaction proche de sa limite, vous manquerez rarement de contexte. Vous pouvez cependant toujours payer pour du contexte dont vous n'avez pas besoin. Chaque requête envoie toute la conversation, donc une session qui a accumulé trois tâches sans rapport relit les trois à chaque tour de la quatrième. C'est à prix réduit tant que le cache est chaud et à plein tarif une fois qu'il a expiré.

/usage est le premier endroit où regarder. Sur Pro, Max, Team et Enterprise, il ventile votre utilisation par skill, sous-agent, plugin et serveur MCP. Il signale aussi des tendances comme un contexte long ou des défauts de cache fréquents dès que l'une d'elles dépasse 10 % de votre utilisation. À partir de là, les solutions habituelles :

  • /clear entre des tâches sans rapport. Cela ne coûte rien, et la tâche suivante ne continue pas à payer pour l'historique de la précédente. /clear oauth-migration nomme la session que vous quittez, afin que vous puissiez y revenir plus tard.
  • /compact avec un objectif, comme /compact keep the API changes and the test commands. Sur une longue session, /compact est lui-même une grosse requête, puisqu'il lit toute la conversation pour la résumer, et plus encore une fois le cache expiré.
  • Gardez un œil sur le travail en arrière-plan : un /loop, la vérification d'un objectif après chaque tour et les propres sous-agents de Claude continuent tous d'envoyer des requêtes pendant que vous ne tapez pas.

[!NOTE]

Le prompt caching dure environ une heure avec un abonnement et cinq minutes avec une clé API, un fournisseur cloud ou des crédits d'utilisation. Les sous-agents disposent de cinq minutes sauf si vous le modifiez.

Avec le cache d'une heure, une session de plus d'environ 200K tokens qui reste inactive est compactée peu avant l'expiration du cache, donc après le déjeuner vous reprenez à partir d'un résumé. Si vous n'avez pas du tout besoin de l'historique, une nouvelle session coûte encore moins cher.

Pilotez la session

[!TIP]

Surveillez la première minute, appuyez sur Esc dès que Claude dévie, et après deux corrections infructueuses, exécutez /clear et écrivez un meilleur prompt au lieu d'une troisième correction.

Aucune configuration ne remplace le fait de surveiller la première minute et d'intervenir lorsque Claude part dans une direction que vous n'aviez pas prévue. Il n'existe que quelques contrôles pour cela, et ils valent la peine d'être connus par cœur :

  • Esc arrête Claude en pleine action et conserve tout jusqu'à ce point, afin que vous puissiez le rediriger sans perdre de travail.
  • /rewind, ou Esc deux fois sur un prompt vide, ouvre le menu de retour en arrière, où vous ramenez le code, la conversation ou les deux à un prompt antérieur. Cela rend peu risqué le fait d'essayer d'abord l'approche la plus audacieuse et de revenir en arrière si elle ne fonctionne pas. Le même menu peut aussi résumer une partie de la conversation devenue obsolète.
  • /clear repart de zéro. Si vous avez corrigé la même chose deux fois et que c'est toujours faux, une troisième correction ne fait surtout qu'alourdir une conversation qui contient déjà deux tentatives échouées que Claude continue de relire. /clear suivi d'un nouveau prompt qui intègre ce que vous avez appris fonctionne mieux presque à chaque fois.

[!WARNING]

Les checkpoints couvrent les fichiers que Claude a modifiés avec ses propres outils de fichiers dans votre conversation principale, donc un fichier touché uniquement par une commande Bash n'est pas restauré. Ils fonctionnent aux côtés de git plutôt que de le remplacer.

Deux contrôles plus modestes : /btw répond à une question rapide sans rien ajouter à l'historique. Et pour un travail qui s'étale sur plusieurs jours, /rename oauth-migration dans la session lui donne un nom, afin que claude --resume oauth-migration depuis votre shell le reprenne plus tard, checkpoints compris. claude --continue reprend la session la plus récente.

Laissez Claude travailler sans vous

[!TIP]

Avant qu'une exécution ne se déroule sans surveillance, assurez-vous qu'elle sait à quoi ressemble « terminé », qu'elle peut vérifier son propre travail et qu'elle ne peut toucher que ce qu'elle doit. Donnez-lui une limite de tours ou de dépenses, et faites approuver le résultat par une personne à la fin.

Tout ce qui figure sur cette page compte un peu plus une fois que vous n'êtes plus là pour rattraper les erreurs. Tant que vous surveillez, le fait qu'il manque à Claude un élément de contexte n'est pas grave : vous le remarquez en un message ou deux et vous le lui dites. Dans une exécution lancée avant d'aller vous coucher, personne ne le lui dit, et vous découvrez le lendemain matin qu'il a passé toute la nuit à construire sur une hypothèse erronée.

Avant de laisser une tâche s'exécuter seule, il vaut la peine de passer en revue ces cinq questions en gardant cette tâche précise à l'esprit :

  1. Sait-elle à quoi ressemble « terminé » ? Une condition d'objectif, un fichier de spécification ou un test qui échoue et qu'elle doit faire passer au vert.
  2. Peut-elle vérifier son propre travail ? La suite de tests, un hook Stop, une étape de revue quelconque.
  3. Qu'est-elle autorisée à toucher ? Les règles de permission, dontAsk, le sandbox, un worktree, la seule branche sur laquelle elle peut pousser.
  4. Qu'est-ce qui l'arrête ? --max-turns, --max-budget-usd, une limite de dépenses.
  5. Où va le résultat, et qui le valide ? Une PR, un commentaire ou un résumé, puis une personne qui approuve la fusion, le déploiement ou toute autre action irréversible.

Une fois lancé, Claude mènera seul une longue tâche à son terme. Ce qui reste de votre ressort, c'est de la démarrer, de décider ce que « terminé » signifie cette fois-ci et d'approuver la fusion à la fin.

Exécutez Claude depuis un script

claude -p "prompt" s'exécute une fois puis se termine, et c'est ainsi que Claude Code se retrouve dans des jobs CI, des hooks git et des boucles shell.

Dans un script, vous voudrez presque toujours quelques flags supplémentaires :

  • --bare ignore les hooks, les skills, les plugins, les serveurs MCP et les fichiers CLAUDE.md, ceux du dépôt comme ceux de la machine, afin que l'exécution fasse la même chose où qu'elle s'exécute. Il ne touche jamais non plus à votre connexion claude.ai : l'authentification provient de ANTHROPIC_API_KEY, d'un apiKeyHelper dans le fichier que vous passez avec --settings, ou des identifiants de votre fournisseur cloud.
  • --append-system-prompt, --mcp-config et --settings transmettent explicitement ce dont l'exécution a besoin.
  • --allowedTools pré-approuve ses outils, et --permission-mode dontAsk refuse tout le reste qui aurait déclenché une demande.
  • --output-format json vous donne un objet résultat unique à analyser, et stream-json avec --verbose diffuse les événements au fur et à mesure.

Assemblé, cela ressemble à ceci :

for file in $(cat files.txt); do
  claude --bare -p "Migrate $file to the new logger API and commit. Reply OK or FAIL." \
    --allowedTools "Read,Edit,Bash(git add *),Bash(git commit *)" \
    --permission-mode dontAsk \
    --max-turns 20
done

Lorsqu'une exécution se termine, Claude répond OK ou FAIL, et une exécution qui atteint la limite de tours se termine plutôt avec une erreur. Essayez d'abord sur trois fichiers, voyez ce qui ne va pas, corrigez le prompt, puis lancez le reste.

Le mode auto fonctionne aussi avec -p si vous passez --permission-mode auto. Dans une exécution non interactive, un blocage du classifieur refuse cette action précise et Claude continue, et des blocages répétés ne mettent pas l'exécution en pause comme ils le font dans un terminal. Lisez comment les seuils s'y appliquent avant de vous y fier.

Démarrez des exécutions selon un planning ou un événement

Une fois une exécution lancée, Claude peut gérer le reste seul. La seule chose qu'il ne peut pas faire, c'est décider de démarrer, donc quelque chose doit le faire : vous, un minuteur ou un événement comme une vérification CI échouée ou une nouvelle PR.

Dans une session ouverte, c'est /loop, qui répète un prompt à intervalle régulier :

/loop 15m check CI on this branch, and if it's red pull the failing job's log, fix it and push

Chaque exécution est un tour supplémentaire dans la même session, donc n'en laissez pas tourner une dans une longue conversation. Pour tout ce qui doit se produire pendant que votre ordinateur portable est fermé, /schedule configure une tâche planifiée cloud qui s'exécute selon un minuteur. Elle nécessite une connexion claude.ai plutôt qu'une clé API. Vous pouvez ajouter un déclencheur basé sur un événement GitHub en le demandant à Claude, ou un déclencheur API sur claude.ai/code/routines.

[!WARNING]

Avant de laisser une tâche planifiée cloud s'exécuter, protégez main avec une règle de branche GitHub que la tâche ne peut pas contourner. Et surveillez les premières exécutions de toute nouveauté avant de lui faire confiance sans surveillance.

Exécutez des sessions en parallèle

Lorsque vous menez plusieurs travaux distincts en même temps, donnez à chacun son propre checkout afin que les modifications ne puissent pas entrer en collision. claude -w feature-auth démarre une session dans un nouveau worktree, l'application de bureau en exécute plusieurs côte à côte, et les sessions cloud les exécutent dans le cloud plutôt que sur votre machine.

Un worktree est un checkout neuf, ce qui signifie que les fichiers ignorés par git comme .env n'y sont pas et que les dépendances ne sont pas installées. Pour le premier point, listez les fichiers ignorés par git dont vous avez besoin dans un .worktreeinclude à la racine du dépôt (même syntaxe que .gitignore) et Claude Code les copie dans chaque worktree qu'il crée :

.env
.env.local
config/dev-credentials.json

Limitez-vous à de petits fichiers : il copie plutôt que de lier, donc y mettre node_modules signifierait une copie complète par worktree. Pour les grands répertoires, il existe le paramètre worktree.symlinkDirectories, ou bien gardez la commande d'installation dans CLAUDE.md pour que Claude l'exécute chaque fois qu'il démarre dans un nouveau checkout.

Vous avez rarement à faire le ménage vous-même :

  • Lorsque vous quittez une session de worktree sans nom, Claude Code supprime le worktree s'il ne contient rien. Pour une session nommée, ou une session avec des modifications, il vous demande quoi faire.
  • Les worktrees des sous-agents disparaissent lorsque le sous-agent se termine sans modifications.
  • Les worktrees de sous-agents et de sessions en arrière-plan qui restent malgré tout sont nettoyés une fois qu'ils sont plus anciens que cleanupPeriodDays et ne contiennent aucun travail.

[!NOTE]

Une exécution claude -p --worktree est à nettoyer vous-même, puisqu'elle se termine sans rien demander. Supprimez ces worktrees avec git worktree remove <path>, et si git refuse parce que le worktree est verrouillé, exécutez d'abord git worktree unlock <path>.

Pour une grosse modification mécanique sur de nombreux fichiers, /batch migrate every handler to the v2 response helpers divise le travail en 5 à 30 unités et vous montre le plan. Il exécute ensuite chaque unité dans son propre worktree et ouvre une PR pour chacune. Depuis votre shell, claude agents (encore en research preview) vous donne un seul écran pour tout ce qui s'exécute en arrière-plan sur votre machine.

Une deuxième session est aussi le relecteur indépendant le plus facile à obtenir. Une session écrit le limiteur de débit, une autre examine @src/middleware/rateLimiter.ts sans l'avoir vu s'écrire, et vous recollez les constatations dans la première. Même idée que /code-review, mais c'est vous qui transportez les messages.

Ce que vous pouvez arrêter de faire

Chacun de ces conseils était judicieux au moment où il a été écrit. La plupart étaient des contournements pour quelque chose que le modèle ne pouvait pas encore faire de manière fiable, et les modèles ont depuis rattrapé leur retard. Si certains sont encore des habitudes, voici pourquoi vous pouvez les abandonner sans risque.

L'ancien conseil Pourquoi il n'a plus lieu d'être
La fenêtre de contexte est votre principale contrainte, gérez-la agressivement La plupart des modèles actuels ont une fenêtre de 1M de tokens et la compaction se fait d'elle-même, il est donc rare d'en manquer. /clear entre les tâches vaut toujours la peine, car un contexte ciblé vous donne de meilleures réponses et coûte moins cher.
Ajoutez IMPORTANT ou des MAJUSCULES aux instructions que Claude ne cesse de manquer Les modèles plus anciens avaient parfois besoin de cette emphase. Les actuels suivent une ligne formulée simplement, et accumuler l'emphase pousse surtout Claude à sur-appliquer la règle. S'il s'agit d'une règle qui ne peut pas fléchir, transformez-la en hook ou en règle de refus. Si la ligne se perd dans un long fichier, c'est le fichier qui doit être raccourci.
Utilisez des sous-agents pour protéger votre fenêtre de contexte Manquer de contexte est rarement le problème désormais. Les sous-agents restent excellents pour le travail en parallèle, pour tenir les sorties bruyantes à l'écart et pour la revue indépendante, mais chacun de ces usages coûte des tokens supplémentaires.
Déléguez à un sous-agent pour obtenir une meilleure réponse Confier la même tâche à un sous-agent ne rend pas la réponse meilleure. Un relecteur neuf aide bien, parce qu'il n'a pas vu votre raisonnement, mais c'est autre chose que déléguer.
think hard, think harder, be thorough dans le prompt L'effort est le contrôle prévu pour cela. Ces expressions sont du texte de prompt ordinaire qui oriente Claude dans les limites de son niveau d'effort, plutôt que des mots-clés qui l'augmentent. ultrathink fonctionne toujours : il demande un raisonnement plus approfondi pour ce seul tour sans toucher à votre paramètre d'effort.
Dites à Claude de continuer, de boucler jusqu'à ce que ce soit fini, de ne pas être paresseux Les modèles actuels mènent généralement une tâche convenue à son terme sans qu'on le leur dise, et ce genre de ligne risque davantage de provoquer un excès de travail que de résoudre un blocage. Donner à Claude une vérification à réussir est différent, et vaut toujours la peine. Si une exécution s'arrête trop tôt, dites continue, et pour les exécutions que personne ne surveille, /goal ou un hook Stop l'impose.
Décrivez votre architecture et l'organisation de vos fichiers dans CLAUDE.md Claude lit lui-même le dépôt. N'écrivez que ce qui ne s'y trouve pas.

Si un autre conseil de cette page commence un jour à ressembler à une corvée, c'est probablement le signe qu'il a lui aussi sa place dans ce tableau.

Ressources connexes