Claude Code - tout ce qu’on peut configurer et que la documentation ne dit pas

(buildingbetter.tech)

1 points par GN⁺ 3 시간 전 | 1 commentaires | Partager sur WhatsApp

Claude Code 2.1.87 comporte de nombreux réglages non documentés, et il est possible d’appliquer séparément Hooks, Skills et Agents via des fichiers .claude/ personnels ou propres au projet
Un Hook ne se limite pas au JSON reçu sur stdin et au code de sortie : grâce aux champs JSON propres à chaque événement sur stdout, il peut aussi modifier des commandes, décider des autorisations, injecter du contexte et même surveiller des fichiers
Les champs de Hook absents de la documentation, once, async et asyncRewake, permettent de mettre en place une exécution unique, des journaux d’audit en arrière-plan et des flux de blocage de sécurité asynchrones
Skills et Agents utilisent un frontmatter caché pour contrôler le modèle, l’effort, les Hooks à portée limitée, la délégation à un Agent, la mémoire persistante, l’omission de CLAUDE.md et les dépendances MCP
Auto Mode, la mémoire automatique, Dream, Magic Docs, les glob d’autorisations et context: fork rapprochent Claude Code d’un environnement de développement apprenant

Version de référence et emplacement des fichiers

Le contenu se base sur @anthropic-ai/claude-code@2.1.87, et les fonctionnalités non documentées peuvent changer d’une release à l’autre
Les champs dont le nom contient EXPERIMENTAL sont signalés comme instables par des ingénieurs d’Anthropic et peuvent être supprimés ou renommés
Emplacement des fichiers de configuration
- Configuration personnelle : ~/.claude/settings.json
- Configuration du projet : .claude/settings.json
Emplacement des Skills
- Personnel : ~/.claude/skills/<name>/SKILL.md
- Projet : .claude/skills/<name>/SKILL.md
Emplacement des Agents
- Personnel : ~/.claude/agents/<name>.md
- Projet : .claude/agents/<name>.md
Il est recommandé de placer les scripts Hook dans ~/.claude/hooks/, et chmod +x est nécessaire pour pouvoir les exécuter
Les fichiers .claude/ au niveau du projet peuvent être commités dans Git et partagés avec l’équipe, tandis que les fichiers personnels sous ~/.claude/ ne s’appliquent qu’à l’utilisateur

Les Hooks peuvent modifier le comportement de Claude Code via du JSON sur stdout

La documentation officielle ne couvre que le flux où un Hook reçoit du JSON sur stdin et bloque une action avec le code de sortie 2, mais en pratique, les champs JSON propres à chaque événement sur stdout permettent de modifier en temps réel le comportement de Claude Code
Champs renvoyables dans PreToolUse
- updatedInput : permet de réécrire l’entrée avant l’exécution de l’outil afin de modifier la commande
- permissionDecision : permet de forcer allow ou deny sans demander à l’utilisateur
- permissionDecisionReason : permet d’afficher la raison de la décision dans l’interface
- additionalContext : permet d’injecter du texte dans le contexte de la conversation
Champs renvoyables dans SessionStart
- watchPaths : permet de configurer une surveillance automatique des fichiers pour déclencher des événements FileChanged
- initialUserMessage : permet d’ajouter du contenu avant le premier message utilisateur de la session
- additionalContext : permet d’injecter un contexte conservé pendant toute la session
Champs renvoyables dans PostToolUse
- updatedMCPToolOutput : permet de modifier la réponse d’un outil MCP telle que vue par Claude
- additionalContext : permet d’injecter du contexte après l’exécution de l’outil
Champs renvoyables dans PermissionRequest
- decision : permet d’autoriser ou de refuser de manière programmatique avec updatedInput ou updatedPermissions
Hook qui remplace automatiquement git push par --dry-run
- Dans un Hook PreToolUse, on peut inspecter une commande Bash et, si elle contient git push, utiliser updatedInput pour ajouter --dry-run à la fin de la commande
- Claude croit exécuter git push origin main, mais le Hook le transforme en git push origin main --dry-run avant l’exécution réelle

