Lobster : des workflows typés et locaux pour OpenClaw
Lobster est un shell de workflow natif d'Openclaw : un moteur de macro typé, d'abord local, qui transforme les compétences/outils en pipelines composables et en automatisations sécurisées, et permet à Openclaw d'appeler ces workflows en une seule étape.
En bref
- De quoi s’agit-il ?
- Lobster est un shell de workflows natif pour OpenClaw qui transforme des compétences et outils en pipelines typés, tâches et étapes d'approbation.
- À qui s’adresse-t-il ?
- Lobster est publié sous licence MIT, et la prochaine étape indiquée dans le README est de le distribuer comme outil de plugin optionnel pour OpenClaw. Suivez la commande lobster indiquée dans README.md et inspectez le fichier de workflow ou de recette utilisé, en vérifiant les étapes et les approbations affichées.
- Puis-je l’utiliser commercialement ?
- Oui. MIT est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 2 jours.
- En quel langage est-il écrit ?
- Principalement TypeScript, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 14 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Pipelines typés et fichiers de workflow
Lobster est un shell de workflows natif pour OpenClaw. Il définit les workflows comme des pipelines typés qui opèrent sur du JSON plutôt que sur des flux texte, et inclut des tâches et des étapes d'approbation. Un agent comme OpenClaw peut invoquer un workflow Lobster en une seule étape, ce qui, selon le README, économise des jetons et améliore le déterminisme et la reprenabilité par rapport à une replanification de chaque étape. Le README montre deux exemples d'appel du workflow github.pr.monitor, l'un avec une PR inchangée, l'autre avec une PR fusionnée ; les deux renvoient un JSON structuré avec un prSnapshot et un résumé des champs modifiés.
Objectifs de conception
Le README liste quatre objectifs. Les pipelines doivent être typés, c'est-à-dire utiliser des objets et tableaux plutôt que des pipes texte. L'exécution doit être locale. Lobster ne doit pas introduire une nouvelle surface d'authentification, donc ne doit pas posséder de jetons OAuth ou d'identifiants similaires. Et les workflows doivent être des macros composables qu'OpenClaw ou n'importe quel agent peut invoquer en une étape pour économiser des jetons. Ces objectifs expliquent pourquoi le projet se décrit comme un shell de workflows plutôt qu'un service.
Commandes de démarrage rapide
La section de démarrage rapide liste pnpm install, pnpm test, pnpm lint, node ./bin/lobster.js --help, node ./bin/lobster.js doctor, et une commande exemple qui envoie du JSON à travers exec, where et json. La commande de test exécute d'abord tsc puis lance les tests contre dist/ ; bin/lobster.js préfère le point d'entrée compilé dans dist/ lorsqu'il existe. Le README ne liste pas de commande d'installation npm, donc l'installation via d'autres gestionnaires de paquets que pnpm reste à vérifier.
Structure des fichiers de workflow
Les fichiers de workflow Lobster se lisent comme de petits scripts. Un fichier peut contenir des étapes run ou command pour du travail shell et CLI, des étapes pipeline pour des étages natifs Lobster comme llm.invoke, des étapes approval comme barrières strictes entre les étapes, et des entrées stdin comme $step.stdout ou $step.json pour faire circuler les données. Le README note que run et command sont équivalents, run étant préféré pour les nouveaux fichiers, et que les étapes pipeline partagent le même modèle args, env et results que les étapes shell. Le workflow exemple jacket-advice utilise une commande météo, une étape d'approbation et une étape pipeline llm.invoke, avec une condition when liée au résultat de l'approbation.
Contraintes d'identité pour les approbations
Les étapes d'approbation peuvent imposer des contraintes d'identité. Le fichier de workflow supporte required_approver (ou requiredApprover) pour exiger un identifiant d'approbateur exact, require_different_approver (ou requireDifferentApprover) pour exiger que l'approbateur diffère de l'initiateur, et initiated_by (ou initiatedBy) pour définir l'identifiant de l'initiateur. À l'exécution, LOBSTER_APPROVAL_INITIATED_BY peut fournir un identifiant d'initiateur par défaut, et LOBSTER_APPROVAL_APPROVED_BY est utilisé lors de la reprise ou de l'approbation pour les vérifications d'identité. Le README ne décrit pas comment ces valeurs sont validées, seulement qu'elles sont utilisées pour des vérifications.
Demandes d'entrée suspendues et reprise
Les commandes pipeline peuvent appeler ctx.requestInput avec prompt, responseSchema, defaults, subject et suspendedState pour faire une pause en mode outil, dans les workflows ou dans le SDK, et reprendre la même commande après une réponse structurée. Les jetons de reprise CLI et outil ne stockent qu'une clé d'état, et l'état persisté valide les métadonnées de la demande suspendue avant de renvoyer la réponse soumise. Les reprises de même commande dans le SDK stockent le cadre de commande dans le répertoire d'état du SDK configuré. Les commandes sont réexécutées à la reprise, elles doivent donc être idempotentes jusqu'à ce que requestInput retourne. Les entrées de commande basées sur des tableaux sont instantanées avec des bornes pour la relecture ; les entrées de flux paresseux ne sont pas tamponnées et nécessitent un suspendedState JSON compact fourni par la commande.
Conclusion éditoriale
Lobster est publié sous licence MIT, et la prochaine étape indiquée dans le README est de le distribuer comme outil de plugin optionnel pour OpenClaw. Suivez la commande lobster indiquée dans README.md et inspectez le fichier de workflow ou de recette utilisé, en vérifiant les étapes et les approbations affichées.
Notes de la communauté