Les skills : automatiser vos workflows

Vous allez vite reconnaître le symptôme. Pour la troisième fois cette semaine, vous tapez la même demande à rallonge : « relis mon diff, cherche les bugs et les fuites de secret, liste-moi les problèmes par fichier, mais ne corrige rien sans mon accord. » Mot pour mot, à chaque fois. C’est précisément le moment où il faut capturer cette demande une bonne fois, et la rappeler d’une seule commande.

C’est ça, un skill : un paquet d’instructions réutilisable que l’agent déclenche à la demande, souvent via une commande slash. Là où le fichier mémoire est du contexte passif que l’agent lit toujours, un skill est une capacité active que vous invoquez quand vous en avez besoin. Imaginez /relecture (relis mon diff), /ship (lance les tests, bump la version, commit, ouvre la PR), /deploy. Un nom, et le workflow entier se déroule.

Pourquoi : la répétition est un signal

Le déclencheur d’un skill, c’est toujours le même : vous vous surprenez à retaper une instruction multi-étapes. « Lance les tests, et si c’est vert, commit avec un message conventionnel, puis pousse… » Si vous l’avez écrit deux fois, vous l’écrirez vingt fois.

Capturez-le une fois, et vous gagnez trois choses d’un coup :

• Une commande au lieu d’un paragraphe. Vous tapez /relecture, point.
• De la constance. Le workflow tourne pareil à chaque fois, vous n’oubliez plus l’étape « vérifier les secrets » parce que vous étiez pressé.
• Du partage. Le skill vit dans le dépôt : vos coéquipiers (et leurs agents) l’utilisent tel quel.

Comment ça marche, concrètement

Le principe est désormais le même partout : un skill est un dossier qui contient un fichier SKILL.md. En tête, un petit en-tête YAML donne son nom et une description ; en dessous, vos instructions en markdown. Le dossier peut aussi embarquer des scripts, des modèles ou de la documentation que l’agent consultera au besoin.

La description compte plus qu’elle n’en a l’air : au démarrage, l’agent ne lit que les noms et les descriptions de tous vos skills, puis charge le contenu complet de celui qui correspond à la tâche. Vous pouvez donc en avoir beaucoup sans encombrer son contexte.

.claude/skills/<nom>/SKILL.md    # skills du projet (partagés via le dépôt)
~/.claude/skills/<nom>/SKILL.md  # skills globaux (tous vos projets)

.opencode/skills/<nom>/SKILL.md           # skills du projet
~/.config/opencode/skills/<nom>/SKILL.md  # skills globaux
# Il lit aussi .claude/skills/ et .agents/skills/ (projet et global)

.agents/skills/<nom>/SKILL.md     # skills du projet (Codex remonte jusqu'à la racine du dépôt)
~/.agents/skills/<nom>/SKILL.md   # skills globaux (tous vos projets)

Un exemple : la commande /review

Reprenons la demande du début, votre revue à vous. Attention au nom : Claude Code fournit déjà un /review d’origine (alias de /code-review, voir Relire, auditer, sécuriser). Appelez donc la version maison autrement, relecture par exemple (Codex a lui aussi un /review d’origine), et posez-la une fois dans .claude/skills/relecture/SKILL.md, ou dans .agents/skills/relecture/SKILL.md pour Codex et OpenCode :

---
name: relecture
description: Relit le diff courant et liste les problèmes sans rien corriger. À utiliser quand je demande une relecture avant un merge.
---

Relis le diff courant contre la branche de base.

Cherche :
- les bugs et les régressions évidentes,
- les fuites de secret (clé API, mot de passe, token en clair),
- les requêtes SQL non échappées ou autres injections,
- les `console.log` et autres oublis de debug.

Liste les problèmes regroupés par `fichier:ligne`, du plus grave au plus
bénin. Sois concret : pour chaque point, dis pourquoi c'est un problème.

Ne corrige rien sans mon accord. Termine par un verdict : prêt à merger, ou pas.

À partir de là, /relecture (ou $relecture dans Codex) relance ce protocole exact à chaque fois. Plus de paragraphe à retaper, plus d’étape oubliée.

La marche à suivre

La vue d’ensemble : votre atelier qui se compose

Posez-vous et regardez ce que vous avez construit au fil de ces trois fiches :

• La mémoire (fichiers mémoire), ce que l’agent sait en permanence.
• Les skills : ce qu’il sait faire sur commande.
• Le cadrage (cadrer avec un LLM), la qualité de ce que vous lui demandez au départ.

Mis bout à bout, ça devient un atelier personnel qui se compose. Chaque projet enrichit votre mémoire globale, vous laisse un ou deux skills réutilisables, affine vos patrons de cadrage. Le dixième projet démarre sur les épaules des neuf premiers. C’est tout l’intérêt : vous n’automatisez pas une tâche, vous vous construisez un environnement qui vous rend chaque fois un peu plus rapide.