Concevoir, affiner et maintenir des agent skills chez Perplexity

Les produits d’agents de pointe de Perplexity reposent sur une base de savoir-faire et d’expertise métier intégrée dans des Skills modulaires. Nous entretenons une bibliothèque soigneusement sélectionnée de Skills à travers nos environnements techniques. Ces Skills incluent de nombreux utilitaires polyvalents qui alimentent Perplexity Computer ; des fonctionnalités verticales dans des domaines tels que la finance, le droit et la santé ; ainsi qu’une très longue traîne de modules destinés à répondre aux besoins des utilisateurs. Certains Skills sont rarement invoqués, mais essentiels lorsqu’ils le sont. Afin de garantir une expérience utilisateur constamment excellente, l’équipe Agents de Perplexity accorde autant d’importance à la qualité des Skills qu’à la qualité du code.

Les intuitions et les meilleures pratiques requises pour développer un Skill de haute qualité diffèrent considérablement de celles nécessaires pour créer des logiciels traditionnels. L’équipe Agents examine de nombreuses demandes de tirage (pull requests) provenant d’excellents ingénieurs qui développent des Skills dans le cadre de leur travail. Le résultat se traduit presque toujours par de nombreux commentaires et suggestions de révision. Cela s’explique par le fait que de nombreux modèles utiles pour écrire du code deviennent des anti-modèles dans la création de Skills.

Par exemple, si vous prenez certains aphorismes de PEP20 – Le Zen de Python, il devient vite évident qu’écrire du bon code Python n’a rien à voir avec l’écriture de bons Skills. Sur les 20 lignes de sagesse, au moins la moitié sont totalement fausses ou activement trompeuses lors de l’écriture de Skills. Voici cinq d’entre elles :

Cinq contrastes entre le Zen de Python et les recommandations de l’article pour la rédaction de Skills.

Ce guide est le document que les ingénieurs chez Perplexity utilisent pour développer et réviser des Skills. Nous publions également ce guide pour que nos découvertes et enseignements puissent bénéficier à la communauté au sens large. Que vous soyez un ingénieur concevant des Skills de production dans votre travail quotidien, un utilisateur de Computer cherchant à développer votre propre Skill dans un domaine que vous maîtrisez, ou les deux, ce guide est fait pour vous.

Qu’est-ce qu’un Skill ?

Lorsque vous écrivez un Skill, vous n’écrivez pas un logiciel ordinaire (même si les Skills font désormais partie des moteurs logiques principaux pour les systèmes d’agents). Vous construisez plutôt du contexte pour les modèles et leurs environnements. Un Skill possède des contraintes et des principes de conception différents. Si vous écrivez un Skill comme vous écrivez du code, vous échouerez.

Un Skill est au moins quatre choses, surtout dans le contexte de la manière dont nous les construisons chez Perplexity.

Un Skill est un répertoire

Un Skill n’est pas juste un seul fichier SKILL.md. Dans de nombreux cas, un Skill inclut plusieurs fichiers. Sous le répertoire nommé d’après votre Skill, vous pourriez avoir :

SKILL.md : métadonnées et instructions

scripts/ : code que l’agent exécute, et non réinvente

references/ : documents lourds, chargés de manière conditionnelle

assets/ : modèles, schémas et données

config.json : configuration utilisateur lors de la première exécution

Ce modèle en étoile (hub-and-spoke) vous permet de garder les Skills très concentrés et compacts, et il est possible d’utiliser la structure de dossiers de manière très créative. Parfois, les Skills particulièrement complexes bénéficient de plusieurs niveaux de hiérarchie pour aider le modèle à mieux s’y retrouver. Supposons qu’un Skill nécessite des connaissances couvrant 300 sujets, regroupables en 20 domaines d’expertise. Choisir de manière fiable le bon sujet parmi 300 est un défi non résolu, même pour les meilleurs modèles de pointe actuels. Il s’agit d’un problème de choix bien plus simple pour un modèle de se concentrer sur l’un des 20 domaines, plutôt que sur les 15 sujets au sein de ce domaine.