{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{
        "type": "command",
        "command": "~/.claude/hooks/dry-run-pushes.sh"
      }]
    }]
  }
}

#!/bin/bash
INPUT=$(jq -r '.tool_input.command' < /dev/stdin)
if echo "$INPUT" | grep -q 'git push'; then
  jq -n --arg cmd "$INPUT --dry-run" '{"updatedInput": {"command": $cmd}}'
fi

Hook qui injecte une surveillance de fichiers et un contexte Git au démarrage de la session
- Le Hook SessionStart peut définir package.json, .env et tsconfig.json comme fichiers à surveiller, et ajouter au contexte de la session la branche courante ainsi que le nombre de fichiers non commités

{
  "hooks": {
    "SessionStart": [{
      "hooks": [{
        "type": "command",
        "command": "~/.claude/hooks/session-context.sh",
        "statusMessage": "Loading project context..."
      }]
    }]
  }
}

#!/bin/bash
BRANCH=$(git branch --show-current 2>/dev/null)
CHANGES=$(git status --porcelain 2>/dev/null | wc -l | tr -d ' ')

jq -n \
  --arg branch "$BRANCH" \
  --arg changes "$CHANGES" \
  '{
    "watchPaths": ["package.json", ".env", "tsconfig.json"],
    "additionalContext": "Current branch: \($branch). Uncommitted changes: \($changes) files."
  }'

Hook qui approuve automatiquement les commandes Bash en lecture seule
- Des commandes comme ls, cat, echo, pwd, whoami, date, git status, git log et git diff peuvent être laissées passer sans confirmation utilisateur avec permissionDecision: "allow"

{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{
        "type": "command",
        "command": "~/.claude/hooks/auto-approve-readonly.sh"
      }]
    }]
  }
}

#!/bin/bash
CMD=$(jq -r '.tool_input.command' < /dev/stdin)
if echo "$CMD" | grep -qE '^(ls|cat|echo|pwd|whoami|date|git status|git log|git diff)'; then
  echo '{"permissionDecision": "allow", "permissionDecisionReason": "Safe read-only command"}'
fi

Trois champs de configuration de Hook absents de la documentation

Les champs de Hook documentés sont type, command, matcher, timeout, if, statusMessage, mais le parseur du code source accepte aussi once, async, asyncRewake
once: true
- Exécute automatiquement le Hook une seule fois puis le supprime, ce qui convient bien à la configuration de la première session
- Cela permet de créer un flux qui copie .env.example vers .env si .env n’existe pas, puis ne se relance plus ensuite

{
  "hooks": {
    "SessionStart": [{
      "hooks": [{
        "type": "command",
        "command": "[ -f .env ] || cp .env.example .env && echo 'Created .env from template'",
        "once": true,
        "statusMessage": "First-time setup..."
      }]
    }]
  }
}

async: true
- Exécute le Hook en arrière-plan sans bloquer l’avancement de Claude
- Peut servir à enregistrer toutes les commandes Bash dans ~/.claude/audit.jsonl sans ajouter de latence à la session

{
  "hooks": {
    "PostToolUse": [{
      "matcher": "Bash",
      "hooks": [{
        "type": "command",
        "command": "jq '{timestamp: now, command: .tool_input.command, session: .session_id}' < /dev/stdin >> ~/.claude/audit.jsonl",
        "async": true
      }]
    }]
  }
}

asyncRewake: true
- Sur le chemin normal, s’exécute en arrière-plan comme async, mais si le processus se termine avec le code de sortie 2, le modèle est réveillé à nouveau pour bloquer la tâche
- Permet d’inspecter chaque fichier écrit par Claude pour y détecter des motifs password, secret, api_key codés en dur et bloquer si nécessaire

{
  "hooks": {
    "PostToolUse": [{
      "matcher": "Write|Edit",
      "hooks": [{
        "type": "command",
        "command": "~/.claude/hooks/scan-secrets.sh",
        "asyncRewake": true,
        "statusMessage": "Scanning for secrets..."
      }]
    }]
  }
}

