Claude Skills 2026 : packager ton workflow IA

Lundi matin. Tu retapes le même prompt à Claude pour la 4ᵉ fois cette semaine. Tu te dis qu'il doit y avoir un moyen plus malin. Il y en a un. Ça s'appelle une Claude Skill. Sortie en octobre 2025, formalisée par Anthropic dans un guide officiel de 32 pages le 29 janvier 2026. C'est la couche d'abstraction qui transforme un prompt répété en automation déclenchée. J'en ai packagé 4 en 6 semaines sur le blog VibesMoney, sans coder une ligne. Voici exactement comment.

Avant de packager, il faut savoir prompter. Si Claude Code part dans tous les sens chez toi, commence par écrire une spec qui décuple Claude Code. Une skill sur un prompt mou, c'est juste un mauvais prompt qu'on déclenche plus vite.

C'est quoi une Skill Claude, expliqué simple ?

Une Claude Skill, c'est un dossier avec un fichier SKILL.md qui dit à Claude quand intervenir et comment. Sortie officielle Anthropic en octobre 2025. Guide de 32 pages publié le 29 janvier 2026. C'est la couche qui transforme un prompt répété en automation déclenchée. Avantage clé : Claude la lance tout seul, sans que tu tapes une commande.

Le mot-clé, c'est automatique. Tu dis à Claude "illustre l'article pricing", il reconnaît la demande, il déclenche la skill. Tu n'as pas besoin de te souvenir du nom de la skill, ni de taper la moindre commande. Claude scanne les descriptions de toutes les skills installées et choisit celle qui matche.

Concrètement, une skill tient en 2 ou 3 fichiers :

