Omni : chercher l’interface qui rend les skills lisibles

Avec plusieurs projets et plusieurs agents, je veux pouvoir répondre à une question simple : qui utilise quoi ? C’est pour ça que je construis Omni.

J’ai accumulé des fichiers Markdown, des spécifications et des consignes pour aider mes agents. À force d’en ajouter, je dois aussi faire le tri dans ce contexte. Je préfère maintenant garder mes méthodes répétitives dans des skills : des recettes que l’agent peut découvrir grâce à leur description, puis consulter quand il en a besoin.

Mais dès que chaque agent peut créer sa recette, il faut organiser ce qui se passe autour. Est-ce qu’elle existe déjà ? Suit-elle les bonnes conventions ? Une version externe a-t-elle changé ? Et si j’améliore une copie dans un projet, que doivent devenir les autres ?

Retrouver ce que mes agents utilisent

Sans vue d’ensemble, je finis par travailler à l’aveugle. Une même skill peut être installée pour Claude Code et Codex, à l’échelle de l’utilisateur ou d’un projet. Deux fichiers portant le même nom peuvent aussi contenir des instructions différentes.

J’ai longtemps cherché comment rendre ces relations compréhensibles. Dans Omni, le projet est devenu le point de départ. Ses ressources sont regroupées selon leur provenance : ma marketplace, les sources externes ou le projet lui-même. Avant même d’ouvrir une skill, je retrouve un contexte.

Le canevas devait servir la navigation

J’ai essayé plusieurs manières de répartir ces informations. L’une des difficultés était de garder une interface cohérente lorsque la navigation passait d’un écran à un autre. Le canevas pouvait donner une bonne vue d’ensemble, puis disparaître au moment d’agir ou de lire.

J’ai donc choisi de garder le canevas comme espace de travail et d’ouvrir les détails dans des fiches latérales. Le lecteur voit le contenu sans perdre complètement les ressources qui l’entourent. Le chemin en haut de la fenêtre permet de remonter vers le projet.

Le déplacement et le zoom répondent à une autre contrainte : tous les projets n’ont pas la même quantité de ressources. Une disposition claire avec quelques nœuds doit aussi rester navigable quand le contenu se densifie.

Une skill devait rester une skill

Une première représentation pouvait montrer deux fois une même skill, une fois pour chaque agent. Elle reflétait les copies présentes sur le disque, mais elle compliquait la lecture. Deux nœuds portant le même nom n’expliquaient pas immédiatement s’il s’agissait du même outil ou de deux outils différents.

J’ai gardé un seul nœud par skill, avec des pastilles pour indiquer les agents qui l’utilisent.

Le nom permet de reconnaître la ressource. Les pastilles donnent l’information d’installation. Et les états particuliers, comme une mise à jour disponible, apparaissent au même endroit. Chaque élément a ainsi un rôle distinct dans la lecture.

Le détail devait répondre à des questions précises

Quand j’ouvre une skill, je veux savoir ce qu’elle fait, d’où elle vient et où elle est utilisée. C’est l’ordre retenu dans la fiche. Le contenu arrive ensuite, dans le même panneau.

Ce travail a aussi porté sur les mots. Une action comme désactiver une skill n’a pas le même sens que la supprimer. Les noms des actions et les explications doivent permettre de comprendre cette différence avant de cliquer.

Garder la main quand les skills évoluent

Retrouver une skill ne règle pas tout. Avant d’en créer une, je veux vérifier les doublons, les règles de sécurité et les conventions d’écriture, dont l’anglais. Quand elle vient d’ailleurs, je veux garder sa provenance et suivre ses mises à jour. Et lorsqu’une copie change dans un projet, je veux comprendre ce qui peut revenir à la source commune, en conservant les adaptations qui ont une raison d’exister.

C’est ce cycle que je cherche à rendre lisible dans Omni. Le canevas doit aider à explorer, les fiches à comprendre, et l’aperçu d’un changement à décider. Une propagation entre projets ne doit pas devenir une nouvelle opération qu’on lance à l’aveugle.

Une interface qu’on a envie d’explorer

J’ai beaucoup itéré sur ces parcours parce que je voulais aussi prendre plaisir à les utiliser. Se déplacer dans le canevas, ouvrir une fiche, revenir au projet : ces gestes doivent aider à comprendre les liens. Le côté presque ludique m’intéresse quand il rend cette exploration plus facile.

J’utilise des agents pour développer Omni, mais ces choix restent mon travail. Une implémentation peut être correcte et produire un écran difficile à comprendre. Faire tourner l’application, essayer les parcours et reprendre la représentation font partie de la conception.

Omni est encore en développement. Ces captures montrent le parcours de lecture actuel ; les parcours complets de mise à jour des copies restent en cours de travail. Je continue d’éprouver les décisions d’interface sur mes projets, avec une question simple : est-ce que je comprends ce que je m’apprête à changer ?