En guise d’exemple de la valeur ajoutée par une hiérarchie multiniveaux, notre équipe a employé trois niveaux d’imbrication thématique au sein des Skills alimentant les capacités liées à l’impôt sur le revenu américain de Computer lors de la dernière saison fiscale. Cette hiérarchie était absolument indispensable compte tenu de la complexité du droit fiscal : lors de nos tests initiaux, présenter au modèle un dossier unique contenant les 1 945 sections du Code des impôts américain a entraîné des performances inférieures à celles obtenues sans charger le Skill. L’organisation des informations en subdivisions logiques était indispensable pour garantir des opérations de lecture de haute précision.

Cependant, cette hiérarchie n’était pas gratuite. L’augmentation des niveaux de hiérarchie exige des niveaux de curation accrus dans l’architecture de l’information pour gérer l’indirection qui en résulte. Nous avons conçu des guides de référence rapide, des utilitaires de recherche personnalisés et d’autres outils pour aider le modèle à localiser les informations avec un minimum d’indirection. Dans ce cas, le travail fastidieux de curation a finalement produit un résultat positif : un Skill qui a permis aux modèles d’effectuer des tâches liées à l’impôt de manière bien plus compétente que l’utilisation d’outils généraux seuls.

Agrandir

Un Skill est un format

Un Skill est un format. Le fichier racine principal SKILL.md doit avoir à la fois un nom et une description. En outre, le Skill doit correspondre exactement au nom du répertoire dans lequel il est situé. Le nom doit être entièrement en minuscules, ne comporter aucun espace et peut utiliser des traits d’union. La description est le déclencheur de routage. Il s’agit d’un point d’échec courant : la description n’est pas une documentation interne sur ce que fait le Skill. Elle équivaut à des instructions données au modèle sur le moment de charger le Skill. Ainsi, vous verrez fréquemment « Charger lorsque », et non « Ce Skill fait ». C’est important en raison de la manière dont la plupart des implémentations injectent la description dans le contexte du modèle.

Au sein des métadonnées, il existe également « depends: », qui vous permet de créer des dépendances hiérarchiques entre Skills, et « metadata: », qui est utilisé pour les revues et les évaluations. Différents systèmes d’agents peuvent même définir leurs propres champs de métadonnées, à utiliser d’une manière spécifique à ces systèmes. Alternativement, les métadonnées spécifiques aux Skills peuvent être emballées dans un fichier de configuration auxiliaire JSON ou YAML. C’est souhaitable lors de la création de systèmes d’agents qui doivent faciliter différents types de comportements d’exécution par Skill sans polluer le contexte du modèle avec des détails. Enfin, un comportement similaire peut être obtenu en supprimant les métadonnées du Skill lors de la lecture. Computer utilise cette méthodologie, ce qui permet de conserver la configuration dans le fichier racine SKILL.md. Une attention particulière aux détails est requise dans la logique d’analyse, et vous pourriez souhaiter implémenter une suppression conditionnelle s’il existe certains champs utiles à conserver dans le contexte du modèle.

Un Skill est invocable

Un Skill est invocable. L’agent charge un Skill lors de l’exécution. Il est important de noter que les Skills ne sont pas toujours regroupés dans le contexte. Par défaut, la plupart des systèmes d’agents déploient les Skills progressivement en fonction des besoins spécifiques.

Il existe au moins trois niveaux de coûts de contexte dans la façon dont nous avons implémenté les Skills dans Computer. Voici le processus :

Computer appelle load_skill(name="...")

Computer copie le répertoire du Skill dans le bac à sable d’exécution isolé

Computer charge récursivement les dépendances dans la balise « depends: »

Computer supprime ensuite les métadonnées et l’agent ne voit donc que le corps et les fichiers supplémentaires

