Skills et ressources

Les ressources sont les skills, commandes slash et sous-agents que vous enregistrez dans Neuronz.ai. Vous enregistrez une ressource une seule fois, et le plugin l'ajoute à chaque session des profils qui y ont accès. Le statut d'une ressource (active, brouillon ou archivée) détermine si elle est distribuée : seules les ressources actives le sont.

Fonctionnement

Trois types. Une ressource enregistrée est de l'un de trois types, et son type détermine dans quel dossier de votre harnais d'agent (harness), c'est-à-dire l'agent de code que vous utilisez (Claude Code ou Oh-My-Pi), elle est placée :

• Skill — une capacité que l'agent utilise de lui-même quand le travail correspond à sa description.
• Commande — une tâche qu'une personne lance par son nom. Claude Code et Oh-My-Pi la proposent sous forme de commande /slash.
• Agent — la définition d'un sous-agent spécialisé.

Placées à chaque début de session. Au début de la session, le plugin prend les ressources actives du profil et place chacune dans le dossier correspondant du harnais, en les mettant à jour à chaque session pour que vous ayez toujours la version actuelle. Il ne touche qu'aux ressources qu'il a lui-même placées : vos skills et commandes personnels ne sont jamais modifiés. Sur les harnais capables de recharger les skills en cours de session, les skills sont utilisables dès la session en cours. Les autres ressources apparaissent à la session suivante.

Placées dans le dépôt où vous êtes. Les ressources d'un profil appartiennent à ce profil : elles sont donc placées dans le dépôt d'où vient le profil de la session, dans le dossier que le harnais y lit, et non dans un dossier commun à toutes les sessions de la machine. Les ressources d'un profil n'apparaissent donc jamais dans les sessions d'un autre profil. Les fichiers des ressources restent en dehors du dépôt ; seuls des liens vers eux y sont placés, et ces liens sont listés dans le .git/info/exclude du dépôt lui-même : ils n'apparaissent jamais dans git status et ne peuvent jamais être commités par erreur. Chaque agent y a ses propres entrées, si bien que deux agents qui travaillent dans le même dépôt, ou dans deux worktrees de ce dépôt, conservent chacun les leurs. Les anciens liens laissés dans les dossiers communs à toute la machine sont nettoyés à la session suivante. Une exception : si vous démarrez une session Claude Code dans votre dossier personnel, son dossier de projet et le dossier commun à la machine sont le même (~/.claude), si bien que les ressources de ce profil peuvent aussi apparaître dans des sessions Claude Code ouvertes dans d'autres dossiers, jusqu'à ce qu'une session ultérieure les nettoie.

Ce nettoyage ne se limite pas à l'agent que vous lancez. Chaque session note où elle a placé des ressources : un ensemble laissé dans un dossier commun par un agent que vous n'utilisez plus, ou par un profil que vous n'utilisez plus, est supprimé par la prochaine session qui le trouve. Vous n'avez pas besoin de relancer cet agent pour vous en débarrasser. Seuls les dossiers communs sont nettoyés de cette façon. Le contenu d'un autre dépôt n'est pas touché.

Les ressources supprimées sont nettoyées au même passage : la copie enregistrée de tout ce que vous avez renommé, cessé de partager ou supprimé disparaît avec son lien, si bien que ce qui se trouve sur le disque correspond toujours à votre ensemble actif. Cela vaut aussi à l'intérieur d'un skill : un fichier que vous retirez d'un skill est supprimé de la copie que lit l'agent. Une session qui n'a pas pu joindre Neuronz.ai ne supprime rien et conserve toutes les copies qu'elle a déjà.

Resynchroniser sans redémarrer. Les ressources sont placées une seule fois, au démarrage de la session : une session peut donc se retrouver avec un ensemble que vous avez déjà modifié, parce que vous avez changé de profil en cours de session, modifié une ressource dans le tableau de bord, ou qu'une session dans un autre dépôt a nettoyé un dossier commun que celle-ci utilisait. /neuronzai:reload-assets refait ce travail immédiatement : la commande télécharge à nouveau les ressources du profil (sans tenir compte du cache, si bien que les fichiers abîmés à la main sont réécrits), met à jour les liens et nettoie les ensembles des autres profils, exactement comme un démarrage de session.

Ce que la session voit ensuite dépend du harnais, et la commande vous indique dans quel cas vous êtes. Claude Code relit les skills immédiatement ; ses commandes et sous-agents sont lus au démarrage et nécessitent une nouvelle session. Sur Oh-My-Pi, lancez ensuite /reload-plugins : la commande relit les skills, les commandes et les sous-agents sans toucher à votre conversation. /neuronzai:switch-profile place de lui-même les ressources du nouveau profil et vous informe de la même façon : sur Claude Code, son message vous invite à lancer /neuronzai:reload-assets pour charger les nouveaux skills sans redémarrer.

Chaque harnais lit les ressources dans son propre dossier à l'intérieur du dépôt : Claude Code dans .claude, Oh-My-Pi dans .omp. Les deux prennent en charge les trois types de ressources. Le tableau complet se trouve dans le comparatif des outils (en anglais).

