Se fabriquer ses propres raccourcis

Tu ouvres ta session et tu retapes les trois mêmes choses : dans quel dossier travailler, avec quels réglages, et la consigne de démarrage que tu recolles depuis un fichier de notes gardé ouvert dans un coin. Le soir, tu recommences.

Il y a une version plus coûteuse de la même scène, et c’est celle qui justifie cette leçon. La vérification que tu t’étais promis de lancer à chaque fois te prend six lignes à retaper. C’est celle de la leçon 10, qui demande à Claude de lancer l’application et de montrer le résultat plutôt que de dire que c’est bon. Tu l’as lancée trois jours. Le quatrième, tu as passé ton tour, et personne ne te l’a fait remarquer.

Ce qui se passe vraiment

Ce n’est pas la frappe qui coûte, c’est le frottement. Six lignes à retaper, ce n’est rien une fois ; c’est ce qui décide, au bout de trois semaines, entre une habitude et un souvenir. Un geste pénible ne devient jamais un réflexe — il devient une chose qu’on faisait avant. Et contrairement à une règle mal suivie, dont la leçon 6 donne les symptômes, ici rien ne se dégrade : tu arrêtes, et ton projet ne s’en aperçoit pas.

L’atelier, encore. La leçon 1 a posé l’image : l’atelier fournit l’établi, les outils courants et les règles de sécurité, et toi tu es l’artisan. La leçon 5 y a ajouté les outils spécialisés, qu’on achète quand le geste s’est répété assez souvent pour les payer. Il en manque une troisième sorte, et c’est le sujet ici : l’outil que l’artisan se fabrique lui-même, parce qu’aucun catalogue ne vend le geste exact qu’il refait tous les jours.

À retenir — un raccourci ne sert pas à taper moins. Il décide de ce qui est facile, et ce qui est facile est ce que tu feras encore dans trois semaines. La bonne question n’est donc pas « qu’est-ce que je retape le plus », c’est « qu’est-ce que j’ai arrêté de faire parce que c’était pénible ».

Cette question a un défaut à régler avant de s’en servir : ce qu’on a arrêté de faire ne se rappelle pas. Ne compte donc pas sur ta mémoire, regarde ce qui reste. Un contrôle qu’on lance laisse une trace — un rapport, un commit, une capture, une sortie collée dans un fil. Ouvre la dernière et regarde sa date : trois semaines, tu as ta réponse. Et si le geste ne laissait rien derrière lui, c’est le premier problème à traiter, pas le raccourci : un contrôle sans trace est déjà mort sans que personne le sache. C’est le sujet de la leçon 13.

Ce n’est pas un neuvième déclencheur. Les huit moments de la leçon 5 comptent des répétitions : deuxième fois, troisième fois. Ce que tu as arrêté, tu l’avais forcément fait plusieurs fois avant de l’abandonner — trois jours, dans la scène du début. Le compteur avait bien tourné ; c’est l’abandon qui l’a arrêté. La question de l’encadré ne s’ajoute pas à la liste, elle la relit.

Deux étages, et ils ne répondent pas au même moment

• Avant que la session démarre : le modèle, le niveau d’effort, le mode d’autorisation, les dossiers auxquels il a accès. Ces choix-là se posent au lancement, dans ton terminal — non qu’ils y soient figés : /model, /effort et /add-dir les reprennent en cours de session, et Shift+Tab fait tourner les modes d’autorisation (leçon 8, qui donne aussi les deux modes qui ne s’obtiennent qu’au lancement). Ce qu’on évite en les posant au départ, c’est de les reprendre à chaque fois. Leur raccourci est un alias, un nom court que ton terminal remplace par une commande longue.
• Pendant la session : les consignes, les procédures, les checklists. Leur raccourci est un skill (la fiche réutilisable de la leçon 4, du savoir ou une procédure), qu’on déclenche en tapant / suivi de son nom, comme n’importe quelle commande.

Matériellement, un skill est un dossier. Dedans, un fichier SKILL.md : un en-tête entre deux lignes de tirets, le frontmatter dans la documentation, qui dit quand l’utiliser, puis du markdown avec les instructions. Et ce qui surprend : le nom du dossier devient la commande.