Différents systèmes d’agents peuvent choisir d’exposer le contenu d’un Skill de différentes manières. Par exemple, certains systèmes pourraient choisir de ne pas exposer du tout la hiérarchie des fichiers, laissant au modèle le soin de la découvrir via des opérations sur le système de fichiers. D’autres systèmes peuvent choisir de donner au modèle une cartographie de toute l’arborescence des fichiers jusqu’à une certaine limite de troncature et/ou de profondeur. Pour garder le contexte propre, Computer omet les hiérarchies de fichiers complètes du contexte d’invocation ; cependant, cela peut être annulé par Skill.

Un Skill est progressif

Les Skills sont progressifs. Dans Computer, il existe trois niveaux différents de coûts de contexte, et nous les subissons tous à différents stades :

Les trois niveaux de contexte d’un Skill : index, chargement complet du Skill et fichiers de référence d’exécution.

Computer construit un index de Skills qui contient le nom et la description de chaque Skill disponible. Le budget pour cela est d’environ 100 jetons par Skill (plus court est encore mieux). C’est très serré car vous payez ce coût à chaque Session, pour chaque utilisateur. Cela est injecté dans le prompt système au tout début de la conversation. Le modèle a accès à un ensemble de Skills nommés et à leurs descriptions afin de pouvoir décider s’il doit appeler « load_skill() ». La barre pour entrer dans cet index est extrêmement élevée. Votre Skill doit être très utile, et la description doit être extrêmement dense et concise car tout le monde paie le coût tout le temps.

Après que le système d’agents charge le Skill, il y a le corps complet de SKILL.md. Idéalement, le texte du corps ne dépasse pas 5 000 jetons. Même dans ce cas, vous voulez que chaque phrase compte, car une fois que vous chargez un Skill, le reste de la conversation doit en payer le coût jusqu’à ce que vous atteigniez la limite de compaction. De nombreux fils (threads) chargent entre trois et cinq Skills différents, multipliant ce coût. Les Skills contenant beaucoup de superflu dégraderont presque certainement les autres Skills ainsi que les capacités agentiques globales. En bref, si votre Skill se charge et qu’il ne fait pas ce qu’il faut, c’est du contexte gaspillé.

Le niveau final de progression concerne les scripts ou les cas particuliers, comme les sous-skills ou le formatage. C’est là que vous voulez mettre une logique de branchement conditionnel non bornée. L’agent ne l’utilisera que lorsqu’il en aura besoin, ce qui signifie qu’il y a une barre beaucoup plus basse pour ce que vous voulez mettre ici.

Dans l’index, chaque jeton est important. Le corps de Skill chargé est plus détendu, et l’exécution est le plus détendu. Cela pourrait être 20 000 jetons ou zéro jeton. C’est le niveau auquel vous pourriez envisager d’étendre le Raisonnement du modèle de manière progressive.

Quand avez-vous besoin d’un Skill ?

L’équipe Agents est souvent sollicitée pour donner son avis sur la nécessité réelle d’un Skill pour un domaine ou un cas d’usage donné. Nous avons très rarement une réponse définitive basée uniquement sur les premiers principes. La seule façon de vraiment le déterminer est de commencer avec votre agent sans le Skill, d’exécuter plusieurs requêtes héroïques, puis de déterminer si l’agent fait du bon travail.

Quand vous avez besoin d’un Skill

Il existe de nombreuses tâches qui sont dans la distribution des modèles entraînés. Vous n’avez besoin d’appliquer un Skill que si vous souhaitez modifier ce comportement d’une manière spécifique que vous ne pouvez pas obtenir avec, disons, une phrase dans votre prompt. Donc, vous avez besoin d’un Skill lorsque l’agent fera erreur sans contexte spécial, ou s’il y a une incohérence ou un non-déterminisme que vous devez rendre extrêmement cohérent à travers les exécutions.

