Aller au contenu
Mastering Claude

Accueil / Une installation structurée

Une installation structurée9 minApplication

Curer ses skills et boucler la mise en place

Une skill s'installe une par une contre un besoin déjà rencontré, jamais en lot, et boucler l'installation consiste à prouver chacun des sept éléments de la carte du module par un geste exécutable plutôt que de les supposer en place.

Installer dix skills d'un coup parce qu'une liste les recommande revient à empiler des réglages sans savoir lesquels servent vraiment. Chaque skill installée entre en concurrence lexicale avec les autres au moment du routage automatique : une skill posée contre un besoin qui ne s'est pas encore présenté ne coûte que du contexte, sans aucune contrepartie. La bonne question avant d'installer n'est jamais combien de skills ce dépôt propose, mais quel geste précis, déjà répété dans votre propre travail, cette skill viendrait remplacer.

Une skill à la fois, deux emplacements possibles

Une skill vit dans un dossier personnel quand elle sert tous les projets, ou dans un dossier de projet quand elle ne sert que celui en cours. Sur un conflit de nom entre les deux emplacements, c'est la skill personnelle qui l'emporte. Les commandes slash personnalisées et les skills ont par ailleurs fusionné : un fichier de commande et un fichier SKILL.md portant le même nom produisent désormais la même commande et se comportent de la même façon, un changement structurel à connaître avant d'aller plus loin dans créer sa propre skill ou sa propre commande.

Deux dépôts distincts existent. Le premier, claude-plugins-official, est un ensemble curaté par Anthropic, pas un dépôt communautaire : il s'enregistre seul au tout premier lancement interactif, et un ajout manuel passe par la sous-commande CLI claude plugin marketplace add anthropics/claude-plugins-official, pas par une commande slash. Le second, claude-community, est bien le dépôt public de la communauté, et s'ajoute avec :

/plugin marketplace add anthropics/claude-plugins-community

Aucun chiffre fixe ne mesure honnêtement la taille de ces bibliothèques, curatée ou communautaire : elles sont versionnées en continu par leurs mainteneurs, un compte relevé un jour donné diverge déjà du même dépôt consulté le lendemain. Le geste correct est de consulter le dépôt au moment de l'installation, jamais de retenir un total appris une fois pour toutes.

Boucler, c'est prouver, pas supposer

La carte d'une installation structurée comptait sept éléments en ouverture de ce module : moteur, constitution CLAUDE.md, mémoire de fichiers, transport git, hooks, skills, battement de coeur. Boucler la mise en place consiste à fermer chacun de ces sept éléments par une preuve exécutée, jamais par un souvenir de configuration qu'on suppose encore vrai. La figure de cette leçon détaille les sept preuves attendues, une par élément de la carte, avant de considérer l'installation comme terminée.

Figure 1

Les sept preuves qui ferment l'installation

Phase 1
Moteur
Une première demande simple obtient une réponse dans le terminal, preuve que la connexion et l'abonnement fonctionnent.
Phase 2
CLAUDE.md global
Une session nouvellement ouverte cite dans sa réponse une règle écrite dans le fichier, preuve qu'il a bien été chargé.
Phase 3
Mémoire de fichiers
Un commit apparaît dans l'historique du coffre mémoire après une session de travail.
Phase 4
Transport git
Le remote privé du coffre mémoire répond à un push sans erreur d'authentification.
Phase 5
Hooks
Un témoin de succès écrit par le hook SessionEnd existe bien après la fermeture de la session.
Phase 6
Skills
Le dossier des skills installées contient exactement les fichiers SKILL.md attendus, ni plus ni moins.
Phase 7
Battement de coeur
La dernière exécution enregistrée de la tâche planifiée correspond à l'heure prévue, pas à une date plus ancienne.
La chronologie reprend les sept éléments de la carte d'ouverture du module et associe à chacun le geste concret qui prouve qu'il est réellement en place, plutôt qu'un souvenir de réglage.
Calibrez vous-même

Un développeur installe une skill de génération de diagrammes dans le dossier personnel de son compte, l'utilise sur trois demandes portant sur des schémas réseau au cours du mois, puis consulte le dossier des skills installées et y retrouve quatorze entrées accumulées depuis six mois.

Écrivez en une phrase ce que cette situation établit, et en une phrase ce qu'elle n'établit pas.

Ce qu’il faut retenir
  • Une skill s'installe contre un besoin déjà rencontré, jamais en lot par anticipation, parce que chaque skill installée entre en concurrence lexicale avec les autres au moment du routage.
  • Sur un conflit de nom entre une skill personnelle et une skill de projet, c'est la skill personnelle qui l'emporte.
  • Les commandes slash personnalisées et les skills produisent désormais le même résultat sous un fichier différent, un changement structurel par rapport aux versions plus anciennes du produit.
  • Aucun chiffre fixe ne décrit honnêtement la taille d'un dépôt communautaire de skills, la seule preuve valable est une consultation du dépôt au moment de l'installation.
  • Boucler une installation structurée consiste à prouver chacun de ses éléments par un geste exécutable, pas à supposer qu'il est en place.
À faire maintenant

Listez vos sept éléments installés depuis le début du module, et pour chacun, exécutez la preuve correspondante de la figure de cette leçon avant de cocher l'installation comme terminée.

Ce qui reste à vérifier

Ces points dépendent d’une interface ou d’une règle qui peut avoir changé depuis la rédaction. Vérifiez-les sur votre propre écran avant de vous y fier.

  • Le nombre exact de skills et d'agents disponibles dans les dépôts communautaires ECC et superpowers n'est pas stabilisé, aucun chiffre n'a été cité dans cette leçon pour cette raison.
Vérifier à la source

Chaque affirmation datable de cette leçon renvoie ici au texte public qui la porte. Une source qui ne s’ouvre pas ne prouve rien.