• SKILL.md — le fichier principal. Il commence par un frontmatter (un bloc de métadonnées encadré par ---, en format YAML, c'est-à-dire en mode clé : valeur). Suivi de la procédure en markdown.
• scripts/ — un dossier optionnel pour les helpers en bash (le langage du terminal). À utiliser quand la skill doit exécuter une action répétitive.
• references/ — un dossier optionnel pour des templates ou des fichiers de référence.

Le frontmatter contient deux champs obligatoires : name (le nom de la skill) et description (ce qui dit à Claude quand l'invoquer). C'est cette description qui fait toute la différence. Trop vague, la skill ne se déclenche jamais. Trop technique, Claude ne comprend pas le contexte d'usage.

Anecdote concrète. J'ai packagé ma première skill VibesMoney (illustrate-article) un samedi soir. 30 minutes chrono. Sans écrire une ligne de TypeScript ni de Python. Juste un SKILL.md de 145 lignes et un helper bash de 24 lignes. Le lundi matin, je tapais "illustre l'article spec", Claude déclenchait la skill, et 12 minutes plus tard j'avais 4 visuels prêts à intégrer. Le ratio temps économisé : ~80% par rapport à la même tâche faite à la main.

Skill, slash command, subagent, hook : la matrice qui clarifie

Skill, slash command, subagent, hook, MCP : 5 concepts proches mais radicalement différents en 2026. La skill se déclenche AUTOMATIQUEMENT quand ta demande matche sa description. La slash command, c'est toi qui la lances avec un /. Le subagent, c'est une mission isolée. Le hook, c'est un événement. Confondre les 4, c'est créer un subagent là où une skill suffit.

Le piège classique pour un solopreneur qui démarre : confondre skill et subagent. Tu vois quelqu'un sur Twitter qui dit "j'ai créé un subagent qui review mes specs", tu te dis "je vais faire pareil pour mes briefs blog". Sauf que tu fais ça 3 fois par semaine. Une skill aurait suffi. Le subagent ajoute de la complexité (contexte isolé, gestion de session) qui ne sert que si la tâche est multi-étapes complexe.

Voici la matrice de décision qu'on enseigne dans le programme VibesMoney. Cinq lignes, cinq déclencheurs, cinq usages distincts :

Définitions rapides au cas où. Une slash command, c'est une commande qui commence par / que tu tapes toi-même. Un subagent, c'est un mini-Claude isolé dans son propre contexte à qui tu délègues une mission. Un hook, c'est un script qui se déclenche tout seul à un événement (sauvegarde de fichier par exemple). Un MCP server, c'est un protocole pour brancher Claude à un service externe.

Anecdote du programme VibesMoney. On voit régulièrement des founders confondre subagent et skill. Cas typique : un founder qui crée un subagent "génère mon brief produit" et l'invoque manuellement à chaque session. La même tâche en skill aurait été déclenchée par Claude tout seul, et lui aurait économisé l'étape de "se souvenir d'invoquer le subagent". Le passage skill lui a fait gagner 15 minutes par jour.

Pourquoi un solopreneur en a 2× plus besoin qu'un dev d'équipe

Un dev en équipe répète peu de tâches : les autres prennent le relais sur ce qui est répétitif. Un solopreneur, lui, répète TOUT, tout le temps. Les skills sont le levier brutal qui transforme 30 minutes de prompt manuel en 30 secondes de skill auto-déclenchée. Heuristique reine de la communauté Claude en 2026 : si tu tapes les mêmes instructions 3 fois dans 3 conversations différentes, c'est une skill.

Avant les skills, mon workflow blog ressemblait à ça. Lundi : j'ouvre Claude. Je tape "génère-moi un brief produit en suivant la voix VibesMoney, tutoiement, phrases courtes, anecdote par H2, cluster SEO 2026...". Mardi, mercredi, vendredi : pareil. Avec à chaque fois une variation infime parce que je tapais de mémoire. Résultat : 3 briefs par semaine, ton incohérent, 20 minutes par invocation pour rappeler le contexte à Claude.

Aujourd'hui : je tape "drafte l'article claude-skills". La skill draft-article se déclenche, lit elle-même le brief éditorial, applique la voix VibesMoney, génère le HTML structuré. 30 secondes. Pas une ligne de contexte à retaper. C'est ce que CONTENT_BRIEF appelle orchestrer plutôt que coder : tu valides, Claude exécute.

Le ratio est brutal pour un solo. Sur 5 workflows répétés par semaine (brief, illustration, relance lead, pricing review, post-mortem), la version "prompt à la main" coûte 2 à 3 heures cumulées. La version "skills" coûte 5 à 10 minutes. Tu récupères 2 heures par semaine, soit 100 heures par an. Le break-even d'une skill packagée en 30 minutes : elle se rentabilise en 2 utilisations.

L'autre raison qui rend les skills indispensables pour un solopreneur : la cohérence. Quand tu retapes un prompt à la main, tu oublies des contraintes. La skill, elle, lit toujours les mêmes documents source de vérité, applique toujours les mêmes règles. Tu signes ton ton éditorial une fois, il devient permanent. Pour un blog SEO, c'est la différence entre 8 articles cohérents et 8 articles qui sonnent comme 8 personnes différentes.

L'anatomie d'une skill : SKILL.md + scripts

Une skill bien packagée tient en 3 fichiers et zéro dépendance externe. SKILL.md (la procédure, max 500 lignes selon Anthropic). Un ou deux scripts bash optionnels (pour les actions répétitives). Et c'est tout. Mon SKILL.md de illustrate-article fait 145 lignes, le helper bash 24 lignes : 169 lignes pour automatiser un workflow de 4 actions.

Décortiquons illustrate-article, ma première skill packagée. Elle vit dans .claude/skills/illustrate-article/ à la racine du repo VibesMoney. Trois fichiers :

1. SKILL.md — 145 lignes. La procédure complète : pre-flight checks, lire les docs source, spawn Codex CLI, convertir les images, patcher le HTML.
2. scripts/convert-image.sh — 24 lignes. Le helper bash qui convertit un PNG en AVIF + WebP via sips et cwebp.
3. Aucun autre fichier. Pas de package.json, pas de node_modules, pas de venv Python.

Le SKILL.md commence par un frontmatter qui ressemble à ça :

---
name: illustrate-article
description: Génère 3 à 5 illustrations in-article statiques pour un
  article du blog VibesMoney en utilisant la skill imagegen de Codex CLI
  (gpt-image-2). Use when the user asks to illustrate a blog article,
  add visuals to an article, or invokes /illustrate-article <slug>.
---

# Illustrate Article

Génère 3 à 5 illustrations in-article statiques pour `blog/<slug>.html`,
en orchestrant Codex CLI (skill `imagegen`).

## Inputs
- `<slug>` (required) : nom de fichier article sans `.html`...

## Pre-flight (vérifs avant d'invoquer Codex)
...

Deux trucs à noter sur ce frontmatter. Premièrement, la description est longue et précise. Elle explique : ce que la skill fait, dans quel contexte l'utiliser, quelles phrases-trigger reconnaître. C'est ce qui permet à Claude de la déclencher correctement. Deuxièmement, le mélange français + anglais ("Use when...") est volontaire : Claude raisonne aussi bien dans les deux, et certaines formulations anglaises ("when the user asks to X") matchent plus précisément les patterns d'invocation.

Anecdote sur l'évolution. Mon premier draft de SKILL.md faisait 380 lignes. Claude le lisait à moitié et sautait des étapes. J'ai compressé à 145 lignes en virant tout ce qui n'était pas essentiel : doublons, exemples redondants, longs paragraphes d'explication remplacés par des listes. Performance ×2 : Claude exécute désormais toutes les étapes sans en oublier. Voir aussi le workflow LinkedIn + IA qui est un autre candidat naturel à packager en skill (chaque enrichissement de lead est répété 500 fois par semaine).

Comment j'ai packagé "draft-article" en 30 minutes

J'ai packagé la skill draft-article en 30 minutes chrono, le même soir que illustrate-article. Sans une ligne de TypeScript ou de Python. La méthode tient en 4 étapes : créer le dossier, écrire SKILL.md, ajouter un script si besoin, tester avec un cas réel. Tu peux la copier sur ton repo en 1 heure max, en incluant la phase d'itération.

Voici le déroulé exact. Ouvre ton terminal dans le repo. Suis les 4 étapes en parallèle de ce que tu lis.

1. Crée le dossier de la skill — 30 secondes. mkdir -p .claude/skills/draft-article/scripts. Le sous-dossier scripts/ est optionnel, mais tu l'auras probablement besoin pour un helper.
2. Écris le fichier SKILL.md — 20 minutes. Le frontmatter (name + description) prend 2 minutes. La procédure prend 18 minutes. Pense en étapes numérotées : Step 1 lire les docs source, Step 2 parser l'input, Step 3 générer l'output, Step 4 vérifier. Garde sous 500 lignes.
3. Ajoute un helper script si besoin — 5 minutes. Pour draft-article, j'ai créé scripts/new-brief.sh qui scaffolde un brief depuis un template. 24 lignes de bash. Rends-le exécutable avec chmod +x.
4. Teste avec un cas réel — 5 minutes. Lance la skill sur un brief existant. Si Claude ne déclenche pas, c'est presque toujours la description. Réécris-la avec les phrases-trigger exactes que tu utiliserais en pratique.

Le frontmatter de draft-article ressemble à ça :

---
name: draft-article
description: Génère un draft HTML d'article pour le blog VibesMoney
  à partir d'un brief de recherche dans `_internal/drafts/<slug>.md`.
  Use when the user invokes /draft-article <slug>, asks to draft a
  blog article, or has prepared research notes. Reads source-of-truth
  docs (CONTENT_BRIEF, BLOG_README, article-template), applies the
  VibesMoney editorial voice, produces SEO meta + JSON-LD + structured
  prose, updates sitemap.xml + blog/index.html. Args: <slug>.
---

# Draft Article

Génère un draft HTML conforme à la patte VibesMoney pour
`blog/<slug>.html` à partir d'un brief de recherche.

## Inputs
- `<slug>` (required) : slug en kebab-case...

## Pre-flight
1. Brief existe à `_internal/drafts/<slug>.md` ?
2. Article n'existe pas (anti-overwrite) ?
3. Template, CONTENT_BRIEF, BLOG_README présents ?

## Step 1 — Lire les sources de vérité
1. CONTENT_BRIEF.md — extraire tonalité, persona, anti-patterns
2. BLOG_README.md — extraire SEO checklist
3. article-template.html — extraire le squelette
4. 1 article anchor — pour la voix

## Step 2 — Parser le brief
...

Anecdote du test final. J'ai testé draft-article sur un brief de pricing que je venais d'écrire. La skill a généré le HTML en 1 prompt. Zéro retouche manuelle pour la voix éditoriale, parce que la skill lit elle-même CONTENT_BRIEF.md au moment de l'exécution. C'est ce même pattern que j'applique pour un onboarding qui évite 70% du churn : la machine connaît la règle, elle l'applique automatiquement, tu valides à la fin.

Les 5 erreurs qui font qu'une skill ne se déclenche jamais

Une skill qui ne se déclenche pas, c'est une skill qui n'existe pas. La communauté Claude (Marc Bara sur Medium, retours r/ClaudeAI) a documenté 5 failure modes récurrents en 2026 : description vague, SKILL.md trop long, side effects sauvages, pas de section Gotchas, pas de when-to-use clair. La cause numéro un : 70% des activation failures viennent d'une description trop floue.

Petit rappel de vocabulaire. Un side effect (effet de bord), c'est une action qui modifie quelque chose au-delà de ton ordi : envoi d'un email, déploiement en prod, commit Git. Un fallback, c'est le comportement par défaut quand le système ne sait pas quoi faire. Activation failure, c'est quand Claude n'invoque pas la skill et fait fallback sur sa réponse générique.

1. Description vague — la cause numéro un

Tu écris "génère des images" dans la description. Claude ne déclenche jamais la skill quand tu tapes "illustre l'article X". Pourquoi ? "Images" est trop générique, "illustre" n'est pas dans la description. Fix : réécris avec les phrases-trigger réelles. "Use when the user asks to illustrate a blog article, add visuals to an article, or invokes /illustrate-article". Activation passe à 100%.

2. SKILL.md trop long — au-delà de 500 lignes, Claude lit la moitié

Tu mets 800 lignes pour être exhaustif. Claude lit les 200 premières et skip le reste. Résultat : il exécute la moitié de ta procédure, oublie les étapes critiques, te livre du travail incomplet. Fix : compresse à 500 lignes max. Déplace les détails (templates, longs exemples) dans des fichiers séparés que la skill peut lire à la demande.

3. Pas de "when to use" explicite

Tu décris ce que la skill fait, pas quand l'utiliser. Claude voit la description, comprend l'output, mais ne sait pas reconnaître les situations où invoquer. Fix : ajoute une phrase qui commence par "Use when the user asks to..." avec 2 ou 3 phrases-trigger réelles. C'est ce qui fait passer ton taux d'activation de 30% à 100%.

4. Side effects sauvages sans disable-model-invocation

Ta skill fait git commit ou npm run deploy. Elle est auto-déclenchée par Claude dès qu'il pense que c'est pertinent. Conséquence : commits sauvages, déploiements non voulus, support saturé. Fix : ajoute disable-model-invocation: true dans le frontmatter. La skill ne se déclenche plus que via slash command manuel /cmd. Tu reprends le contrôle.

5. Pas de section "Gotchas" — les erreurs récurrentes ne sont jamais documentées

Claude répète la même erreur dans la skill, version après version. Tu corriges en chat, mais à la session suivante, l'erreur revient. Fix : ajoute une section "Gotchas" dans SKILL.md qui liste les erreurs réelles et leur fix. Mets à jour à chaque nouveau cas. C'est ce que la communauté appelle "le or de la maintenance" : la skill apprend de ses propres ratés.

Anecdote personnelle. J'ai galéré 1 heure sur ma première skill (illustrate-article v1) parce que la description disait juste "génère des images". Claude ne la déclenchait pas quand je tapais "illustre l'article X". J'ai réécrit la description en 5 lignes précises avec les phrases-trigger. Activation 100% au prompt suivant. La leçon : la description n'est pas un résumé. C'est un signal d'invocation.

Quand packager une skill vs quand garder un simple prompt

Toutes les répétitions ne méritent pas une skill. La règle communautaire Q1 2026 : 3 fois la même tâche ET utilisation hebdomadaire = candidate skill. Sweet spot 2026 = 5 skills régulièrement utilisées maximum. Au-delà, l'overhead cognitif (laquelle déclencher ?) dépasse le gain. Sur les 12 workflows que j'ai identifiés comme répétés, j'en ai packagé 4.

Voici la matrice de décision que j'applique :

• Tu fais la tâche 1 fois par mois. Garde un prompt copié-collé dans Notion. Le coût de packaging (30 minutes) ne sera jamais rentabilisé.
• Tu fais la tâche 1 fois par semaine. Limite : prompt sauvegardé. Tu peux packager si tu veux uniformiser le ton (cas du blog), sinon le prompt suffit.
• Tu fais la tâche 3+ fois par semaine. Skill obligatoire. Tu rentabilises en 2 semaines.
• La tâche a des side effects (deploy, commit, send email). Skill avec disable-model-invocation: true. Manuel uniquement, jamais auto-déclenché.

Sur les workflows répétés qu'on identifie dans le programme VibesMoney, j'en ai packagé 4 en skills à date : illustrate-article (visuels in-article), draft-article (rédaction d'article depuis un brief), plus 2 autres internes. Les autres restent des prompts dans Notion. Pourquoi ? Parce que je ne les utilise qu'une fois par mois, ou que le contexte change trop entre chaque utilisation pour qu'une skill rigide marche.

Le piège classique du débutant : packager 15 skills la première semaine, parce que c'est nouveau et excitant. Au bout d'un mois, tu en utilises 3 régulièrement. Les 12 autres dorment dans .claude/skills/ et tu les oublies. Tu perds le bénéfice de la cohérence (parce que tu as 15 ton possibles) et tu gagnes l'overhead mental (laquelle déclencher ?).

La méthode VibesMoney : tu installes la stack 12 semaines dès le début du programme. Tu packages ta première skill autour de TON workflow le plus répété, une fois la stack rodée. Tu en as 3 à 5 à la fin du programme. Pas plus. C'est cette discipline qui transforme les skills en levier durable, pas en gadget.

Au final, une skill réussie remplit 4 critères. Elle se déclenche à 100% sur ses phrases-trigger. Elle exécute toutes les étapes sans en oublier. Elle produit un output que tu n'as pas besoin de retoucher pour la voix. Elle gagne au moins 15 minutes par invocation. Si une de tes skills rate sur l'un de ces 4 critères, elle est à reécrire, pas à abandonner.