Il se pourrait que vos connaissances soient durables mais pas dans les données d’entraînement. Il pourrait y avoir des dates limites ou des flux de travail spécifiques à l’entreprise, ou il pourrait s’agir d’une question de goût. Par exemple, nous avons plusieurs Skills liés à la conception dans Computer écrits par Henry Modisett (notre chef de design). La raison pour laquelle chaque jeton existe dans ces Skills est qu’Henry a très bon goût en matière de conception de sites web et de PDF. Henry précise quelles polices utiliser et lesquelles ne pas utiliser, comment ces polices se sentent, et d’autres questions de jugement que le modèle ne peut pas apprendre uniquement à partir des données d’entraînement.

Quand vous n’avez pas besoin d’un Skill

Nous voyons de nombreux Skills dans lesquels les ingénieurs ont écrit une série de commandes git qui doivent être exécutées dans l’ordre. C’est inutile car le modèle sait déjà comment faire cela, ce qui signifie que cela fait une excellente documentation mais un pauvre Skill.

Nous voyons des exemples où les Skills récapitulent des instructions du prompt système. Vous n’avez pas besoin d’un Skill pour cela. Les connaissances pertinentes pour la majorité des requêtes devraient être incluses dans le contexte global, et non dans un Skill chargé de manière conditionnelle.

S’il y a quelque chose qui change plus vite que vous ne pouvez le maintenir, vous n’avez pas besoin d’un Skill. Par exemple, si vous accédez à un point de terminaison MCP distant et que ses outils ou les versions de ces outils changent fréquemment, vous ne devriez pas les injecter dans un Skill. Si vous le faites, vous finirez simplement avec de la dérive et le modèle fera des erreurs.

Chaque Skill est une taxe

Voici un test utile que vous pouvez appliquer à chaque phrase de votre Skill : « L’agent ferait-il erreur sans cette instruction ? » Si la phrase n’a pas besoin d’être là, elle ne peut pas se permettre d’y être car tout le monde paie ce coût à chaque fois. Lorsque vous décidez d’ajouter un Skill ou non, souvenez-vous de cette taxe dans laquelle chaque Session et chaque utilisateur coûte des jetons.

La citation célèbre suivante, qui sonne beaucoup mieux en français, se traduit approximativement par « Je n’ai fait celle-ci plus longue que parce que je n’ai pas eu le loisir de la faire plus courte. »

« Je n’ai fait celle-ci plus longue que parce que je n’ai pas eu le loisir de la faire plus courte. » — Blaise Pascal, Lettres Provinciales, 1657

Tout comme Pascal, vous devez investir du temps dans chaque Skill. Il est difficile d’écrire un Skill court. Si votre Skill est facile à écrire, il est probablement trop long ou ne devrait pas exister. Un bon Skill est aussi court qu’il peut l’être.

Si vous vous retrouvez à essayer de générer un Skill en un seul coup et à soumettre des PR en cinq minutes, les résultats seront presque certainement médiocres. En fait, des recherches précoces ont montré que si vous utilisez des LLM pour écrire des Skills, le LLM ne bénéficiera probablement pas : « Les Skills auto-générés ne fournissent aucun avantage en moyenne, montrant que les modèles ne peuvent pas autoriser de manière fiable les connaissances procédutales dont ils bénéficient. »

Comment construire un Skill

Autrement dit, vous devez injecter votre opinion dans tout Skill que vous écrivez. Suivez ces étapes.

Étape 0 : Écrire les évaluations

Écrivez d’abord certaines évaluations. Vous pouvez sourcer les cas d’évaluation à partir de :

Requêtes réelles des utilisateurs : échantillonnez à partir de la production ou de votre cercle de confiance

Échecs connus : L’agent a échoué parce que le Skill n’existait pas

Confusion de voisinage : Proche de votre limite de domaine mais se dirige vers un autre Skill

