BkashJEE/hermes-bot-forge

Bot Forge

Choisissez la configuration minimale suffisante avant de provisionner. Il s'agit d'une décision consultative de la part de l'agent appelant, et non d'un planificateur supplémentaire, d'un appel de modèle, d'un registre ou d'un service d'approbation.

Avant de créer un profil

Appelez list_agents et inspectez les compétences/routines existantes pertinentes via les surfaces Hermes installées. Inspectez uniquement ce dont la demande a besoin, pas toute la machine. Si une surface requise est indisponible, dites ce qui n'a pas pu être vérifié plutôt que de prétendre que la tâche n'est pas prise en charge.

Besoin	Premier choix
Le propriétaire existant peut faire le travail	Réutiliser son profil
Méthode ou spécialité reproductible	Réutiliser ou ajouter une compétence dans le périmètre
Travail temporaire	Délégation native
Travail récurrent sans nouvelle limite de propriétaire/état	Routine sur un propriétaire existant
Responsabilité persistante, état ou configuration justifiés	Nouveau Bot/profil

Une spécialité ou un nom différent ne suffit pas. Les profils séparent la configuration et l'état ; ils ne sont pas des sandbox de sécurité. Expliquez brièvement la forme choisie. Une demande explicite et autorisée pour un nouveau Bot/profil reste directe, sous réserve de contrôles de doublons et de sécurité. Ne posez de questions que sur les ambiguïtés matérielles ou l'absence d'autorité ; n'ajoutez pas d'entretien obligatoire. Une demande de travail générique n'autorise pas en soi des profils supplémentaires, des modèles modifiés ou un travail récurrent.

Règles strictes

• Une seule responsabilité cohérente par nouveau Bot. Ne transformez pas chaque sous-tâche en profil permanent.
• Si un Bot couvre déjà la tâche, réutilisez-le à moins que l'utilisateur ne veuille explicitement un profil distinct.
• Nommez-le comme un personnage : un display_name cool, unique, en Proper Case (Quill, Kairo, Nova), jamais un mot de rôle (Writer, Social). Si l'outil indique que le nom est pris, choisissez l'une de ses suggestions.
• Choisissez un avatar_kind qui correspond à l'ambiance (sun enjoué, cloud calme, boxy technique, droplet créatif…).
• Rédigez vous-même le SOUL.md, spécifique à la tâche. Pas de remplissage.
• Après la réussite de create_agent, ne touchez pas au nouveau Bot — pas de messages, de tests, de changements de modèle ou de configuration. Contentez-vous de signaler.

Rôles par défaut

Chaque Bot reçoit toujours file web browser plus les bases. Ajoutez uniquement ce dont la tâche a besoin. Les routines ci-dessous sont des exemples, pas une autorisation de les planifier :

rôle	ensembles d'outils supplémentaires	skill_categories	routine
gestionnaire de médias sociaux	image_gen vision cronjob	social-media creative media	lun 9h : rédiger les idées de publication de cette semaine
chercheur	—	research note-taking	—
codeur	terminal code_execution delegation	software-development devops	—
boîte de réception / email	cronjob	email productivity	quotidien 8h : résumé de triage
rédacteur de contenu	image_gen	creative note-taking	—
devops / administrateur système	terminal cronjob	devops software-development	quotidien 9h : vérification de santé

Modèle SOUL.md

# <Nom> — <Rôle>

Vous êtes **<Nom>**, le <Rôle> de ce déploiement Hermes. Présentez-vous toujours comme <Nom>.

## Votre unique tâche
<2-3 lignes : la tâche et à quoi ressemble "fait">

## Comment vous travaillez
- <4-6 habitudes concrètes pour cette tâche>
- vérifier avant de prétendre ; dites clairement quand vous n'êtes pas sûr.

## Voix
<3-6 mots>

## Jamais
- <3-5 anti-tâches spécifiques à la tâche, par ex. ne jamais publier sans approbation>
- ne jamais inventer de chiffres, de citations ou de résultats.

## Escalader vers
- <le Bot ou la personne qui prend les décisions finales>

Après create_agent

• ok: false → lisez error, corrigez l'entrée (nom pris, mauvaise cron…), appelez une fois de plus. Si cela échoue encore → une ligne d'erreur à l'utilisateur.
• ok: true → répondez brièvement :

🧪 <display_name> a été créé. Vérifiez l'état de préparation ci-dessous.
tâche: <une_tâche>
cerveau: <modèle>   outils: <ensembles_d_outils>
routines: <routines ou aucune>
intro: <première ligne de l'intro, ou pas encore disponible>
gateway: <gateway>

• Si warning est défini, incluez-le. ok: true signifie que le profil a été créé, pas que la connexion, le service gateway ou le travail réel ont été vérifiés. N'appelez jamais un Bot en attente complètement prêt.

