skills

En profondeur

L’économie du contexte

Le patron répond à un problème d’économie du contexte. Une consigne permanente qui grossit se paie à chaque appel, occupe la fenêtre de contexte au détriment du travail en cours, et dilue l’attention du modèle sur des instructions dont la tâche du moment n’emploie qu’une fraction. Un skill est un bloc autonome : un nom, une description courte, puis un contenu qui peut être long, fait de procédures, de conventions, d’exemples, parfois de fichiers ou de scripts joints. Seule la description reste visible en permanence, quelques lignes par ensemble, et c’est sur elle que la sélection se fait ; le contenu entier n’arrive qu’au moment où il est retenu. Le mécanisme tient donc en deux temps, un index toujours présent et un corps chargé à la demande, ce qui est exactement le compromis d’un classement : on garde le catalogue sous la main, on va lire le dossier quand la question se pose.

L’effet budgétaire

Le premier effet est budgétaire et il se mesure : dix procédures détaillées écrites dans le prompt système se facturent à chaque tour, alors que leurs dix descriptions coûtent quelques lignes et que la procédure utile ne se charge qu’une fois sur dix. Le deuxième est organisationnel, et il compte davantage à l’usage : un skill est un artefact séparé, donc versionnable, relisible et attribuable à une équipe, là où un prompt système est un texte unique que tout le monde modifie et que personne ne relit en entier. Le troisième est la portée, puisqu’un même ensemble sert plusieurs agents : la question glisse de « comment formuler » vers « qui possède cette procédure ». En contrepartie, on introduit une décision de plus dans la boucle, celle de la sélection, et une décision de plus est une occasion de plus de se tromper. L’arbitrage se pose donc terme à terme : ce qui doit valoir pour toutes les tâches reste dans le prompt système, ce qui ne sert qu’à certaines devient un skill, et une procédure employée à chaque appel n’a rien à gagner à être rangée ailleurs.

La sélection

La sélection est le point fragile, et elle échoue de deux façons symétriques : un ensemble pertinent qui n’est pas retenu, parce que sa description ne dit pas dans quelles situations il s’applique, et un ensemble retenu à tort, parce que deux descriptions se recouvrent. C’est exactement le défaut des descriptions d’outils, pour la même raison : le modèle choisit sur la foi de quelques lignes, sans avoir lu le contenu. Un deuxième piège apparaît quand plusieurs ensembles arrivent ensemble dans le contexte et se contredisent, l’un imposant un format que l’autre proscrit : personne n’a écrit l’arbitrage, et le modèle en produit un que rien ne rend stable. Le troisième est le plus sérieux : un ensemble chargé depuis une source qu’on ne contrôle pas est du texte qui entre dans le contexte avec le statut d’une consigne, ce qui en fait une porte d’entrée pour une injection de prompt, d’autant plus efficace que le dispositif est prévu pour lui obéir. Un catalogue de skills se traite donc comme une dépendance logicielle : on sait d’où vient chaque élément, on le relit avant de l’installer, on le fige à une version, et on vérifie par un jeu de cas que la bonne sélection se fait bien sur les tâches qui comptent.