À tout le moins, vous devriez vous assurer de tester que le Skill se charge lorsque nécessaire. Idéalement, vous échantillonnez certains d’entre eux, peut-être à partir d’un environnement de production. Vous pourriez également considérer des cas d’erreur connus : peut-être que toute la raison pour laquelle vous avez décidé d’écrire le Skill est due à un échec spécifique que vous avez remarqué, ou peut-être que vous refactorez et qu’il y a une certaine confusion dans deux domaines proches qui sont couverts par un Skill.

Commencez par des exemples négatifs et positifs similaires. Les exemples négatifs sont extrêmement puissants et peuvent compter plus que les exemples positifs.

Étape 1 : La description

C’est la ligne la plus difficile du Skill. C’est un déclencheur de routage, pas une documentation. Pour obtenir le nom et la description corrects, vous ne vous souciez pas du contenu du Skill. Vous ne vous souciez que de savoir si le Skill est chargé et injecté aux bons endroits et est exempt d’effets secondaires hors cible, ce qui est le premier mode de défaillance. Chaque fois que vous ajoutez un Skill supplémentaire, vous risquez de rendre chaque autre Skill légèrement pire, vous devez donc vous assurer de minimiser la régression.

Encore une fois, une mauvaise description décrit ce que fait le Skill ou pourquoi il est utile. Une bonne description dit quand l’agent doit charger le Skill. Par exemple, disons que vous avez quelque chose pour surveiller les demandes de tirage. N’écrivez pas ce que fait le Skill. Écrivez ce que disent les ingénieurs lorsqu’ils sont frustrés et qu’ils veulent que vous vous assuriez que leur PR fonctionne, comme « surveiller » ou « regarder l’IC » ou « s’assurer que cela aboutisse ».

Voici une liste de contrôle rapide :

Commence par « Charger lorsque... »

Ciblez 50 mots ou moins

Décrit l’intention de l’utilisateur, idéalement à partir de requêtes réelles

Ne résume pas le flux de travail

Les requêtes réelles sont ce que vous pouvez couvrir dans un 80-20. Habituellement, deux ou trois exemples fonctionnent bien. Il n’est pas facile d’ajouter exactement et seulement ce dont vous avez besoin.

Étape 2 : Écrire le corps

Ensuite, écrivez le contenu du Skill lui-même. Notez que ce n’est pas l’étape 0 ou l’étape 1.

Communiquer des flux de travail à un LLM est complètement différent de communiquer des flux de travail à un collègue, ou même à votre système d’exécution. Lors de l’apprentissage d’un nouvel outil logiciel, un ingénieur peut avoir besoin de lire la documentation, d’obtenir une démonstration de quelqu’un avec de l’expérience et d’apprendre à utiliser l’outil. Pendant ce temps, pour presque tout outil logiciel qui existe depuis au moins un an, vous avez juste besoin de mentionner son nom et le LLM a toutes les informations dont il a besoin.

Lorsque vous écrivez le corps, sautez les choses évidentes. De nombreux ingénieurs ont beaucoup d’expérience dans l’écriture de fichiers readme.md qui listent chaque commande que quelqu’un doit exécuter. Il est facile de retomber là-dedans lorsque vous écrivez un Skill parce que vous avez l’impression d’écrire de la documentation, mais si vous le faites, votre Skill sera des ordures. Donc, n’écrivez pas une série de commandes.

Par exemple, vous n’avez pas besoin d’écrire, « git log # trouver le commit; git checkout main; git checkout -b <clean-branch>; git cherry-pick <commit>; »

Au lieu de cela, écrivez, « Cherry-pick le commit sur une branche propre. Résolvez les conflits en préservant l’intention. S’il ne peut pas aboutir proprement, expliquez pourquoi. »

Le modèle fera un bien meilleur travail avec ce dernier qu’avec la série de commandes trop prescriptive de l’ancien, surtout lorsque les choses tournent mal. Ne verrouillez pas, ou ne soyez pas trop prescriptif, ce qui est fragile, et soyez plutôt flexible là où plusieurs approches peuvent fonctionner. Encore une fois, une bonne documentation pour les humains est le plus souvent une mauvaise documentation pour les modèles.