Un bloc de frontmatter doit être valide. L'enregistrement d'une ressource est refusé si son bloc --- n'est pas un YAML valide, et la ligne en cause est indiquée. Un harnais strict comme Oh-My-Pi ignore tout le bloc quand il n'est pas valide : la description et l'indication d'argument seraient alors absentes. Un contenu sans aucun frontmatter reste parfaitement valide.

La construction qui pose le plus souvent problème est une indication d'argument écrite sous forme de plusieurs groupes entre crochets, argument-hint: [pr-url] [--confirm], que YAML lit comme une liste complète suivie du début d'une autre. Mettez-la entre guillemets (argument-hint: "[pr-url] [--confirm]") et chaque harnais lira la même chaîne.

Rapide quand rien n'a changé, sûr quand quelque chose tourne mal. La synchronisation est mise en cache : une session où rien n'a changé se limite à une vérification rapide plutôt qu'à un téléchargement complet. Le cache suit le profil qu'utilise réellement la session, si bien que changer le profil auquel appartient un dossier déclenche toujours une resynchronisation. Si Neuronz.ai est injoignable, vous gardez les ressources que vous avez déjà et vous continuez à travailler. Si Neuronz.ai répond mais n'accepte plus votre connexion (parce qu'elle a expiré ou a été révoquée, par exemple), les ressources placées par Neuronz.ai sont retirées jusqu'à ce que vous vous reconnectiez avec /neuronzai:login. Vos propres fichiers ne sont jamais touchés.

Quand quelque chose tourne mal, le message précise quoi : Neuronz.ai était totalement injoignable, il a été joint et a répondu par une erreur, ou il a renvoyé une liste de ressources illisible.

Les exécutions sont enregistrées pour vous. Chaque fois qu'un skill ou une commande enregistré s'exécute et fait un vrai travail, cette exécution est automatiquement enregistrée comme un run : vous disposez ainsi d'un historique des capacités réellement utilisées, et de leurs dates.

Où une ressource est disponible : la portée

Chaque ressource a une portée qui détermine les sessions qui y ont accès. Il y a trois possibilités :

• Le profil actuel (par défaut). Créez une ressource sans rien préciser sur sa portée et elle appartient au profil dans lequel vous l'avez créée : seules les sessions de ce profil la voient. C'est le bon choix par défaut pour une capacité qui n'a de sens que pour un projet.
• Globale : disponible partout. Marquez une ressource comme globale et elle est placée dans tous les profils de votre espace de travail. Utilisez-la pour un skill ou une commande que vous voulez dans tous vos projets.
• Partagée entre certains profils. Donnez à une ressource une liste explicite de profils et elle devient disponible dans exactement ceux-là. C'est une seule ressource, pas des copies : la modifier met à jour en même temps tous les profils qui la partagent, si bien que les versions ne peuvent jamais diverger comme le font des fichiers copiés à la main.

Remplacer une ressource globale par la version d'un profil

Comme une ressource globale va partout, vous voudrez parfois qu'un projet fasse les choses à sa manière. La règle est simple : la ressource propre à un profil l'emporte sur une ressource globale du même nom. Supposons qu'il existe un skill global deploy et qu'un profil ait aussi son propre skill deploy. Les sessions de ce profil reçoivent la version du profil, tandis que partout ailleurs la version globale s'applique toujours.

Vous ne pouvez pas créer de véritable conflit : deux ressources globales du même type et du même nom, ou deux ressources propres à des profils qui partagent à la fois un profil et un nom, sont refusées. Une ressource globale accompagnée de la version propre à un profil est toujours autorisée.

Utilisation

Créez et gérez les ressources depuis votre agent via MCP avec add_asset, get_asset, list_assets, update_asset et delete_asset, en passant kind parmi skill, command ou agent. Pour définir la portée, passez global: true pour rendre une ressource disponible partout, ou une liste profiles pour la partager entre certains profils ; sans l'un ni l'autre, elle reste dans le profil actuel. Vous pouvez ensuite changer la portée d'une ressource de la même façon avec update_asset. Vous pouvez aussi tout parcourir et tout modifier sur la page Assets du tableau de bord, et y définir le statut de chaque ressource (seules les ressources actives sont distribuées).

Un déroulement typique : vous décrivez une tâche réutilisable, par exemple une commande qui vérifie un canal d'alertes et consigne tout ce qui n'est pas encore suivi, et votre agent rédige la ressource complète puis appelle add_asset avec kind: "command". Elle est enregistrée comme active et placée dans le profil au prochain démarrage de session. Dès lors, vous pouvez lancer /votre-commande dans Claude Code ou Oh-My-Pi. Rédiger une ressource et l'exécuter se font dans des sessions distinctes : vous la rédigez maintenant, et une session ultérieure l'exécute.

Voir aussi

• Briefing de début de session — le reste de ce qui arrive avec une session.
• Profils — la portée à travers laquelle les ressources sont partagées.