#!/bin/bash
FILE=$(jq -r '.tool_input.file_path // .tool_response.filePath' < /dev/stdin)
if grep -qE '(password|secret|api_key)\s*=' "$FILE" 2>/dev/null; then
  exit 2
fi
exit 0

Champs cachés du frontmatter des Skills

La documentation couvre name, description, allowed-tools, argument-hint, when_to_use, context, mais le parseur réel accepte aussi six champs supplémentaires
model
- Permet de changer le modèle d’exécution du Skill : haiku pour les tâches rapides et peu coûteuses, opus pour les analyses complexes

---
name: quick-lint
description: Fast lint check using the cheapest model
model: haiku
effort: low
allowed-tools: Bash, Read
argument-hint: "[file]"
---
Run the project linter on: $ARGUMENTS
Detect the linter from config (eslint, ruff, clippy) and run it. Report only errors, not warnings.

effort
- Contrôle à quel point le modèle réfléchit en profondeur, avec les valeurs low, medium, high, max
- Est mappé en interne au système d’effort qui pilote la profondeur de raisonnement par réponse
hooks
- Permet de définir des Hooks à portée limitée qui ne sont enregistrés que lorsque le Skill est actif, puis retirés une fois terminé
- Peut par exemple servir à lancer une vérification de types de façon synchrone à chaque écriture d’un fichier TypeScript, et exécuter le lint en arrière-plan

---
name: strict-typescript
description: Write TypeScript with type checking on every save
allowed-tools: Bash, Read, Write, Edit, Grep, Glob
hooks:
  PostToolUse:
    - matcher: "Write|Edit"
      hooks:
        - type: command
          command: "~/.claude/hooks/typecheck-on-save.sh"
          statusMessage: "Type checking..."
        - type: command
          command: "~/.claude/hooks/lint-on-save.sh"
          async: true
---
Write TypeScript with strict enforcement. Every file you touch gets type-checked and linted automatically.
$ARGUMENTS

agent
- Permet de déléguer l’exécution du Skill à un Agent personnalisé

---
name: deep-review
description: Thorough security review delegated to the review agent
agent: security-review
---
Review the following: $ARGUMENTS

disable-model-invocation: true
- Empêche l’appel automatique et limite l’exécution aux appels explicites via /skill-name, ce qui convient aux Skills destructifs
shell: bash
- Indique le shell à utiliser pour l’exécution

Champs cachés du frontmatter des Agent

Les Agent personnalisés dans .claude/agents/ prennent aussi en charge des champs de frontmatter non documentés
color
- Permet de définir la couleur de l’interface sur red, orange, yellow, green, blue, purple, pink, ou gray
- Utile pour distinguer visuellement plusieurs Agent lorsqu’ils s’exécutent en parallèle
memory
- Donne à l’Agent une mémoire persistante entre les appels
- user : conservée globalement sur tous les projets
- project : conservée par projet
- local : mémoire privée par projet, exclue de Git
- Un reviewer sécurité peut suivre les problèmes déjà détectés, et un reviewer de code peut se souvenir des habitudes de l’utilisateur au-delà d’une session

---
name: codebase-guide
description: Answer questions about the codebase, learning more with each session
tools: [Read, Grep, Glob, Bash]
color: green
memory: project
---
You are a codebase guide with persistent memory. Check your memory first before exploring the code.

omitClaudeMd: true
- Ignore le chargement de la hiérarchie d’instructions CLAUDE.md, ce qui convient à un reviewer “fresh eyes” qui juge selon les standards du secteur plutôt que selon les conventions du projet

---
name: fresh-eyes
description: Review code without project-specific biases
tools: [Read, Grep, Glob]
omitClaudeMd: true
effort: high
color: blue
---
Review this code purely from first principles. You have no project context. Focus on correctness, security, performance, and readability by industry standards.