Ensuite, concentrez-vous sur les pièges ou les exemples négatifs. Ce sont des contenus à très haut signal car ils guident souvent le modèle sur ce qu’il ne faut pas faire. Si vous ajoutez une ligne chaque fois que l’agent trébuche, vous apprendrez en l’exécutant et les pièges croîtront organiquement.

Enfin, s’il y a une partie qui est conditionnelle ou extrêmement lourde en contenu, sortez-la du SKILL.md, qui est le hub, et mettez-la dans l’un des rayons. Mettez-la dans un fichier accessoire qui peut être chargé progressivement, ce que nous aborderons ensuite.

Étape 3 : Utiliser la hiérarchie

Faites usage de la hiérarchie de Skill lorsque vous avez un script, des références, ou que vous utilisez un outil spécifique :

Usages suggérés pour les scripts, les références, les ressources et la configuration au sein d’un Skill.

Pour tout ce qui est conditionnel ou qui bifurque depuis le Skill principal, séparez-le dans un dossier. Rappelez-vous, également, qu’une hiérarchie multiniveaux peut être utilisée pour des Skills particulièrement complexes. Pour ceux-ci, vous voudrez réfléchir soigneusement à savoir si la fonctionnalité doit être implémentée de manière monolithique ou comme une collection de Skills (peut-être avec des relations de chargement basées sur depends:).

Étape 4 : Itérer

Ensuite, faites un tas d’itérations sur une branche. Commencez sur la branche principale sans Skill, faites quelques itérations, construisez votre jeu de requêtes héroïques, et exécutez une foule d’évaluations. Quiconque révisera votre code de Skill vous remerciera d’avoir soumis un seul ensemble de modifications complet avec un jeu d’évaluation. Réviser des changements incrémentaux consécutifs (sauf un nouveau piège) est très difficile, alors essayez de le minimiser.

Vous ferez probablement de nombreux petits changements de mots. De petits changements de mots dans les descriptions peuvent avoir un impact démesuré sur le routage (y compris des effets de débordement sur d’autres Skills), alors faites tout ce travail avant l’étape 5.

Étape 5 : Expédier

Expédiez-le.

Comment maintenir un Skill

Maintenant que vous avez écrit un Skill, vous devez le maintenir.

Le volant d’inertie des pièges

À partir de ce moment, votre liste de pièges a tendance à beaucoup croître ou changer. Nous voyons souvent des ingénieurs qui font des PR qui ne sont pas évaluées, par exemple, changer la description. Si vous changez la description après que votre Skill ait été fusionné, vous êtes hors piste. Si vous apportez des modifications à la chose qui décide de router votre Skill, vous devez écrire quelques évaluations qui soutiennent les changements.

Les Skills sont principalement basés sur l’ajout. La section des pièges accumule le plus de valeur au fil du temps :

L’agent échoue sur quelque chose → Ajouter un piège

L’agent charge le Skill hors cible → Resserrer la description et ajouter des évaluations négatives

L’agent ne charge pas le Skill quand il devrait → Ajouter des mots-clés et des évaluations positives

Le prompt système change → Vérifier la contention ou la duplication

Il est facile de remarquer un seul cas d’échec dans les tests internes ou en production et d’ajouter un piège. C’est un exemple négatif donc il ne change pas vraiment les conseils explicites, mais il permet au modèle de savoir : « Hé, il y a cet échec connu. »

À mesure que vous passez du 80-20 à un taux de succès de 99,9 % ou 99,99 %, il est facile de faire croître cette liste de pièges. À mesure que vous voyez ces exemples négatifs, vous devriez principalement les ajouter à la section des pièges. Vous ne devriez pas ajouter de longues instructions ou changer la description.

