Intégrer des Agent Skills dans Omnilude
Introduction
J’avais déjà publié un article pour présenter les Skills et les Agent Workflows.
En le relisant, je me suis dit : si les skills sont reliés au chat IA, cela pourrait devenir vraiment utile.
Cet article est un journal d’implémentation né de cette idée. Je voulais sortir les Skills d’outils comme Claude Code ou Codex, laisser un Agent les appeler à l’intérieur d’un vrai flux de travail, et voir ce que cela change. Si cela fonctionne bien, même des LLM plus modestes pourront peut-être se rapprocher un peu plus de Jarvis.
Expliquer Skill en une phrase
La définition la plus courte serait la suivante : un skill est un paquet de travail réutilisable qui apprend à un agent à traiter un certain type de tâche selon un ordre et des critères répétables.
Le guide public d’Anthropic décrit lui aussi un skill comme un dossier centré sur SKILL.md, accompagné si nécessaire de scripts, references et assets. L’important n’est pas la forme, mais le principe. Au lieu d’injecter toute la connaissance dans le prompt à chaque fois, on laisse l’agent ouvrir progressivement le corps du skill et les fichiers de référence, seulement au moment où il en a besoin.
C’est plus important qu’il n’y paraît. Les agents généralistes sont intelligents, mais ils vacillent facilement face aux tâches répétitives. Même dans le même dépôt, pour le même travail et la même demande, le ton, la structure et les points oubliés peuvent varier. Un skill sert précisément à réduire cette dérive.
Les trois principes qui me semblent les plus importants sont les suivants. D’abord, progressive disclosure, c’est-à-dire ouvrir des documents plus profonds uniquement au moment nécessaire. Ensuite, composability, où un skill n’essaie pas de tout résoudre seul, mais fonctionne avec d’autres skills. Enfin, portability, pour éviter qu’un skill soit enfermé dans un écran ou un outil particulier.
La chaîne de Skills que je construis
Dans mon dépôt local, il y a 25 skills sous .codex/skills. Ils se partagent des travaux récurrents comme la génération de documents, l’implémentation d’API, le CRUD de backoffice, le SSE, les pipelines narratifs, la traduction, la revue et les flux de commit. Sous .agents/skills, je conserve le même catalogue afin de le réutiliser facilement depuis une autre surface.
Et il y a aussi une raison pour laquelle Codex apparaît soudainement alors que je parle souvent de Claude Code. En Corée, une offre avec près de 90 % de réduction sur OpenAI Pro a récemment été proposée via Kakao. C’était une bonne occasion, donc je suis passé à Codex.
Pour revenir au sujet principal, l’axe de skills que j’utilise le plus souvent est assez clair. prd-generator prend les besoins et produit un PRD conforme à nos règles documentaires, tandis que endpoint-implement-skill fixe le schéma d’implémentation de l’Entity jusqu’au Controller. Si nécessaire, frontend-task-handover prolonge ce travail avec un document de passation pour le frontend, et branch-review revoit les régressions et les risques à la fin.
Autrement dit, j’ai tendance à voir les skills davantage comme une chaîne que comme des fonctionnalités isolées.
En pratique, CLAUDE.md précise déjà quels skills connecter en priorité selon le type de travail. Par exemple, le travail API suit la chaîne prd-generator -> endpoint-implement-skill -> frontend-task-handover, tandis que le travail backoffice suit prd-generator -> backoffice-crud-skill -> frontend-task-handover. À ce stade, un skill ressemble moins à une simple fonction d’assistance qu’à une véritable règle opératoire de travail.
Ce qui est intéressant, c’est que cet article lui-même repose sur la même philosophie. Le skill blog-post-writer que j’utilise en ce moment est conçu pour aligner d’un seul coup la catégorie du blog, le reading time, le tone, la longueur de l’excerpt, l’URL canonique, le prompt de miniature et le schéma JSON d’import. Même l’écriture n’est plus seulement une affaire d’intuition. Elle est elle aussi emballée dans un format de sortie répétable.
Skills et assistants
Une fois qu’un skill entre dans le produit, il ne peut plus être expliqué uniquement par SKILL.md. Si l’on prend comme référence le blueprint détaillé de current-weather-checker, le skill réel ressemble plutôt à une unité de runtime qui regroupe non seulement des instructions et des documents de référence, mais aussi du code exécutable, des métadonnées, une politique réseau et une stratégie de trigger. C’est pourquoi, aujourd’hui, quand je regarde un skill, je ne vois plus seulement une structure de dossiers, mais aussi ce qui est stocké, ce qui est exécuté et comment cela se connecte à l’assistant.
Vue d’ensemble de la structure du skill
En suivant le blueprint de current-weather-checker, on constate que la substance d’un skill est plus structurée qu’elle n’en a l’air. Ce que l’on voit d’abord à l’écran, c’est le nom et la description. Mais derrière cela se trouvent aussi Instructions, Scripts, References, Assets, Metadata et Runtime Policy. C’est cette composition qui permet à certains skills d’enrichir seulement le contexte, à d’autres de s’exécuter directement dans un sandbox, et à d’autres encore de contrôler en toute sécurité l’accès au réseau externe.
En résumé, un skill n’est pas seulement un fichier de prompt. Il se rapproche davantage d’un objet de définition qui rassemble texte descriptif + ressources d’exécution + politique d’exploitation. Dans le cas des script skills en particulier, des règles d’exécution comme networkPolicy et allowedDomains déterminent les permissions réelles. Lire seulement body ne suffit pas à comprendre ce que le skill peut réellement faire. C’est précisément pour cela que les blueprints sont utiles : ils restaurent d’un coup la structure cachée derrière l’écran.
Vue d’ensemble de l’intégration avec l’assistant
À l’étape suivante, l’important n’est pas tant le skill lui-même que qui possède ce skill, dans quelles conditions il est invoqué, et par quel chemin il s’exécute après avoir été sélectionné. Dans la structure d’Omnilude, le skill n’est pas attaché de façon lâche à un agent. Il est mappé à un assistant, et l’orchestrator lit ce mapping ainsi que les informations de trigger pour décider du chemin réel d’exécution. Les skills exécutables vont vers la partie sandbox, tandis que le matériel context-only va vers le prompt de la réponse finale.
Environnement d’exécution isolé
Les scripts des skills exécutables ne s’exécutent pas directement dans le processus de l’assistant. AssistantSkillScriptExecutor délègue l’exécution à un sandbox pod séparé via sandbox-bridge, et le script tourne dans cet environnement isolé, en recevant stdin JSON comme entrée et en renvoyant stdout JSON comme sortie. Cette structure sépare le cœur de l’assistant du code d’exécution, tout en permettant de contrôler la portée des accès externes via networkPolicy et allowedDomains.
En termes simples, l’assistant décide quoi exécuter, et le sandbox est l’endroit où cette exécution est traitée de manière sûre. Plus le nombre de skills augmente, plus cette séparation devient importante. Elle permet d’isoler les échecs, de répartir plus finement les permissions réseau et de retracer plus facilement quel script a été exécuté sous quelle politique.
Vu sous cet angle, un skill ressemble davantage à un module que l’assistant sélectionne et exécute lorsque nécessaire qu’à un simple document auxiliaire. C’est pourquoi, à mesure que les attached skills deviennent plus puissants, ce qui compte n’est plus la longueur de l’explication, mais la clarté avec laquelle mapping, trigger, execution et observability sont conçus. Au final, un bon skill n’est pas seulement un document bien écrit. C’est une surface d’exécution structurée qu’un assistant peut invoquer de manière fiable.
Conclusion
Si l’article sur le workflow du 18 février 2026 expliquait comment circule un agent, alors cet article parle de la manière de fixer ce flux dans une structure stable à travers les skills.
Un skill n’est pas une option magique. Mais il reste un outil puissant pour regrouper en une seule unité le travail répétitif, les standards de travail, le contexte de référence, le format de sortie et les chemins d’exécution, pour les individus comme pour les équipes.
La prochaine fois, j’aimerais apporter des cas plus concrets, du point de vue de l’implémentation comme de l’exploitation, pour montrer comment la combinaison des skills et des assistants peut améliorer l’expérience réelle des agents.