Construire sa bibliothèque de Skills

Phase 2 · Personnaliser · Article 3 sur 3

Le moment où ça déborde

Tu as créé tes premiers Skills. Un pour rédiger des posts X. Un pour auditer une landing page. Un pour faire ta veille. Ils marchent. Tu les utilises chaque semaine.

Puis tu en crées un quatrième, un cinquième, un dixième. Les noms deviennent incohérents. audit-site, mon-audit, landing-review, trois noms pour la même chose. Tu ne sais plus lequel est le bon. Tu ouvres le mauvais, le résultat n'est pas celui que tu attendais, tu perds 5 minutes à retrouver le bon.

C'est le moment de structurer. Pas avant (inutile avec 2 Skills), pas après (le chaos est installé).

Cet article fait suite à Comprendre les Skills et CLAUDE.md. Tu sais créer un Skill et tu as ton cadre projet en place. Ici, on organise l'ensemble.

La convention catégorie:nom

Le premier levier, c'est le nommage. Pas un fichier en vrac, mais une convention systématique : catégorie:nom.

La catégorie, c'est le domaine. Le nom, c'est l'action. writing:coach, veille:digest, mktg:cro-audit. En lisant le nom, tu sais ce que fait le Skill sans l'ouvrir.

Les catégories émergent de ton métier. Un CPO aura product:, mktg:, coach:. Un responsable contenu aura writing:, social:, seo:. Un fondateur de startup aura product:, ops:, pitch:.

Pas besoin de planifier les catégories à l'avance. Elles apparaissent naturellement. Tu crées ton premier Skill de veille, tu l'appelles veille:digest. Tu en crées un deuxième, veille:events. La catégorie veille: existe maintenant.

Les conventions qui comptent :

Règle	Pourquoi
Toujours en minuscules	Pas d'ambiguïté entre Audit et audit
Catégorie au singulier	writing: pas writings:
Nom = verbe ou action	:digest, :audit, :draft, pas :mon-truc
Un Skill = une tâche	Si le Skill fait 3 choses différentes, c'est 3 Skills

Le méta-Skill : un Skill qui crée des Skills

Le Skill le plus utile de ta bibliothèque n'est pas un Skill métier. C'est /skill:create.

Tu lui dis ce que tu veux automatiser, il crée le dossier, le fichier SKILL.md, le frontmatter, et la structure. Il applique tes conventions de nommage. Il te demande les permissions nécessaires. En 30 secondes, le Skill est prêt.

Le méta-Skill connaît tes conventions parce qu'elles sont écrites dans son propre fichier SKILL.md. Le format catégorie:nom, les dossiers dans le bon répertoire, le template du frontmatter. Tu ne réinventes pas la roue à chaque nouveau Skill.

C'est exactement le même principe qu'un template de document dans Google Docs ou Obsidian. Sauf que le template est actif : il ne t'attend pas, il te guide.

Skills imbriqués : quand un Skill en appelle d'autres

Un Skill n'a pas besoin de tout faire lui-même. Il peut orchestrer d'autres Skills.

/newsletter:draft ne sait pas faire de veille. Il ne sait pas rédiger dans ton ton. Il ne sait pas nettoyer le texte des patterns IA. Mais il sait dans quel ordre appeler les Skills qui savent faire tout ça.

Le principe : chaque Skill fait une chose bien. L'imbrication crée la complexité sans que chaque Skill devienne un monstre de 200 lignes.

Obsidian comme cockpit

Les Skills sont des fichiers markdown. Obsidian est un éditeur de fichiers markdown. La connexion est naturelle.

L'astuce : stocker les Skills dans ton vault Obsidian et créer un lien symbolique vers ~/.claude/skills/. Tu édites dans Obsidian, Claude lit le même fichier.

~/Documents/Vault/Skills/
  writing:coach/SKILL.md
  writing:unslop/SKILL.md
  veille:digest/SKILL.md
  ...

~/.claude/skills/ → lien vers ~/Documents/Vault/Skills/

Voilà à quoi ça ressemble en pratique :

Ce que ça change :

• Recherche : tu cherches "audit" dans Obsidian, tu trouves tous tes Skills d'audit en une seconde
• Édition visuelle : tu modifies un Skill avec le preview markdown, pas dans un éditeur de code
• Liens : tu peux lier un Skill à une note de projet, un compte-rendu, un brief
• Historique : Obsidian Sync ou Git te donne le versioning gratuitement

Tu ne vois plus les Skills comme des fichiers de config cachés dans un dossier système. Tu les vois comme des documents de travail, à côté de tes notes, tes briefs, tes projets.

Maintenir ses Skills

Un Skill n'est jamais terminé. Il évolue avec ton usage.

La première version fait 80% du travail. Tu l'utilises une semaine, tu remarques qu'il oublie de vérifier un critère. Tu ajoutes une ligne. Il génère un format de sortie trop long. Tu ajustes. Il utilise un ton trop formel pour un client spécifique. Tu ajoutes une exception.

Le cycle de maintenance :

Le système complet

Tu as maintenant les trois couches qui forment un système de productivité complet.

CLAUDE.md pose le cadre. Il est toujours actif, chargé à chaque session. Ton, audience, conventions, interdits. Claude sait qui il est et pour qui il travaille.

Les Skills définissent les méthodes. Ils sont activés à la demande, quand tu tapes /nom-du-skill. Chaque Skill encapsule un workflow complet : étapes, critères, format de sortie.

Les serveurs MCP fournissent l'accès. Ils connectent Claude à tes outils externes. PostHog pour les analytics, Slack pour la communication, Gmail pour les emails, Jira pour le backlog.

Les trois couches se cumulent. Quand tu tapes /newsletter:draft, Claude applique les conventions du CLAUDE.md (ton, interdits), exécute la méthode du Skill (scanner, rédiger, nettoyer), et accède aux données via les serveurs MCP (Web Search, Gmail, Slack).

Une seule commande. Trois couches. Un résultat complet.

Par où commencer

Ne planifie pas 20 Skills d'un coup. Commence par un. Utilise-le. Corrige-le. Ajoute le suivant quand un besoin concret se présente. Au bout d'un mois, tu auras une bibliothèque qui reflète exactement ta façon de travailler.