Suites d’évaluation

Chez Perplexity, nous exécutons de nombreuses suites d’évaluation pour vérifier différentes choses. Il y a le chargement de Skill et la lecture de fichiers de Skill, qui vérifie la précision, le rappel et les vérifications interdites du chargement de Skill lui-même. L’agent routera-t-il votre Skill quand il est censé le faire ? Ceux-ci garantissent que les nouveaux Skills ne brisent pas les frontières existantes.

Il existe également des évaluations qui peuvent vérifier le chargement progressif approprié. L’agent pourrait charger le Skill, mais lit-il le fichier ou les fichiers accessoires ? Par exemple, si vous avez un Skill de finance pour les requêtes de finance, lit-il le fichier spécial FORMATTING.md ?

Il existe également des évaluations pour les Skills qui testent l’achèvement des tâches de bout en bout au sein des domaines. Nous exécutons la boucle d’agent complète et utilisons un juge LLM pour noter les résultats basés sur une rubrique de critères bien définis.

Enfin, il est important d’exécuter ces évaluations contre différents modèles. Computer prend en charge au moins trois familles de modèles d’orchestration différentes : GPT, Claude Opus, et Claude Sonnet. Vous voulez exécuter votre chargement de Skill et les Skills de domaine contre ces différents orchestrateurs d’agents pour vous assurer que vous n’obtenez pas un comportement différent. Sonnet et GPT se comportent assez différemment en ce qui concerne les Skills.

Pensées finales et points à retenir

Plus vous construisez de Skills, meilleur vous deviendrez pour les construire. Si vous n’automatisez pas ou n’essayez pas de rendre plus reproductibles les tâches que vous faites au jour le jour en utilisant des Skills, commencez immédiatement.

L’acte de construire des Skills vous rend meilleur pour construire plus de Skills, mais aussi, ils sont extrêmement bons pour automatiser les processus d’affaires. Si vous pouvez décrire quelque chose que vous faites chaque semaine avant votre réunion debout, à la fin de chaque sprint, ou tout ce que vous faites en tant qu’ingénieur sur une base quotidienne, hebdomadaire, ou même trimestrielle, vous devriez écrire un Skill pour récupérer votre temps.

Pouvez-vous automatiser les post-mortems ? Pouvez-vous réviser les demandes de tirage ? Toute tâche que vous pouvez faire, vous pouvez au moins avoir le premier passage qui soit un Agent Skill. Cela vous fera gagner un temps significatif.

Cela dit, n’oubliez pas qu’un Skill n’est pas facile ou même toujours nécessaire. Moins c’est plus. Quelques autres points à retenir :

Écrivez les évaluations avant le Skill. Incluez des exemples négatifs et des chargements interdits pour les skills adjacents mais distincts.

La description est la partie difficile. « Charger lorsque... » (chaque mot coûte de l’attention).

Les pièges sont des contenus à très haute valeur. Commencez mince, grandissez à mesure que l’agent échoue.

N’oubliez pas qu’il est facile de casser d’autres Skills préexistants en ajoutant un nouveau Skill, même si vous n’y avez pas touché (méfiez-vous de l’action à distance).

Utilisez tous les outils disponibles chaque fois que vous écrivez et maintenez un Skill. Si vous voulez en savoir plus, le site web Agent Skills a plein de bons exemples, et à la fois notre référentiel interne et l’écosystème public contiennent de nombreux exemples de Skills bien conçus.

Citation

@online{perplexity2026DesigningRefiningAndMaintainingAgentSkillsAtPerplexity,
  author = {{Perplexity} and Marshall Kiely and Daisy Lee and Jerry Ma and Lauren Kolm},
  title = {{Designing, refining, and maintaining agent skills at Perplexity}},
  date = {2026-05-01},
  url = {https://www.perplexity.ai/hub/blog/designing-refining-and-maintaining-agent-skills-at-perplexity}
}