criticalSystemReminder_EXPERIMENTAL
- Réinjecte un court message comme rappel système à chaque tour, ce qui le maintient dans le contexte même après compression de la conversation
- Le nom du champ contient lui-même EXPERIMENTAL, il est donc instable et convient plutôt à des rappels de sécurité d’appoint qu’à une infrastructure critique

---
name: prod-deployer
description: Manages production deployments with strict safety checks
tools: [Bash, Read, Grep]
color: red
criticalSystemReminder_EXPERIMENTAL: "Always run migrations with --dry-run first. Never skip the staging verification step."
---

requiredMcpServers
- Liste les motifs de noms de serveurs MCP requis ; si ces serveurs sont absents, l’Agent n’apparaît pas
- Cela évite de charger un Agent dont les dépendances ne sont pas prêtes

Le classificateur d’Auto Mode reçoit une description d’environnement en langage naturel

Le champ autoMode de settings.json configure le classificateur d’approbation automatique qu’Anthropic appelle en interne le « YOLO Classifier »
Les motifs allow sont approuvés automatiquement, et les motifs soft_deny exigent toujours une confirmation
Le tableau environment n’est pas un ensemble de motifs, mais un contexte en langage naturel lu par le classificateur, qui permet de décrire l’environnement du projet afin d’éclairer son jugement sur la sûreté des commandes ambiguës

{
  "autoMode": {
    "allow": [
      "Bash(npm test)",
      "Bash(npm run *)",
      "Bash(git status)",
      "Bash(git diff *)",
      "Bash(git log *)",
      "Read",
      "Grep",
      "Glob"
    ],
    "soft_deny": [
      "Bash(git push *)",
      "Bash(rm *)",
      "Write(.env*)"
    ],
    "environment": [
      "NODE_ENV=development",
      "This is a local dev machine with no production database access",
      "All Docker containers use isolated networks",
      "The test suite is safe to run repeatedly, it uses a dedicated test database"
    ]
  }
}

Une phrase comme This project uses Docker, all commands run in containers aide le classificateur à comprendre l’environnement
No production access l’amène à être moins conservateur face aux opérations destructrices, et Test database is isolated signale que l’exécution des tests est toujours sûre

Boucle d’intégration entre mémoire automatique et Dream

Activer autoMemoryEnabled et autoDreamEnabled dans settings.json active le système d’auto-amélioration de Claude Code

{
  "autoMemoryEnabled": true,
  "autoDreamEnabled": true
}

autoMemoryEnabled
- Après chaque conversation, un Agent en arrière-plan extrait de la session les informations qui méritent d’être conservées à long terme
- Il enregistre les préférences utilisateur, les patterns de la base de code et les décisions dans ~/.claude/projects/<path>/memory/ au format standard de frontmatter de mémoire
autoDreamEnabled
- Toutes les 24 heures, si au moins 5 sessions se sont accumulées, un Agent en arrière-plan examine les transcripts des sessions passées pour consolider la mémoire
- Il fusionne les doublons, résout les contradictions, convertit les dates relatives en dates absolues et supprime les éléments obsolètes
- Lorsque les deux paramètres sont activés ensemble, cela crée une boucle d’apprentissage où les sessions produisent de la mémoire, Dream consolide cette mémoire, et la mémoire consolidée est réinjectée dans les sessions suivantes
- Après quelques semaines, Claude Code peut ainsi donner l’impression de se souvenir des préférences, conventions et schémas récurrents de l’utilisateur sans réentraînement du modèle

Format des Magic Docs

Les Magic Docs sont détectés via l’expression régulière /^#\s*MAGIC\s+DOC:\s*(.+)$/im
Il doit s’agir d’un titre H1, et la casse n’est pas prise en compte
La ligne suivante peut contenir une instruction en italique entourée de _underscores_ ou de *asterisks*, qui limite le périmètre sur lequel l’Agent de mise à jour doit se concentrer

# MAGIC DOC: API Endpoint Reference
_Only document public REST endpoints. Include method, path, request body, response schema, and auth requirements._

## Endpoints

(content auto-maintained by Claude Code)

