Créer des Skills : workflows d'agent plutôt que prompts jetables

Un prompt est une idée. Un skill est un outil. Cette distinction décide si le travail IA vit dans des têtes individuelles ou dans le dépôt d'équipe.

Ce qu'est un skill

Un skill rassemble trois éléments au même endroit :

1. Un prompt système qui définit rôle, finalité et limites.
2. Des outils auxquels le skill peut accéder - système de fichiers, base de données, client HTTP, API interne.
3. Un standard qualité qui définit ce qui compte comme « terminé ».

Ce qu'un skill n'est pas : un prompt joli dans une page Notion. La versioning est la clé. Un skill vit dans Git, a une histoire, peut être revu et annulé.

Pourquoi cela change le quotidien

Trois effets concrets reviennent régulièrement :

• Reproductibilité. Deux collègues produisent des résultats comparables sur la même tâche.
• Revisabilité. Des pull requests sur les skills permettent une vraie discussion - au-delà de « quel était le meilleur prompt ».
• Délégation aux agents. Un skill qu'un humain utilise aujourd'hui peut être appelé automatiquement par un agent demain.

Un exemple tiré de notre quotidien

Notre skill timetrack lit les commits Git, les croise avec des règles projet et saisit des entrées de temps dans TimeCockpit. Avant : rapprochement manuel, cinq à dix minutes par jour, fautes faciles. Après : une commande, deux questions, saisie terminée. Le facteur décisif n'était pas le modèle de langage mais le skill structuré autour - avec des règles projet explicites dans .claude/TIMECOCKPIT.md et des critères de réussite clairs.

Du prompt jetable à l'actif d'équipe

Trois questions aident à condenser les prompts existants en candidats-skills :

1. Ce prompt est-il utilisé plus de trois fois par mois ?
2. Nécessite-t-il un contexte qui ne change pas à chaque fois ?
3. Y a-t-il un critère de succès clair (« terminé veut dire X ») ?

Trois oui et investir dans un vrai skill en vaut presque toujours la peine - pour les humains de l'équipe aujourd'hui, pour les agents demain.