Helmor : organiser les tâches et les dépendances d’un projet
Ce projet transforme « Open-source local workbench for multi-agent software development. » en une solution open source exploitable, avec une chaîne d’outils réutilisable et des moyens d’intégration pour des cas d’usage concrets.
En bref
- De quoi s’agit-il ?
- Un projet dont le README expose le modèle de travail, l’installation et les commandes nécessaires à son évaluation.
- À qui s’adresse-t-il ?
- Ce projet convient aux équipes qui recherchent précisément les capacités décrites par helmor et acceptent de vérifier sa compatibilité avec leur environnement. Il convient moins à celles qui attendent une couverture ou un support que le README ne promet pas.
- Puis-je l’utiliser commercialement ?
- Oui. Apache-2.0 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 25 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
Orchestration locale d'agents de codage
Helmor est un poste de travail open source et local-first pour orchestrer des agents de codage. Il exécute plusieurs agents en parallèle, chacun dans son propre espace de travail git isolé, et regroupe conversation, diffs, éditeur, terminaux et actions de pull request dans une seule fenêtre. Tout est stocké localement sous ~/helmor/, donc aucun code ou état d'agent ne doit quitter la machine. Le dépôt est écrit en TypeScript, et la description du projet le qualifie de poste de travail local pour le développement logiciel multi-agents. Le README ne précise pas combien d'agents peuvent s'exécuter en même temps et ne fournit pas de benchmarks de performance.
Espaces de travail git isolés par tâche
Chaque tâche reçoit un nouveau worktree et une nouvelle branche git sous ~/helmor/workspaces/. Cette isolation empêche les agents de perturber mutuellement leurs fichiers ou l'état git. Le README explique le flux : ajouter un dépôt (soit un clone local, soit un clone depuis une URL), créer un espace de travail, inviter un agent, puis examiner et livrer. La même boucle peut se répéter en parallèle. Le README ne spécifie pas de limites sur les espaces de travail simultanés ni la gestion de l'utilisation du disque.
Amenez votre propre agent
Helmor ne fournit pas son propre modèle. Il fonctionne avec les CLI d'agents de codage existantes : Claude Code, Codex, Cursor, OpenCode et Kimi Code. Vos identifiants, clés API et fournisseurs personnalisés sont utilisés. Le README ne décrit pas comment configurer les fournisseurs personnalisés au-delà de cette déclaration, et ne documente pas les flux d'authentification. Au premier lancement, vous connectez GitHub ou GitLab et vous connectez à votre premier agent ; les CLI d'agents sont incluses, donc rien d'autre à installer.
Revue, test et livraison depuis une seule fenêtre
Le workflow de revue et de livraison est intégré dans la même fenêtre. Vous pouvez lire les diffs, utiliser un éditeur Monaco et exécuter des terminaux à côté de la conversation. D'un seul bouton, vous pouvez créer une PR ou un MR, la fusionner, corriger le CI, résoudre les conflits et travailler avec des PR empilées. GitHub et GitLab sont pris en charge. Le mode terminal exécute les invites dans le TUI natif de l'agent, et vous pouvez reprendre une discussion GUI dans le terminal. Le panneau rapide, ouvert avec Shift+Option+Space, fournit une fenêtre flottante pour démarrer un espace de travail et discuter de n'importe où. Le README ne donne pas de détails sur le fonctionnement de la détection des échecs CI ou sur la résolution des conflits.
Scriptable via CLI et MCP
Helmor est scriptable via une CLI et un serveur MCP. La CLI s'installe depuis Paramètres > Expérimental > Outil de ligne de commande et fonctionne avec la même base de données locale que l'application, même lorsqu'elle est en cours d'exécution. Les exemples de commandes incluent helmor repo add, helmor workspace new, helmor send, helmor workspace status et helmor workspace run-action. Chaque commande prend en charge --json, et les espaces de travail utilisent le raccourci nom-dépôt/nom-dossier. Le serveur MCP fonctionne sur stdio et se lance avec helmor mcp. Le README ne spécifie pas la référence complète des commandes ; il pointe vers helmor --help.
Démarrage, contribution et licence
Pour commencer, téléchargez la version pour macOS (Apple Silicon et Intel) ou Windows (x64). Le README renvoie aux versions GitHub et à docs.helmor.ai. Au premier lancement, vous connectez GitHub ou GitLab et vous connectez à votre premier agent. Pour contribuer, l'architecture, les commandes et la disposition des tests sont décrites dans AGENTS.md, et le développement local utilise bun install && bun run dev. Les canaux communautaires sont Discord et GitHub Issues. Le projet est sous licence Apache 2.0 ; l'extrait de licence accorde une licence de droit d'auteur perpétuelle, mondiale, non exclusive, gratuite et sans redevance pour reproduire, préparer des œuvres dérivées, afficher, exécuter, sous-licencier et distribuer l'œuvre. Il ne dit rien sur la garantie, le support ou la posture de sécurité.
Vérifier helmor sur un cas réel
Les commandes d’installation du README et les exemples du dépôt doivent être rejoués sur une tâche représentative, en observant les sorties et les dépendances. Cette vérification relie directement la documentation de helmor à l’usage visé : elle permet de constater les fichiers lus, la commande exécutée et le résultat observable, sans déduire une garantie que le README ne formule pas.
Conclusion éditoriale
Ce projet convient aux équipes qui recherchent précisément les capacités décrites par helmor et acceptent de vérifier sa compatibilité avec leur environnement. Il convient moins à celles qui attendent une couverture ou un support que le README ne promet pas. Avant décision, exécutez le contrôle suivant : Les commandes d’installation du README et les exemples du dépôt doivent être rejoués sur une tâche représentative, en observant les sorties et les dépendances.
Notes de la communauté