Ce qui le distingue du fichier de règles de la leçon 6, c’est le moment du chargement. Le contenu d’un CLAUDE.md occupe le plan de travail à chaque requête ; le corps d’un skill ne se charge que quand il sert. Un long matériau de référence n’y coûte donc presque rien tant que personne n’en a besoin ; ce qui est chargé à chaque session, c’est sa description.

Une fois chargé, il reste, mais pas indéfiniment. Un skill entre dans la conversation comme un seul message et y demeure ; Claude Code ne relit pas le fichier aux tours suivants. D’où des instructions permanentes plutôt que des étapes ponctuelles, et le plus court possible. La réserve est celle du tableau de la leçon 3 : à la compaction, les skills invoqués sont réinjectés mais plafonnés — 5 000 tokens (un morceau de mot, pas un mot : l’unité qui compte la place occupée) par skill, 25 000 au total, les plus anciens jetés d’abord, la troncature gardant le début. Un skill long, ou invoqué tôt dans une session chargée, perd sa fin. Remède : le réinvoquer après.

Ce qu’on fait

D’abord le déclencheur, ensuite l’inventaire

La leçon 5 donne les deux moments, et ils ne s’anticipent pas : tu retapes le même prompt pour démarrer une tâche, ou tu recolles la même procédure pour la troisième fois. Avant ça, on n’écrit rien. Quand le moment est là, regarde d’abord ce qui est livré. Les bundled skills sont les skills fournis avec Claude Code ; ils s’invoquent comme les autres, / puis le nom : /doctor, /code-review, /batch, /debug, /loop, /claude-api, entre autres. Si l’un d’eux n’apparaît pas chez toi, regarde le réglage disableBundledSkills : il les coupe tous sauf /doctor. Trois d’entre eux lancent ton application et confirment un changement contre l’application qui tourne plutôt que contre les tests — /run, /verify et /run-skill-generator, version 2.1.145 ou plus récente. La leçon 10 les traite en détail, y compris le piège de /verify, qui enregistre sa propre recette dans ton dépôt et finit par remplacer le skill fourni. Le troisième vaut d’être essayé avant d’écrire un skill à la main : il fait tourner ton application depuis un environnement propre, capture ce qui a marché et l’écrit dans .claude/skills/run-<nom>/.

Écrire le sien

Deux emplacements, et le choix se fait sur une question : est-ce que ça ne vaut que pour ce projet ?

~/.claude/skills/<nom>/SKILL.md     # tous tes projets
.claude/skills/<nom>/SKILL.md       # ce projet seulement, et versionnable

Dans l’en-tête, tous les champs sont optionnels. Un seul est recommandé, description, parce que c’est lui qui dit à Claude quand appliquer le skill ; s’il manque, c’est le premier paragraphe du contenu markdown qui en tient lieu. Mets le cas d’usage principal en premier : dans le listing, la description et le champ when_to_use réunis sont coupés à 1 536 caractères — plafond réglable par skillListingMaxDescChars, mais qui s’applique quel que soit le budget.

Le champ name ne fait pas ce qu’on croit. Dans un skill personnel ou de projet, il ne fixe que le libellé affiché dans les listes ; la commande vient du nom du dossier. Le renommer sans renommer le dossier ne change pas ce que tu tapes.

Deux champs décident qui a le droit de déclencher, et c’est le vrai sujet de l’en-tête :

L’en-tête	Qui peut l’invoquer	La description est-elle en contexte
par défaut	toi et Claude	oui, à chaque session ; le contenu complet arrive à l’invocation
disable-model-invocation: true	toi seul	non
user-invocable: false	Claude seul — le skill disparaît du menu /	oui

La leçon 5 a donné le motif documenté du premier, et ce n’est pas l’économie de place : c’est le contrôle des effets de bord, pour ne pas laisser Claude décider tout seul de déployer parce que le code a l’air prêt. Deux contreparties : il empêche aussi le préchargement du skill dans un subagent (l’ouvrier isolé de la leçon 4) et, depuis la version 2.1.196, son exécution quand une tâche planifiée le prend pour prompt. Le second champ sert au savoir de fond.