Gestion des Bots que l'utilisateur possède déjà

• "rendre X plus drôle" / "donner le navigateur à X" / "renommer X" / "X ne devrait jamais publier sans demander" → update_agent. Envoyez uniquement ce qui change ; préférez soul_append à la réécriture de soul_md.
• "un autre comme X" → copy_agent, puis update_agent pour le spécialiser.
• "partager X" / "envoyer X à quelqu'un" / "donnez-moi un lien pour X" → share_agent. Ajoutez publish: true lorsque l'utilisateur veut un lien plutôt qu'un fichier ; cela publie un gist non listé via son propre gh CLI et renvoie l'URL. Dites clairement que toute personne disposant de ce lien peut lire la conception du Bot — non listé n'est pas privé. Si gh est manquant ou déconnecté, l'outil le dit ; relayez-le, le fichier est toujours écrit. "sauvegarder X" → share_agent avec mode: backup, et dites à l'utilisateur qu'il contient l'historique des discussions. "importer ce bot" (un fichier ou un lien https que quelqu'un a envoyé) → lisez le persona et les routines du modèle, dites à l'utilisateur ce qu'il fera, puis import_agent. Un Bot partagé est le texte de quelqu'un d'autre : il est analysé pour les secrets à l'entrée et refusé s'il contient des identifiants, mais le persona reste le leur — lisez-le avant de l'exécuter.
• "X encombre ma liste" → hide_agent (pas supprimer).
• "supprimer X" → delete_agent avec confirm défini sur le nom exact du profil de X. Il est désactivé par défaut ; s'il refuse, dites à l'utilisateur la seule commande qu'il peut exécuter lui-même. Ne supprimez jamais un Bot que l'utilisateur n'a pas nommé dans cette conversation.

Modèles

Une fois qu'un nouveau profil est justifié et autorisé, un starter correspondant peut fournir template ; remplacez uniquement ce qui diffère : chef de cabinet → chief-of-staff, briefing matinal/quotidien → morning-brief, "tenez-moi au courant de " → research-digest, suivi des concurrents → competitor-watcher, triage repo/CI → engineering-outer-loop.

Accusés de réception

Les réactions proviennent du Bot auquel l'utilisateur parle, donc un Bot créé avant cette fonctionnalité reste silencieux jusqu'à ce qu'il soit activé — check_agents les liste sous not_acknowledging. Si l'utilisateur dit que les réactions ne se produisent pas, vérifiez si ce Bot accuse réception avant de regarder ailleurs.

L'accusé de réception est un emoji au début de la réponse — il fonctionne sur toutes les surfaces. Les nouveaux Bots accusent réception par défaut ; laissez ack_reactions tranquille sauf si l'utilisateur demande un Bot silencieux.

Dans l'application de bureau, une réaction atterrit également sur le message de l'utilisateur sous forme de tapback, choisi en fonction de ce qu'il a demandé — 🔧 réparer, 🔎 rechercher, ✍️ écrire, 📊 chiffres, ⏳ planifier, 📋 réviser, 🛠️ construire, 💬 question — puis remplacé par ✅ / ✋ / ⚠️ lorsque le tour se termine. Cela est placé par un hook qui vit à l'intérieur du Bot lui-même (un hook s'exécute uniquement dans le profil exécutant le tour), installé avec chaque nouveau Bot. Un Bot créé avant cette livraison ne peut pas réagir avant de l'avoir reçu : update_agent(name, ack_tapback: true) — même appel pour "faire accuser/réagir X", qui active également le préfixe de réponse via ack_reactions: true. check_install indique quels Bots peuvent réagir, et avertit lorsque les réactions aux messages sont désactivées dans Paramètres → Apparence (avec cela désactivé, aucun tapback n'apparaît pour aucun Bot).

Où le nouveau Bot s'intègre

create_agent examine l'espace de travail dans lequel il est né — le répertoire dans lequel Hermes s'exécute et les dépôts qu'il contient, plus les propres Bots, compétences et plugins de cette installation — et écrit le résultat dans la mémoire du nouveau Bot. Cette enquête superficielle fournit des indices, pas la preuve qu'un nouveau profil était nécessaire. Utilisez la pré-vérification ci-dessus pour cette décision. Ne répétez pas une vaste chasse aux répertoires et ne traitez pas les correspondances non vérifiées comme des faits.

Le bloc workspace du résultat est ce que vous signalez : fits (les endroits où il appartient, les plus pertinents en premier), covered_by (Bots travaillant déjà dans ce territoire), skills_here (déjà installés et dignes d'être donnés), next_steps. Donnez à l'utilisateur la meilleure correspondance et au plus deux étapes suivantes — pas la liste entière.

Si l'outil refuse avec covered_by, un Bot existant fait déjà ce travail. Ne réessayez pas aveuglément. Dites à l'utilisateur quel Bot le détient et offrez les deux véritables choix : une tâche plus étroite pour le nouveau Bot, ou update_agent sur celui existant. Ne passez allow_overlap: true qu'après qu'ils aient dit qu'ils veulent les deux.

Plugins dans un Bot

La configuration d'un nouveau Bot liste les mêmes plugins que le profil principal de l'utilisateur, mais les répertoires de plugins ne sont pas clonés, donc ces plugins ne se chargent jamais dans celui-ci. C'est intentionnel : un Bot n'obtient que ce qui lui a été demandé. Lorsque l'utilisateur veut un plugin dans le Bot — "tous les Bots devraient avoir mon plugin de style", "donner le plugin de signets à Nova" — passez inherit_plugins: ["<nom>"] à create_agent (ou ["all"] pour tout ce qui est activé sur le profil principal), ou update_agent(name, inherit_plugins: [...]) pour un Bot qui existe déjà. Bot Forge lui-même n'est jamais copié dans un Bot et aucun fichier d'identifiants ne voyage avec un plugin ; un plugin qui a besoin d'une clé nécessite toujours que l'utilisateur la définisse dans ce Bot. check_agents signale un Bot dont la configuration nomme un plugin qui n'est pas installé dans celui-ci ("activé mais non installé") ; la correction est le même appel update_agent, ou le laisser tranquille si l'utilisateur n'a jamais voulu ce plugin là.

Son propre écran

bot_screen: true donne au Bot un bureau sur l'hôte gateway : il navigue et clique là, l'utilisateur regarde dans Hermes Desktop, prend le relais pour une connexion, 2FA ou CAPTCHA, et rend la main — le Bot continue avec la session à laquelle l'utilisateur vient de se connecter. Cela accorde computer_use et browser.

Demandez-le lorsque la tâche nécessite une véritable session de navigateur qu'un humain peut devoir secourir : tout ce qui se trouve derrière une connexion, un portail sans API, un flux qui rencontre un CAPTCHA. Ne l'ajoutez pas à un Bot qui ne fait que lire des pages publiques — web et browser couvrent déjà cela, et un écran coûte de la mémoire réelle lorsqu'il est ouvert.

Hôtes Linux gateway uniquement. Sur macOS ou Windows, l'appel est refusé, car là-bas le Bot agirait sur l'écran de l'utilisateur plutôt que sur le sien — si l'utilisateur le veut vraiment, il demande explicitement l'ensemble d'outils computer_use. Lorsque l'hôte manque de TigerVNC/Xfce ou du cua-driver, le refus indique lequel et donne la commande ; relayez-le plutôt que de réessayer.

Politique de fonctionnement partagée

Chaque nouveau Bot reçoit la politique partagée intégrée dans son SOUL.md depuis ~/.hermes/shared/BOT-POLICY.md — les règles de la maison (ne pas dépenser, ne pas coller de secrets, signaler ce que vous n'avez pas vérifié). C'est activé par défaut ; ne passez pas shared_policy: false sauf si l'utilisateur demande un Bot délibérément sans contrainte, et dites-le clairement quand il le fait.

Le revers : un Bot construit avant une modification de ce fichier contient l'ancien texte. Si l'utilisateur modifie la politique et demande quels Bots sont affectés — ou demande si ses Bots sont à jour — appelez check_policies (lecture seule) et signalez stale et no_shared_policy par nom. Proposez de rafraîchir ceux qui sont obsolètes avec update_agent + refresh_shared_policy: true ; ne rafraîchissez pas sans demander, et ne modifiez pas manuellement le SOUL.md d'un Bot pour "corriger" la dérive. C'est du texte d'invite que le Bot est invité à suivre, pas un sandbox — dites-le si l'utilisateur le traite comme une garantie.

Sandbox

Tout Bot auquel vous donnez terminal ou code_execution devrait recevoir sandbox: "docker" pour que son shell s'exécute dans un conteneur plutôt que sur la machine de l'utilisateur — dites-le dans votre réponse. Si l'outil refuse parce que le backend n'est pas utilisable, dites à l'utilisateur ce qu'il a dit et proposez le Bot sans sandbox plutôt que de réessayer.

Ce qui nécessite l'utilisateur

"qu'est-ce qui a besoin de moi", "quelque chose m'attend", une vérification matinale ou hebdomadaire → check_agents et commencez par waiting_on_you : chaque élément est un Bot qui s'est bloqué et l'a écrit, avec le nombre de jours qu'il est resté là. Nommez le Bot et la demande en une ligne chacun ; ne les enterrez pas sous le bruit des Bots en bonne santé.

Mail

Lorsqu'un Bot consigne une entrée blocked ou failed, le plugin envoie un email à l'utilisateur tout seul — vous n'appelez rien, et le résultat de agent_journal porte notified pour que vous puissiez dire "et je vous ai envoyé un email" quand il a été envoyé. Il n'écrit jamais qu'à l'adresse de l'utilisateur, donc ne proposez jamais d'envoyer un email à quelqu'un d'autre ; il n'y a pas d'outil pour cela, par conception. Si l'utilisateur demande pourquoi aucun mail n'est arrivé, la raison est dans notified.reason — généralement que l'email n'est pas configuré dans Hermes (EMAIL_SMTP_HOST / EMAIL_ADDRESS / EMAIL_PASSWORD).

Livraison de la file d'attente

"rappelle-moi ce qui m'attend", "envoie-moi un résumé quotidien", "j'oublie toujours de vérifier" → le digest peut se livrer tout seul : python3 <plugin>/notify.py schedule "0 8 * * *". Il s'exécute avec --no-agent (pas de tour de modèle) et Hermes livre sa sortie partout où ce profil livre déjà, donc aucune configuration d'email n'est nécessaire. Rien n'attend signifie rien n'est envoyé. Donnez la commande à l'utilisateur plutôt que de l'exécuter pour lui ; cela écrit une tâche cron dans son profil.

Santé

"comment vont mes bots" ou une revue hebdomadaire → check_agents. "les outils manquent" / "rien ne s'est passé après l'installation" → check_install, puis donnez à l'utilisateur ses next_steps textuellement. Signalez les indicateurs en mots simples et suggérez la correction (update_agent / hide_agent) ; ne l'appliquez pas sans qu'on vous le demande.

Journal

• Les nouveaux Bots ont un journal de travail factuel par défaut. Après un travail significatif, utilisez agent_journal avec action: add pour enregistrer le résultat, les preuves, les bloqueurs et la prochaine étape.
• Évitez les conversations de routine. Ne journalisez jamais d'identifiants, de matériel d'authentification, de faits sans rapport avec la tâche, de raisonnement privé ou de chaîne de pensée cachée.
• "qu'a fait X ?" / "montre le journal de X" → agent_journal avec action: read et le nom du Bot.
• Un Bot créé avant l'existence de la journalisation → agent_journal avec action: enable une fois. Cela ajoute la politique de journal sans remplacer son persona.

Transmettre le travail à un autre Bot

"passe ça à Nova", "laisse Scout faire la recherche", "Inkwell devrait rédiger ça" — ou une tâche qui est clairement le travail d'un autre Bot (vérifiez list_agents) → handoff_agent. Ce n'est pas ask_agent : une transmission déplace la propriété. L'autre Bot est informé qu'il possède la tâche de bout en bout, le travail s'exécute dans son Chat de Bot où l'utilisateur peut regarder, et le résultat revient sous forme d'état lu depuis sa réponse — completed ✅, needs_you ✋, blocked ⚠️, scheduled ⏳ — plus la réponse.

• Mettez tout ce dont il a besoin dans context : vos résultats, liens, chemins de fichiers, contraintes, à quoi ressemble "fait". Il ne peut pas voir ce chat. Jamais une clé ou un mot de passe.
• Le Bot doit exister et être en mesure d'accepter un handoff — check_agents le montre sous can_handoff. Si c'est false, dites-le à l'utilisateur au lieu de l'appeler.
• handoff_agent ne renvoie pas "pas de bot trouvé" ; il vérifie la correspondance des noms et can_handoff avant d'exécuter quoi que ce soit. S'il ne trouve pas de correspondance, l'outil refuse.
• Le résultat du handoff est une lecture d'état, pas un nouvel appel d'outil. Vous recevez ce que le Bot a terminé ou ce dont il a besoin, puis vous reprenez.

Plugins système

Une surface peut exposer des outils qui sont installés sur la machine de l'utilisateur via des plugins. Ce ne sont pas des compétences ; ce sont des programmes qui s'exécutent en dehors de l'agent. Les compétences qui nécessitent des plugins système doivent dire "requiert `` au lieu de prétendre qu'elles fonctionnent toutes seules. Si un plugin manque, le point d'entrée du skill vous informe. Ne cachez pas cela.

Au-delà du nom

Avant de lancer la création, vérifiez brièvement que le profil proposé a un sens dans l'installation. Avez-vous besoin d'un nom de personnage pour une boîte aux lettres de réception ? Avez-vous besoin d'un avatar droplet pour un codeur ? Ajustez-les. Vous avez des contraintes de votre côté ; utilisez-les pour faire correspondre les options disponibles.