Partager des skills

Objectifs

À l’issue de cette leçon, vous serez capable de :

• Partager des skills avec votre équipe en les commitant dans un dépôt Git
• Distribuer des skills entre projets via les plugins et les marketplaces
• Déployer des skills à l’échelle de l’organisation via les paramètres gérés
• Configurer des sous-agents personnalisés pour utiliser des skills spécifiques

Commiter les skills dans le dépôt

La méthode la plus simple est aussi la plus efficace pour une équipe : placez vos skills dans .claude/skills et commitez-les. Toute personne qui clone le dépôt les reçoit du même geste, sans installation ni documentation à lire. Quand vous poussez une mise à jour de votre checklist de revue, chacun l’obtient à son prochain pull, exactement comme une modification de code.

Cette approche est la bonne pour les standards de code de l’équipe, les workflows propres au projet, et surtout pour les skills qui font référence à la structure de votre codebase — un skill qui explique où se trouvent les migrations et comment on les nomme n’a aucun sens en dehors du dépôt qui les contient. Le répertoire .claude regroupe d’ailleurs vos agents, hooks, skills et paramètres : le tout est versionné et partagé par les workflows Git dont vous avez déjà l’habitude.

Distribuer via les plugins

Certains skills dépassent le cadre d’un projet. Un skill qui applique une convention de documentation ou une méthode de revue d’accessibilité peut servir à des équipes qui ne partagent aucun code avec vous. Les plugins répondent à ce besoin : ils étendent Claude Code avec des fonctionnalités personnalisées conçues dès le départ pour circuler entre équipes et projets. Dans votre projet de plugin, vous créez un répertoire skills dont la structure ressemble à celle du répertoire .claude.

Une fois le plugin distribué sur une marketplace, d’autres utilisateurs peuvent le découvrir et l’installer dans Claude Code. Réservez ce canal aux skills suffisamment généraux pour bénéficier à une communauté plus large : un skill truffé de références à vos noms de services internes ne survivra pas au voyage.

Le déploiement enterprise

Quand un standard n’est pas négociable, il ne peut pas dépendre du bon vouloir de chacun. Les administrateurs déploient alors des skills à l’échelle de l’organisation via les paramètres gérés (managed settings). Ces skills enterprise ont la priorité la plus élevée : ils surchargent les skills personnels, de projet et de plugin qui porteraient le même nom. C’est le mécanisme adapté aux standards obligatoires, aux exigences de sécurité et aux workflows de conformité.

Le fichier de paramètres gérés va plus loin en contrôlant la provenance de ce qui est installé, avec des fonctionnalités comme strictKnownMarketplaces :

"strictKnownMarketplaces": [
  {
    "source": "github",
    "repo": "acme-corp/approved-plugins"
  },
  {
    "source": "npm",
    "package": "@acme-corp/compliance-plugins"
  }
]

Avec cette configuration, les développeurs de l’organisation n’installent que des plugins issus des sources approuvées, ce qui ferme la porte aux skills d’origine inconnue.

Skills et sous-agents : l’héritage n’existe pas

Voici le point sur lequel achoppent la plupart des équipes : les sous-agents n’héritent pas automatiquement de vos skills. Quand vous déléguez une tâche, le sous-agent démarre avec un contexte vierge, et votre skill de revue soigneusement écrit reste à la porte. Trois précisions à garder en tête : les agents intégrés — Explorer, Plan, Verify — ne peuvent pas accéder aux skills ; les sous-agents personnalisés définis dans .claude/agents le peuvent, mais uniquement si vous les listez explicitement ; et ce chargement se fait au démarrage du sous-agent, jamais à la demande.

La configuration passe par un fichier Markdown d’agent déposé dans .claude/agents, dont le frontmatter comporte un champ skills :

---
name: frontend-security-accessibility-reviewer
description: "Use this agent when you need to review frontend code for accessibility..."
tools: Bash, Glob, Grep, Read, WebFetch, WebSearch, Skill...
model: sonnet
color: blue
skills: accessibility-audit, performance-check
---

Les deux skills listés sont chargés au démarrage de ce sous-agent et s’appliquent à chacune de ses revues. Le pattern donne sa pleine mesure lorsque vous voulez une délégation isolée mais experte, lorsque des sous-agents différents ont besoin de skills différents — un relecteur frontend et un relecteur backend ne partagent pas grand-chose — et lorsque vous voulez imposer des standards dans le travail délégué sans dépendre de la qualité du prompt que quelqu’un aura tapé ce jour-là.

Reprenez maintenant les skills que vous envisagez de construire et attribuez à chacun son canal : dépôt, plugin ou paramètres gérés. Puis repérez les workflows délégués où l’ajout explicite d’un skill au sous-agent améliorerait immédiatement la cohérence des résultats.