Garde le SKILL.md sous 500 lignes. Le matériau détaillé part dans des fichiers séparés du même dossier : modèles, exemples, scripts. Tu les références depuis le SKILL.md, sans quoi Claude ne sait ni ce qu’ils contiennent ni quand les ouvrir. Deux substitutions les désignent où que la session soit lancée : ${CLAUDE_SKILL_DIR} pointe le dossier du skill, ${CLAUDE_PROJECT_DIR} la racine du projet — cette seconde-là, et elle seule, demande une version 2.1.196 ou plus récente. Ça donne : Avant de répondre, lis ${CLAUDE_SKILL_DIR}/grille.md.

Et si tu as déjà des fichiers dans .claude/commands/, rien à migrer en urgence : commands/deploy.md et skills/deploy/SKILL.md produisent tous les deux /deploy ; si les deux existent, c’est le skill qui l’emporte, et c’est lui le successeur recommandé.

Ce que tu tapes derrière le nom

Ce qui suit le nom du skill lui arrive par substitution : un morceau de texte du fichier, appelé placeholder, est remplacé avant que le contenu parte à Claude. Un SKILL.md rangé dans fix-issue/ et contenant la ligne Corrige l'issue GitHub $ARGUMENTS en suivant nos conventions. fait arriver à Claude, quand tu tapes /fix-issue 123 : « Corrige l’issue GitHub 123 en suivant nos conventions. » Rien ne devine GitHub — c’est toi qui l’as écrit. Trois choses à savoir :

• $ARGUMENTS prend tout ce que tu as tapé derrière ; $ARGUMENTS[N], ou le raccourci $N indexé à partir de zéro, prend un argument précis. /migrate SearchBar React Vue remplace $0 par SearchBar, $1 par React, $2 par Vue ;
• si ton skill ne contient nulle part $ARGUMENTS, Claude Code ajoute ARGUMENTS: <ce que tu as tapé> à la fin du contenu : rien de ce que tu tapes n’est perdu ;
• un placeholder resté sans argument reste tel quel. $2 sans deuxième argument n’est pas remplacé : Claude lit littéralement $2 dans tes instructions. Pas d’erreur affichée, juste une consigne devenue absurde.

Tu peux aussi empiler plusieurs skills en tête de message : /write-tests /fix-issue 123 charge les deux et passe 123 à chacun, à partir de la version 2.1.199. Deux limites : six au maximum ; et l’empilement s’arrête au premier morceau qui n’est pas un skill inline invocable par toi. /code-review, qui tourne dans un subagent dérivé depuis la version 2.1.218, arrête la chaîne — lui et la suite deviennent le texte d’argument des skills déjà dépliés.

Faire entrer ce qu’il ne peut pas savoir d’avance

Une commande shell écrite entre accents graves et précédée d’un point d’exclamation s’exécute avant que le contenu parte à Claude, et sa sortie prend sa place — c’est ce qui permet à une fiche figée de commencer par l’état réel de ton dépôt. Dans un SKILL.md :

---
description: prépare une relecture avant de committer
allowed-tools: Bash(git *)
---

## L'état du dépôt
- Fichiers modifiés : !`git status --short`
- Sortie du contrôle : !`./scripts/verifier.sh || true`

Claude ne voit jamais les deux lignes de commande : il reçoit la liste des fichiers et la sortie du script. Trois façons de se faire avoir, dont une seule est vraiment silencieuse :