Sans instruction, l’Agent essaie de mettre à jour l’ensemble du contenu
Avec une instruction, il suit un périmètre du type only track public endpoints ou focus on breaking changes
L’Agent de mise à jour s’exécute en arrière-plan et est limité à l’édition de ce seul fichier
Si l’en-tête est supprimé, le suivi s’arrête automatiquement

Syntaxe complète des règles d’autorisation

La documentation montre des exemples de base comme Bash(git *), mais le véritable langage de motifs couvre largement Bash, les chemins de fichiers et les outils MCP

Bash(npm *)              # wildcard after "npm "
Bash(git commit *)       # specific subcommand
Read(*.ts)               # file extension
Read(src/**/*.ts)        # recursive directory with extension
Write(src/**)            # recursive, all files
mcp__slack               # all tools on slack server
mcp__slack__*            # explicit wildcard (same effect)
mcp__slack__post_message # specific tool
Bash(npm:*)              # legacy colon prefix (word boundary)

* effectue une correspondance à l’intérieur d’une frontière, comme un glob de shell, et ** effectue une correspondance récursive sur les répertoires
Les autorisations des outils MCP utilisent le format à double underscore mcp__<server>__<tool>
Le champ if des hooks utilise aussi la même syntaxe, et il s’agit d’un glob, pas d’une expression régulière

{
  "permissions": {
    "allow": [
      "Bash(npm *)", "Bash(git status)", "Bash(git diff *)",
      "Read(src/**)", "Read(tests/**)", "Grep", "Glob",
      "mcp__database__query"
    ],
    "deny": [
      "Bash(rm -rf *)", "Write(/etc/**)", "Write(.env*)",
      "mcp__slack__delete_*"
    ],
    "ask": [
      "Bash(git push *)", "Write(*.json)", "Write(*.lock)",
      "mcp__slack__post_message"
    ]
  }
}

`context: fork` et l’impact du choix du modèle sur le cache

Si context: fork est défini pour une Skill, elle s’exécute comme un subagent forké en arrière-plan
Le fork partage le prompt cache du parent via un contrat typé appelé CacheSafeParams, et génère un préfixe de requête API strictement identique au niveau des octets afin d’augmenter le taux de hit du cache
Si un autre modèle est spécifié pour la Skill forkée, le préfixe change et cela peut casser le cache
Si la conversation parente utilise Opus et que le fork utilise Haiku, le préfixe diffère, ce qui provoque un cache miss et entraîne le coût complet
Dans une Skill forkée, il faut omettre le champ model ou utiliser model: inherit pour préserver le cache
context: fork convient bien aux tâches lourdes comme les scans de sécurité, l’analyse des dépendances, la génération de documentation ou l’exécution d’une suite de tests, tandis que la conversation principale reste réactive

---
name: full-audit
description: Comprehensive codebase audit running in the background
context: fork
allowed-tools: Bash, Read, Grep, Glob, WebSearch
effort: high
---
Run a comprehensive audit:
- Security scan (grep for dangerous patterns, check dependencies for CVEs)
- Code quality (duplicated logic, dead code, missing error handling)
- Test coverage (untested critical paths)
- Dependency health (outdated packages, unused deps, license issues)

Write a detailed report to /tmp/audit-report.md when complete.

Exemples de combinaison de fonctionnalités

Relecteur de code avec mémoire persistante et hook de portée
- L’agent lit la mémoire propre à la base de code, relit à la fois les motifs déjà repérés et les nouveaux problèmes, puis enregistre ensuite les nouvelles constatations dans la mémoire
- Après plusieurs revues, cela aide à repérer des problèmes récurrents propres au projet qu’un relecteur classique pourrait manquer

---
name: reviewer
description: Code reviewer that learns your codebase patterns over time
tools: [Read, Grep, Glob, Bash]
effort: high
color: yellow
memory: project
hooks:
  PostToolUse:
    - matcher: "Bash"
      hooks:
        - type: command
          command: "~/.claude/hooks/log-review.sh"
          async: true
---
Before reviewing, read your memory for past findings on this codebase.

Review git diff HEAD~1 for:
- Patterns you've flagged before (check memory)
- New issues worth flagging
- Resolved issues from past reviews

After review, save to memory:
- New patterns found (type: feedback)
- Recurring issues (type: project)

End with VERDICT: PASS, FAIL, or NEEDS_REVIEW.

Configuration de session combinant surveillance de fichiers et filet de sécurité asyncRewake
- Au démarrage de la session, le contexte du projet est chargé, les commandes Bash en lecture seule sont automatiquement approuvées immédiatement, et les commandes dangereuses sont bloquées via une vérification de sécurité asynchrone
- Les commandes en lecture seule passent rapidement, les commandes dangereuses sont bloquées, et le reste suit le flux d’autorisation habituel

{
  "hooks": {
    "SessionStart": [{
      "hooks": [{
        "type": "command",
        "command": "~/.claude/hooks/session-context.sh",
        "statusMessage": "Loading project context..."
      }]
    }],
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{
        "type": "command",
        "command": "~/.claude/hooks/auto-approve-readonly.sh"
      }, {
        "type": "command",
        "command": "~/.claude/hooks/block-dangerous.sh",
        "asyncRewake": true,
        "statusMessage": "Safety check..."
      }]
    }]
  }
}

#!/bin/bash
CMD=$(jq -r '.tool_input.command' < /dev/stdin)
echo "$CMD" | grep -qE '(rm -rf /|sudo rm|chmod 777|> /dev/)' && exit 2 || exit 0

Revue d’architecture combinant override du modèle, contrôle de effort et délégation à un agent
- effort: max spécifie une analyse approfondie, délègue à un agent spécifique, et omitClaudeMd: true pour cet agent réduit l’influence des conventions existantes du projet

---
name: architecture-review
description: Deep architecture review using max effort, delegated to fresh-eyes agent
agent: fresh-eyes
effort: max
---
Review the architecture of this project. Ignore existing conventions (the agent has omitClaudeMd: true).
Focus on: $ARGUMENTS

Evaluate structural decisions, dependency graph health, separation of concerns, and scalability characteristics.

Signification et limites

Le système de hooks avec des champs de réponse par événement fonctionne comme une couche middleware programmable pour l’usage d’outils IA
La mémoire persistante des agents permet de créer des experts IA qui accumulent de l’expérience au-delà d’une session
Le système d’intégration Dream fournit une structure qui apprend à partir de l’expérience de session sans réentraînement du modèle
Le classificateur Auto Mode prend des descriptions en langage naturel de l’environnement et les intègre dans l’évaluation de sécurité
Ces fonctionnalités, plus que des réglages cachés ou des easter eggs, constituent des briques de base pour un environnement de développement IA persistant, apprenant et autonome, déjà présentes dans le package npm actuel

Vous voulez continuer à recevoir des sujets tech sélectionnés ? Suivez le canal Telegram. @GeekNewsFR

1 commentaires

GN⁺ 3 시간 전

Avis sur Hacker News

Après vérification avec Pangram, cela ressemble clairement à un texte généré par IA
Je suis surpris que ça ait été autant upvoté, et je me demande même si les gens ont vraiment lu l’article. Je sais que @dang a mis en place des règles contre les contenus générés par IA dans les commentaires, mais qu’il a jusqu’ici hésité à le faire pour les articles. Personnellement, j’aimerais qu’il y ait aussi un drapeau de signalement sur les articles pour éviter de perdre du temps avec ce genre de contenu de mauvaise qualité
Tout cela est déjà documenté [1]. Once est documenté [2], async et asyncRewake aussi [3]. Le frontmatter des Skills est lui aussi entièrement documenté [4], et les variables d’environnement d’Automode figurent également dans la documentation [5]
Cet article est du pur clickbait rédigé par IA, donc je suis surpris de voir un accueil aussi positif ici
[1] https://code.claude.com/docs/en/hooks#pretooluse-decision-co...
[2] https://code.claude.com/docs/en/hooks#common-fields
[3] https://code.claude.com/docs/en/hooks#command-hook-fields
[4] https://code.claude.com/docs/en/skills#frontmatter-reference
[5] https://code.claude.com/docs/en/auto-mode-config#define-trus...
Cet article date de deux mois, donc une partie du contenu est ancienne et certaines fonctionnalités sont désormais documentées
Par exemple, la documentation d’auto mode est ici : https://code.claude.com/docs/en/auto-mode-config#define-trus...
Le paquet claude sort dix nouvelles versions par semaine, et de nouveaux modèles arrivent tous les quelques mois, donc il ne faut pas dépendre de bidouilles non documentées autour de tout ça
Ça change, ça casse, et il est très probable que des réglages trop détaillés cessent de fonctionner
- D’après mon expérience, les bidouilles non documentées cassent à peu près aussi souvent que les fonctionnalités documentées
  Comme quand ils ont sorti 1M Opus, affirmé que « la fenêtre de contexte n’est plus un problème », puis supprimé l’option « clear context and execute plan »
- On peut créer une automatisation qui gère efficacement les réglages utilisateur de bas niveau à chaque nouvelle version
- C’est vrai, mais des hacks temporaires peuvent parfois sauver ou ruiner un workflow de pointe
  Je ne repense pas les instructions Claude à chaque release, mais pour certaines releases ça vaut le coup de vérifier si les instructions existantes correspondent encore au modèle actuel, et cela a effectivement produit une différence visible
Le nombre de fonctionnalités dans Claude Code est étourdissant. À ce rythme, le prochain pape viendra d’Anthropic
- Blague à part, Anthropic sort tellement de choses qu’il devient difficile de leur faire confiance
  Avec cette approche, il est difficile d’imaginer un produit suffisamment réfléchi et stable
Ils présentent ça comme un « Honest status », en expliquant honnêtement pourquoi ce n’est pas à 100 % et pourquoi il prend un chemin plus long, https://github.com/user-attachments/assets/961eff6c-0060-45d...
Franchement, j’aimerais juste que Claude Code n’abandonne pas avant d’avoir terminé la tâche. C’est vraiment agaçant. Même avec /goal ou le nouveau ultracode, il finit quand même par renoncer. Mon projet est certes assez complexe (https://github.com/mohsen1/tsz), mais Codex, lui, n’a aucun problème à continuer sans s’arrêter
- Maintenant, j’utilise /loop pour lui donner un prompt qui l’encourage à continuer
  Goal peut aussi servir, mais pour certaines tâches une simple boucle est meilleure
- Je viens justement de demander à Claude de remplir une liste de tâches, et avant même d’arriver au bout il m’a demandé s’il devait continuer ou si ce qu’il avait déjà fait suffisait
Je me demande s’il est en train d’émerger une architecture d’application d’agent de code IA plus ou moins commune à l’ensemble des modèles LLM
Je me demande aussi si quelqu’un rassemble et organise des moyens de comprendre ce style d’architecture
- On parle bien du même site ? Il y a encore des gens qui utilisent autre chose de nos jours ?
- Les schémas semblent converger entre Claude Code, Codex et Cursor : collecte de contexte, planification, exécution, vérification
  La partie moins standardisée, c’est le degré de contrôle laissé à l’utilisateur entre chaque étape. Des réglages comme showClearContextOnPlanAccept ou disableAutoMode sont intéressants parce qu’ils révèlent la frontière entre « l’agent décide » et « l’humain relit avant exécution ». C’est aussi là, à l’usage, que les agents de code continueront probablement à se différencier fortement
Je suis curieux à propos de la fonctionnalité « magic doc ». Je ne sais pas si cela se met dans CLAUDE.md ou dans un fichier du projet
Je me demande aussi s’il faut mentionner ce fichier pendant la session, ou si Claude trouve automatiquement partout dans le projet ce qui contient l’en-tête « magic doc »
Peut-on demander à Claude de créer lui-même sa configuration ? Quelque chose comme : « Imagine que tu es moi, et produis l’ensemble optimal de fichiers de configuration que tu voudrais avoir »
- D’après la documentation, si CLAUDE_CODE_NEW_INIT est défini à 1, /init s’exécute comme un flux de configuration interactif
  Ce flux explore le codebase et demande quels fichiers créer — CLAUDE.md, skills, hooks, etc. — avant d’écrire quoi que ce soit. Sans cette variable, /init génère automatiquement CLAUDE.md sans poser de question
- Ça semble probablement possible. Il paraît y avoir un outil intégré pour explorer sa propre documentation, ainsi qu’un mode spécial pour travailler dans le répertoire .claude/
  On dirait que c’est prévu pour être utilisé ainsi
- J’aimerais bien qu’il existe un projet cookie cutter avec tous les fichiers boilerplate intégrant les bonnes pratiques
- Il existe une commande slash qui parcourt l’historique de la conversation et ajoute les autorisations nécessaires
- Oui, c’est possible. Claude est assez doué pour s’auto-modifier
Vous allez découvrir le plaisir de voir une fonctionnalité non documentée sur laquelle vous comptiez cesser soudainement de fonctionner
- Si, comme Anthropic l’affirme, l’ingénierie logicielle est vraiment un problème résolu, alors n’importe qui devrait pouvoir le recréer en vibe coding
  S’ils n’étaient pas allergiques au mot « open », ils auraient publié Claude Code en open source ; à ce stade, il n’y a plus vraiment de raison concrète de ne pas le faire

Claude Code - tout ce qu’on peut configurer et que la documentation ne dit pas

Version de référence et emplacement des fichiers

Les Hooks peuvent modifier le comportement de Claude Code via du JSON sur stdout

Champs renvoyables dans PreToolUse

Champs renvoyables dans SessionStart

Champs renvoyables dans PostToolUse

Champs renvoyables dans PermissionRequest

Hook qui remplace automatiquement git push par --dry-run

Hook qui injecte une surveillance de fichiers et un contexte Git au démarrage de la session

Hook qui approuve automatiquement les commandes Bash en lecture seule

Trois champs de configuration de Hook absents de la documentation

once: true

async: true

asyncRewake: true

Champs cachés du frontmatter des Skills

model

effort

hooks

agent

disable-model-invocation: true

shell: bash

Champs cachés du frontmatter des Agent

color

memory

omitClaudeMd: true

criticalSystemReminder_EXPERIMENTAL

requiredMcpServers

Le classificateur d’Auto Mode reçoit une description d’environnement en langage naturel

Boucle d’intégration entre mémoire automatique et Dream

autoMemoryEnabled

autoDreamEnabled

Format des Magic Docs

Syntaxe complète des règles d’autorisation

context: fork et l’impact du choix du modèle sur le cache

Exemples de combinaison de fonctionnalités

Relecteur de code avec mémoire persistante et hook de portée

Configuration de session combinant surveillance de fichiers et filet de sécurité asyncRewake

Revue d’architecture combinant override du modèle, contrôle de effort et délégation à un agent

Signification et limites

À lire aussi

1 commentaires

Avis sur Hacker News

Champs renvoyables dans `PreToolUse`

Champs renvoyables dans `SessionStart`

Champs renvoyables dans `PostToolUse`

Champs renvoyables dans `PermissionRequest`

Hook qui remplace automatiquement `git push` par `--dry-run`

`once: true`

`async: true`

`asyncRewake: true`

`model`

`effort`

`hooks`

`agent`

`disable-model-invocation: true`

`shell: bash`

`color`

`memory`

`omitClaudeMd: true`

`criticalSystemReminder_EXPERIMENTAL`

`requiredMcpServers`

`autoMemoryEnabled`

`autoDreamEnabled`

`context: fork` et l’impact du choix du modèle sur le cache

Configuration de session combinant surveillance de fichiers et filet de sécurité `asyncRewake`

Revue d’architecture combinant override du modèle, contrôle de `effort` et délégation à un agent