Les Claws ClawHub

Partager un seul skill est facile, partager un agent entier ne l’est pas. Un Claw est la réponse de ClawHub à cet écart, un paquet versionné qui décrit un agent OpenClaw complet ainsi que les ressources réutilisables dont il a besoin. Le format est explicitement expérimental, et la frontière entre ce que fait le registre et ce que fait votre propre installation est tracée avec un soin inhabituel. Lire cette frontière en premier rend le reste du format évident.

Ce que contient un Claw

• Un Claw publiable est un répertoire de paquet ordinaire dont le fichier package.json pointe vers un fichier de manifeste, et ce manifeste s’ouvre sur un en-tête YAML groupé tandis que son corps Markdown non vide est le prompt portable qu’OpenClaw applique, octet pour octet en UTF-8, comme fichier SOUL.md géré du nouvel agent.
• L’en-tête groupe l’identité de l’agent, les fichiers d’espace de travail à déposer, les skills et les plugins à installer avec une version exacte chacun, les serveurs MCP et les tâches planifiées, et chaque source d’espace de travail doit désigner un fichier livré dans le même paquet.
• Les manifestes JSON restent compatibles mais ne portent pas de corps Markdown, donc un prompt équivalent doit être déclaré explicitement comme fichier d’amorçage de l’espace de travail, et combiner un corps Markdown non vide avec une destination SOUL.md explicite est rejeté comme double source ambiguë.
• Les ressources telles que schémas, modèles, exemples et images sont des fichiers d’espace de travail ordinaires et portables, à placer sous des dossiers comme assets, schemas ou templates et à déclarer dans la liste de l’espace de travail, tandis que les noms et versions de paquets doivent correspondre au fichier package.json, les versions de dépendances doivent être exactes et les valeurs d’environnement MCP doivent rester des références de variables non résolues.

ClawHub stocke et analyse le paquet ; OpenClaw garde la main sur la prévisualisation locale, le consentement, l’application, la mise à jour et la suppression.

Construire, vérifier, publier

Le chemin de publication d’un Claw est volontairement étroit. Vous validez le projet source et construisez un artefact déterministe avec OpenClaw, vous prévisualisez cet artefact exact sans l’envoyer, puis vous le publiez par le flux de paquets authentifié existant. La publication expérimentale de Claws n’accepte qu’une archive déjà construite, jamais un dossier source et jamais une copie de dépôt GitHub. L’outil en ligne de commande transmet l’empreinte locale de l’artefact avec la requête, ClawHub la vérifie face aux octets reçus avant publication, et la même empreinte revient dans la réponse en attente comme dans la réponse finale. La publication rejette un chemin de manifeste manquant, invalide ou sortant du paquet, un dossier source à la place d’une archive construite, une identité ou une version de paquet divergente, une empreinte attendue manquante ou non concordante, un en-tête ou des champs de manifeste mal formés, un corps non vide combiné à une destination SOUL.md explicite, des fichiers sources d’espace de travail manquants ou des collisions de chemins portables, des instructions d’amorçage ou des profils de harnais invalides, le pointeur de configuration retiré, des versions de skills ou de plugins flottantes et des identifiants MCP déjà résolus. Les paquets acceptés poursuivent ensuite dans la chaîne existante de propriété, de modération, d’analyse statique, de publication et de stockage des artefacts. La version stockée conserve l’artefact exact ainsi qu’un résumé non sensible pour la recherche et les pages de détail ultérieures. Les téléchargements renvoient ces mêmes octets et cette même empreinte, et le manifeste complet n’est jamais dupliqué dans le stockage sous-jacent.

Deux verrous indépendants

• La publication de Claws est expérimentale et le déploiement ClawHub doit activer son réglage expérimental dédié aux Claws, faute de quoi le serveur rejette simplement la publication.
• Ce verrou côté registre est indépendant du verrou côté consommateur d’OpenClaw, donc l’hébergement n’active ni la prévisualisation locale ni l’installation, et activer l’outil OpenClaw n’active ni la publication ClawHub ni la découverte hébergée.
• Tant que le verrou côté registre est fermé, les filtres explicites de famille Claw sont rejetés, les listes et les recherches non filtrées omettent les Claws, la lecture d’un Claw nommé renvoie une absence, et la route du flux hébergé renvoie un 404 sans figurer dans le document de découverte du registre.

Un Claw est moins un nouveau type de code qu’une façon d’épingler les éléments qu’un agent utilise déjà, ce qui explique que sa liste de paquets nomme les skills et les plugins avec une version exacte plutôt qu’une plage. Pour les éléments qu’il réutilise, voyez Les skills OpenClaw et La place de marché ClawHub.

Pourquoi la frontière est là

La séparation entre le registre et l’installation locale est toute la conception. ClawHub stocke, vérifie et analyse l’artefact, tandis que la prévisualisation, le consentement, l’application, la mise à jour et la suppression restent du côté d’OpenClaw, et la documentation dit clairement que le registre ne contourne pas cette frontière de prévisualisation et de consentement. Le même réflexe façonne ce que renvoie l’API publique, puisque les listes et les recherches utilisent les champs de résumé habituels tandis que les réponses de détail peuvent ajouter un résumé de manifeste borné indiquant l’identité de l’agent, le nombre de ressources portables, le nombre de profils de harnais, le nombre de profils OpenClaw et le nombre d’extensions natives, sans exposer le contenu du manifeste ni celui des profils. Les manifestes complets restent dans l’artefact exact et ne sont jamais projetés dans les réponses publiques de version. Les profils de harnais suivent la même règle dans l’autre sens, car ClawHub valide la forme commune et contrôle le profil OpenClaw face au contrat consommateur livré, mais n’interprète pas les profils étrangers, et chaque harnais ne découvre que le sien. La présence d’instructions d’amorçage figure dans le résumé de catalogue borné, jamais leur contenu. Pour les deux moitiés de part et d’autre de cette frontière, lisez ensuite Les plugins OpenClaw et Le bac à sable des agents.

Sur Diali

Diali propose OpenClaw hébergé, où chaque client dispose de son propre assistant et où la configuration d’exécution est générée depuis le tableau de bord et remplacée à chaque publication. Les canaux se connectent depuis ce tableau de bord, et l’état de l’agent vit sur un volume persistant, avec des instantanés quotidiens et une restauration en un clic grâce à l’option Sauvegardes (incluse avec Max). Voyez OpenClaw hébergé sur Diali pour l’installation hébergée et Les tarifs Diali pour les formules.

• Un Claw épingle un agent entier, pas un seul skill.
• La publication accepte une archive construite, vérifiée par empreinte.
• Deux verrous : un sur le registre, un sur votre installation.