• une commande qui échoue avorte l’invocation entière, pas seulement sa propre ligne : Claude ne voit rien du skill. « Échouer » veut dire renvoyer un code de sortie non nul — le nombre qu’une commande renvoie en terminant, zéro quand tout s’est bien passé. Une exception, le code 1 des commandes de recherche et de comparaison (grep, rg, egrep, fgrep, find, diff, test, [, plus git diff et git grep), qui veut dire « rien trouvé » ou « ça diffère ». Pour tout le reste, c’est le || true de l’exemple. Ce cas-là n’est pas muet : l’avortement affiche Shell command failed for pattern "...", sortie sous [stderr] ;
• ces commandes ne demandent jamais de permission. Si la vérification de permission ne renvoie pas « allow », y compris pour une règle qui te poserait normalement la question, l’invocation avorte, avec cette fois Shell command permission check failed for pattern "...". Le remède est le allowed-tools de l’en-tête, le Bash(git *) de l’exemple. Une règle qui demande ou qui refuse, elle, avorte quand même ;
• le point d’exclamation n’est reconnu qu’en début de ligne ou juste après une espace. Écrit après un autre caractère, comme dans VERSION=!`git describe` , il reste du texte littéral. Rien ne tourne, rien ne le signale. C’est le seul des trois qui ne dit rien.

Et cette barrière est écrite pour un seul outil. Ces commandes passent par l’outil Bash quand bash est disponible, et par l’outil PowerShell quand il ne l’est pas — Windows sans Git Bash. Un skill qui déclare shell: powershell dans son en-tête y passe lui aussi dès que l’outil PowerShell est actif, ce qui, sur Windows, peut arriver même avec Git Bash installé : son déploiement est progressif, la leçon 8 en tire les conséquences. Dans ces cas-là, la liste d’exception au code 1 n’est pas la même : elle contient grep et git diff, mais ni find ni diff. Et un allowed-tools: Bash(git *) n’y regarde rien, puisque les règles PowerShell sont une famille à part. Le contrôle de permission ne renvoie donc pas « allow », et l’invocation avorte. Le cas inverse est plus net : un skill qui déclare shell: bash sur une machine où bash est absent échoue avant qu’aucune commande ne tourne, avec un message qui nomme Git Bash.

L’étage d’avant : l’alias de terminal

Deux avertissements. Le premier fait perdre du temps : claude --help ne liste pas tous les drapeaux, donc l’absence d’un drapeau dans l’aide ne prouve pas qu’il n’existe pas. Le second porte sur le mot « alias », qui change de sens dans la colonne de droite : c’est un nom court de modèle, pas de commande. Il en aura un troisième plus bas.

Drapeau	Ce qu’il pose	Ce qu’il faut savoir
--model	le modèle de la session	un alias de modèle (sonnet, opus, haiku, fable) ou un nom complet ; écrase le réglage model et ANTHROPIC_MODEL
--effort	le niveau d’effort	low, medium, high, xhigh, max, ou ultracode (2.1.203 ou plus récent) ; les niveaux disponibles dépendent du modèle, et le drapeau ne persiste pas
--permission-mode	le mode de départ	default (aussi appelé manual), acceptEdits, plan, auto, dontAsk, bypassPermissions — leçon 8
--add-dir	des dossiers de travail en plus	charge aussi les .claude/skills/ et .claude/commands/ qui s’y trouvent — ce que le réglage permissions.additionalDirectories, souvent donné comme son équivalent persistant, ne fait pas : lui n’accorde que l’accès aux fichiers

Poser un alias, concrètement. C’est une ligne dans le fichier de démarrage de ton terminal — ~/.zshrc avec zsh, le défaut sur macOS, ~/.bashrc ou ~/.bash_profile avec bash. Tu ajoutes la ligne, tu ouvres un nouveau terminal (ou tu recharges : source ~/.zshrc), puis tu vérifies en tapant alias mon-raccourci : le terminal te répond par la commande qu’il mettra à la place. Tant que tu n’as pas vu cette réponse, tu ne sais pas ce que tu lances. Dedans, ta combinaison à toi. alias cc-revue='claude --model opus --permission-mode plan' remplace deux décisions par un mot et les rend relisibles. L’exemple de la documentation, lui, fait tourner deux comptes côte à côte.

alias claude-work='CLAUDE_CONFIG_DIR=~/.claude-work claude'

CLAUDE_CONFIG_DIR écrase le dossier de configuration, ~/.claude par défaut. Tous les réglages, l’historique des sessions et les plugins vivent sous ce chemin — deux comptes, ce sont donc deux jeux de réglages et deux historiques. À savoir avant de chercher vingt minutes la session d’hier.

Vérifier qu’il existe, puis qu’il sert

/skills liste ce qui est disponible et se filtre en tapant. Sur un skill en surbrillance, Espace fait défiler quatre états de visibilité et Entrée enregistre le choix dans .claude/settings.local.json, sous la clé skillOverrides : on (nom et description annoncés à Claude), name-only (le nom seul), user-invocable-only, affiché user-only (invisible pour Claude, encore tapable par toi) et off (invisible partout). C’est le moyen de couper un skill versionné sans toucher à son en-tête — et de faire tourner une session sans lui.

La leçon 5 a donné les pannes d’installation ; ce qui les complète ici : un skill ajouté ou modifié dans un dossier déjà surveillé est pris en compte dans la session en cours, sans redémarrage. L’exception est justement le cas de ton premier skill : si tu viens de créer le dossier de skills lui-même, qui n’existait pas au démarrage de la session, il faut redémarrer Claude Code pour qu’il le surveille. /reload-skills (version 2.1.152 ou plus récente) rebalaie les dossiers de skills et de commandes et te dit combien sont disponibles, ajoutés ou retirés. Et surtout, un en-tête mal formé échoue sans bruit : si le YAML du frontmatter, l’en-tête entre les deux lignes de tirets, est cassé, Claude Code charge quand même le corps du skill, avec des métadonnées vides. /nom marche toujours, donc rien n’a l’air cassé, mais Claude n’a plus de description sur laquelle s’appuyer pour le déclencher seul. claude --debug montre l’erreur d’analyse.

Et là commence la partie que personne ne fait. Voir un skill se déclencher prouve que Claude l’a trouvé, pas qu’il a fait ce que tu voulais. Ce sont deux mesures distinctes :

1. est-ce qu’il est invoqué sur les prompts qu’il faut ;
2. est-ce que la sortie correspond quand il l’est.

Pour les deux, la vérification documentée est une comparaison à une base : quelques prompts réalistes, passés chacun dans une session neuve, une fois avec le skill et une fois sans. « Sans », c’est skillOverrides : /skills, Espace jusqu’à off, Entrée — et tu remets à on après. La session neuve n’est pas un détail : dans celle où tu viens d’écrire le skill, Claude sait déjà ce que tu voulais dire, ce qui masque les trous de ce que tu as écrit.

Et ce que tu regardes dans les deux sorties se décide avant de lancer, sinon tu jugeras au ressenti. Écris d’abord, en une phrase par prompt, ce que la bonne réponse doit contenir : le fichier qu’elle doit toucher, la commande qu’elle doit lancer, la question qu’elle doit poser avant d’agir. Ensuite tu coches, sans relire le reste. Si la version sans skill coche autant de cases, ton skill ne sert à rien ; si celle avec en coche moins, reprends description et instructions.

Et ce travail-là s’outille. Le plugin officiel skill-creator (/plugin install skill-creator@claude-plugins-official) fait la boucle à ta place : cas de test rangés dans un evals/evals.json à côté du skill, chacun lancé dans un subagent pour garantir un contexte propre, notation assertion par assertion, comparatif agrégé avec et sans skill, A/B aveugle entre deux versions, et mesure du taux de déclenchement pour proposer une meilleure description. C’est un plugin de plus à entretenir, et la leçon 5 dit ce que ça coûte — mais entre un rituel manuel qu’on abandonnera et un dispositif qui mesure, cette leçon a déjà tranché.

Ce que ça ne fait pas

Ça ne garantit aucun comportement. Un skill est du contexte, comme le fichier de règles : la formule officielle vise nommément les deux. « Ne touche jamais à .env » écrit dans un CLAUDE.md ou dans un skill est une demande, pas une garantie. Un hook, le déclenchement automatique attaché à un événement de la leçon 5, se déclenche toujours ; un skill est interprété. Et pour ce cas précis, le refus de lecture de la leçon 8 fait le travail en une ligne. Si ce que tu as écrit semble cesser d’agir après la première réponse, le contenu est en général là — c’est le modèle qui choisit d’autres outils. Trois remèdes : renforcer description et instructions, réinvoquer le skill après une compaction, ou passer par un hook.

Piège — deux installations du même skill, et c’est le personnel qui gagne. Avec un deploy à la fois dans ~/.claude/skills/ et dans le .claude/skills/ du projet, /deploy exécute celui du personnel : l’inverse de l’intuition « le plus proche l’emporte », et l’inverse des fichiers de règles de la leçon 6, qui s’additionnent. Un skill de projet corrigé ne prend jamais la main tant qu’une vieille version traîne chez toi. L’ordre complet : entreprise, personnel, projet.

Et ça change ce que « versionner » veut dire. Puisque le personnel écrase le projet et que skillOverrides s’écrit dans le settings.local.json de la leçon 8, qui reste chez toi, commiter un skill distribue une intention, pas une exécution : le collègue qui a un homonyme personnel lance le sien, celui qui l’a passé à off ne lance rien, et rien de tout ça ne se voit en pull request. Ce qui s’applique vraiment, ce sont les hooks et les réglages gérés par l’organisation.

Remplacer un skill livré ne remplace pas ses alias — troisième et dernier sens du mot : ici, un deuxième nom qui ouvre la même porte. Un code-review maison dans ton projet remplace bien /code-review ; /review, alias du skill fourni, continue de lancer celui d’Anthropic. Tu n’as remplacé qu’une entrée, exactement la forme d’échec silencieux que traite la leçon 13.

allowed-tools n’est pas un garde-fou, malgré son nom. Ce champ pré-autorise des outils pendant le tour qui invoque le skill ; il ne restreint rien, et tes réglages de permission gouvernent toujours ceux qui n’y figurent pas. L’asymétrie compte : l’autorisation tombe dès le message suivant, alors que le contenu du skill, lui, reste — pour pré-autoriser sur toute une session, ce sont des règles allow, leçon 8. Et le champ ne passe pas par la confiance de l’espace de travail : Claude Code l’applique dès qu’un skill de projet est invoqué, y compris dans un run -p (le mode non interactif, une question, une réponse, sans session ouverte) sur un dossier jamais approuvé. D’où la consigne, valable pour tout dépôt que tu clones : relis les allowed-tools des skills versionnés avant d’y lancer Claude Code.

Et deux pièges qui ne viennent pas du skill

Le listing se fait rogner sans prévenir. Claude Code charge les noms et les descriptions en contexte, dans un budget qui vaut par défaut 1 % de la fenêtre du modèle. La liste garde tous les noms ; en revanche, si tu as beaucoup de skills, les descriptions sont raccourcies pour tenir, en commençant par ceux que tu invoques le moins. Un skill peut donc exister, apparaître par son nom, et ne plus jamais se déclencher seul faute des mots-clés qui le désignaient. Trois leviers : passer les entrées secondaires à name-only, raccourcir les descriptions, ou relever le budget avec skillListingBudgetFraction. /doctor estime ce coût.

Tes raccourcis ne sont pas toujours là où tu crois. Les sessions du nuage (y compris les routines planifiées) et celles de Cowork, l’un des trois onglets de l’application de bureau, ne lisent pas le ~/.claude/skills/ de ta machine : elles chargent les skills activés sur ton compte claude.ai, et une routine, dont chaque exécution démarre à neuf comme session distante, dira le skill introuvable. L’onglet consacré au développement, lui, lit bien tes skills personnels. Deux remèdes non interchangeables : commiter dans le .claude/skills/ du dépôt ne sert qu’aux sessions cloud ; pour Cowork, active le skill sur ton compte claude.ai. Sur ta propre machine, c’est un alias qui peut les éteindre : le drapeau --bare saute la découverte automatique des hooks, des skills, des plugins, des serveurs MCP, de la mémoire automatique et du CLAUDE.md. Mis dans un alias « pour aller plus vite », il éteint tout ce que cette leçon vient de te faire construire — et il coupe ton authentification par abonnement, puisqu’il ne lit ni les identifiants ni le trousseau du système et attend une clé d’API dans l’environnement.

Et ce n’est pas un gain de temps. Écrire un skill, le corriger, vérifier qu’il se déclenche et le comparer à une base coûte plus cher que de retaper la consigne une fois de plus. Ce que tu achètes est ailleurs : un objet qui se relit, se versionne et se corrige, et surtout un contrôle que tu ne sautes plus, parce qu’il est devenu moins cher à lancer qu’à éviter. Une contrepartie le jour où tu l’écris : le raccourci supprime le geste manuel qui te signalait qu’il avait besoin d’une révision. Nomme donc sa condition de re-lancement au moment même — le jour où le build change, où le déploiement change de cible, où la checklist gagne une ligne.

Et les versions bougent sous tes pieds. Chaque comportement daté ci-dessus porte son numéro de version à l’endroit où il est décrit. L’ensemble a été contrôlé le 20 août 2026 contre l’instantané de la documentation officielle du même jour. C’est la date du dernier contrôle, pas une promesse de fraîcheur : claude --version et /help répondent pour ta machine, aujourd’hui.

Où c’est écrit

• Les skills — l’en-tête champ par champ, les arguments, l’injection de commandes, les conflits de nom, skillOverrides, le budget du listing, la comparaison à une base, skill-creator ;
• Les commandes — /skills, /reload-skills, et ce qui distingue une commande intégrée d’un skill livré ;
• Référence de la ligne de commande — les drapeaux de lancement ; mode sans interface — --bare ;
• Vue d’ensemble des fonctionnalités — la table de décision skill / hook / plugin, et l’opposition entre demande et application ;
• Variables d’environnement — CLAUDE_CONFIG_DIR.

Comme aux leçons précédentes, ces liens pointent vers les pages anglaises : la version française existe, /fr/ à la place de /en/. Mais elle traduit une partie des mots que tu verras sur ton écran, et elle peut être en retard sur le fond. Un lien qui vise une section précise peut d’ailleurs ne mener nulle part côté français : la section n’y est parfois pas encore traduite, et tu atterris en haut de la page sans que rien te le dise.

Ce que cette leçon ajoute à ces pages. Les deux étages, avant et pendant, qu’aucune page ne met côte à côte parce qu’elles sont rangées par mécanisme. Le critère d’écriture : non pas ce que tu retapes le plus, mais ce que tu as arrêté de faire — et le moyen de le retrouver, puisqu’un abandon ne se rappelle pas. Et la vérification d’un raccourci, qui se mesure en deux fois.

Le point de bascule

Ce n’est pas le nombre de raccourcis que tu as écrits qui le dit, c’est ce qu’ils visent : non plus ce que tu tapes le plus souvent, mais ce que tu avais arrêté de faire parce que c’était pénible. Et le fait que tu ailles chercher la réponse dans la date du dernier rapport, pas dans ta mémoire.

Vérifier que c’est passé

Ton skill `relire` commence par une ligne qui injecte la sortie de ton script de contrôle. Ce matin, `/relire` ne fait plus rien de ce qu'il devrait, et tu vois passer `Shell command failed for pattern "..."`. Qu'est-ce que Claude a reçu ?

Rien du skill. Une commande injectée qui échoue avorte l’invocation entière, pas seulement sa propre ligne. « Échouer » veut dire renvoyer un code de sortie non nul — le cas typique étant un script de contrôle qui sort en 1 précisément parce qu’il a trouvé des problèmes. L’exception du code 1 ne couvre que les commandes de recherche et de comparaison (grep, find, diff, git diff…), pas ton script : le remède est d’ajouter || true. À noter, ce cas-là s’affiche, sortie sous [stderr] ; le seul vraiment muet est le point d’exclamation écrit après un autre caractère.

Ton skill déclare `allowed-tools` et il a tourné sans rien te demander. Tu enchaînes avec un deuxième message pour lui faire finir le travail — et là, il redemande l'autorisation. Régression ?

Non, comportement documenté, et il faut le lire dans les deux sens. allowed-tools ne vaut que pour le tour qui invoque le skill : l’autorisation tombe dès le message suivant. Le contenu du skill, lui, reste en contexte, sous la réserve du plafond de compaction vu plus haut. Donc l’inverse est vrai aussi, et c’est le piège : tu peux croire que le skill n’est « plus en vigueur » alors que ses instructions y sont encore, tandis que ses permissions ont disparu. Pour pré-autoriser sur toute la session, ce sont des règles allow, pas ce champ — qui, au passage, ne restreint rien.

Tu viens d'écrire ton premier skill. Dans la foulée, tu lui donnes une tâche, il le charge tout seul, la sortie est bonne. Tu considères que c'est validé ?

Non. Le voir se déclencher prouve que Claude l’a trouvé, pas qu’il a fait ce que tu voulais : ce sont deux mesures séparées. Et la validation dans la foulée est la moins fiable de toutes — la session où tu viens d’écrire le skill contient déjà tout ce que tu voulais dire, ce qui masque les trous de tes instructions. La vérification documentée est une comparaison à une base : quelques prompts réalistes, chacun dans une session neuve, avec puis sans le skill, le « sans » s’obtenant en le passant à off dans /skills. Et on écrit avant de lancer ce que la bonne réponse doit contenir, sinon on juge au ressenti. Le plugin skill-creator automatise toute cette boucle.