Un Skill Claude, ce n’est pas un prompt sauvegardé
Avant, chaque fois que je démarrais un nouveau projet de développement, je réexpliquais les mêmes neuf phases : cadrage, analyse, architecture, planification, implémentation, tests, revue qualité, livraison, archivage. À chaque fois, en détail, dans un nouveau chat. Aujourd’hui, je tape /sdlc:brainstorm et tout s’enchaîne : les bonnes questions se posent dans le bon ordre, sans que j’aie à retaper la méthode. Ce n’est pas un prompt que j’ai sauvegardé quelque part. C’est un Skill.
La différence qui compte
Un prompt sauvegardé, c’est un texte que tu colles. Toi qui décides quand, toi qui te souviens qu’il existe, toi qui vas le rechercher dans ton dossier de prompts favoris, et si le prompt fait 400 mots, tu les retapes (ou recolles) à chaque fois. Un Skill, lui, porte tout ce contexte en un seul déclencheur, court ou invisible.
Il y a en fait deux façons dont mes Skills se déclenchent, et je choisis laquelle selon l’enjeu. Pour une tâche du quotidien (reformuler un texte dans mon ton, vérifier un point de sécurité), le Skill se déclenche tout seul, dès que Claude reconnaît le type de demande, sans que j’aie besoin de le nommer. Pour mon cadre de développement, en revanche, je préfère taper explicitement /sdlc:brainstorm : basculer dans un processus aussi structurant (neuf phases, de la définition du besoin jusqu’à l’archivage) doit rester une décision consciente, pas un déclenchement surprise. Dans les deux cas, ce qui compte est le même : je n’ai jamais à retaper la méthode elle-même. Le prompt, lui, ne t’offre ni l’un ni l’autre.
Ce même Skill sait aussi s’alléger tout seul selon la taille du projet, ce qu’un prompt copié-collé ne fait jamais. Il commence par estimer si le projet est petit, moyen ou grand ; sur un petit projet, il saute directement au plan sans les étapes de discussion approfondie utiles seulement aux gros projets. Le prompt, lui, pose toujours les mêmes questions, qu’il s’agisse d’un script de dix lignes ou d’une application complète : c’est à moi de me souvenir qu’il faut « sauter » certaines parties, et j’oublie.
Dans mon écosystème actuel, rien que la suite liée à mon cadre de développement compte une quinzaine de Skills distincts : un pour cadrer un projet, un pour l’architecture, un pour la revue de code, un pour vérifier avant de déclarer un travail terminé, et ainsi de suite. D’autres Skills, plus légers, je ne les invoque jamais par leur nom : ils se reconnaissent directement au contexte de ce que je suis en train de faire.
Ce qu’un bon Skill fait aussi : dire ce qu’il ne doit PAS faire
Le piège classique en construisant son premier Skill, c’est de ne décrire que ce qu’il doit accomplir. Résultat : il se déclenche n’importe quand, y compris sur des tâches voisines mais différentes, ou il refuse de se déclencher parce que sa description est trop floue. Un Skill qui fonctionne bien documente autant ses refus que ses cas d’usage.
Exemple concret dans mon propre environnement : un des Skills que j’utilise le plus souvent pour coder documente noir sur blanc, en deux blocs séparés, quand se déclencher et quand ne surtout pas le faire, jusqu’à nommer explicitement les cas voisins à écarter (un autre fournisseur d’IA mentionné dans la conversation, par exemple) pour ne pas se déclencher à tort. Cette liste de refus n’est pas un détail secondaire : sans elle, le Skill s’activerait sur des questions qui n’ont rien à voir avec ce qu’il sait vraiment faire.
Ça me rappelle une règle que j’applique déjà ailleurs sur ce blog, sans l’avoir jamais formulée en ces termes : ma liste de ce que je ne publie jamais (aucun appel à l’action commercial, aucun jargon de vente) est aussi structurante que ce que je publie. Un Skill fonctionne pareil : ce qu’il refuse de faire fait autant partie de sa définition que ce qu’il exécute.
Comment je débogue un Skill qui ne se déclenche pas comme prévu
Quand un Skill ne s’active pas au bon moment (ou s’active trop souvent), je ne réécris pas tout de zéro. Je demande directement : « dans quel cas utiliserais-tu ce Skill ? ». La réponse révèle immédiatement si la description est assez précise : si Claude hésite ou se trompe de cas, c’est que la description mérite d’être resserrée, pas que le Skill est mauvais.
Ce que tu peux essayer cette semaine
Tu n’as pas besoin de quinze Skills pour commencer. Repère une tâche que tu refais chaque semaine (un type de courriel, un format de compte-rendu, une checklist de vérification) et demande à ton IA de la transformer en Skill réutilisable : ce qu’il doit faire, dans quel contexte il doit se déclencher, et tout aussi important, dans quel cas il ne doit pas s’activer. Teste-le sur un vrai cas la semaine suivante, ajuste la description s’il se trompe de moment. Le gain n’est pas de gagner du temps sur cette seule tâche : c’est de ne plus jamais avoir à réexpliquer comment tu veux qu’elle soit faite.
Encore plus simple pour démarrer : tu n’as même pas besoin de partir d’une page blanche. La prochaine fois qu’une conversation avec ton IA se termine bien (tu as trouvé la bonne méthode après plusieurs allers-retours), dis-lui simplement « transforme cet échange en Skill ». Elle peut relire ce qui vient de se passer (les outils utilisés, l’ordre des étapes, les corrections que tu as apportées en chemin) et en tirer un premier jet. Le travail que tu viens de faire une fois, tu ne le refais jamais une seconde.
En résumé
- Un prompt sauvegardé s’oublie, se retape, se recherche. Un Skill se déclenche tout seul, reconnaît le contexte, et reste actif d’une session à l’autre.
- Un bon Skill sait aussi s’alléger selon l’enjeu : un petit projet saute des étapes qu’un gros projet garde, sans que tu aies à t’en souvenir toi-même.
- Ce qu’un Skill refuse de faire fait autant partie de sa définition que ce qu’il exécute : sans ça, il se déclenche n’importe quand.
- Il ne se débogue pas en le réécrivant : demande-lui « dans quel cas t’activerais-tu ? » et resserre la description en fonction de la réponse.
- Pas besoin de partir de zéro : une conversation qui vient de bien se passer peut, elle-même, devenir le premier jet d’un Skill.
Toi, c’est quoi la tâche que tu refais chaque semaine et que tu pourrais transformer en Skill ? Dis-le-moi en commentaire.
Cet article reprend, en version écrite, ma vidéo « un Skill, ce n’est pas un prompt » publiée sur TikTok. Si tu veux la version courte, elle est ici.
Cet article fait partie d’une série sur ma pratique quotidienne de l’IA, après mon atelier IA n’a pas 6 outils, il en a un et vibecoder sans se faire piéger. Abonne-toi au blog pour la suite.