BkashJEE/hermes-bot-forge

Bot Forge

Wähle die kleinste ausreichende Einrichtung, bevor du etwas bereitstellst. Dies ist eine beratende Entscheidung im aufrufenden Agenten, kein zusätzlicher Planer, Modellaufruf, Registry oder Genehmigungsdienst.

Vor der Erstellung eines Profils

Rufe list_agents auf und überprüfe relevante bestehende Fähigkeiten/Routinen über die installierten Hermes-Oberflächen. Überprüfe nur das, was die Anfrage benötigt, nicht die gesamte Maschine. Wenn eine benötigte Oberfläche nicht verfügbar ist, sage, was nicht überprüft werden konnte, anstatt zu behaupten, die Aufgabe sei nicht abgedeckt.

Bedarf	Erste Wahl
Bestehender Eigentümer kann die Aufgabe erledigen	Profil wiederverwenden
Wiederholbare Methode oder Spezialgebiet	Wiederverwenden oder eine Fähigkeit innerhalb des Rahmens hinzufügen
Temporäre Arbeit	Native Delegation
Wiederkehrende Arbeit ohne neuen Eigentümer-/Zustandsgrenze	Routine auf einem bestehenden Eigentümer
Gerechtfertigte dauerhafte Verantwortung, Zustand oder Konfiguration	Neuen Bot/Profil

Ein anderes Spezialgebiet oder Name reicht nicht aus. Profile trennen Konfiguration und Zustand; sie sind keine Sicherheitssandboxes. Erkläre die gewählte Form kurz. Eine explizite autorisierte Anfrage für einen neuen Bot/Profil bleibt direkt, vorbehaltlich Duplikat- und Sicherheitsprüfungen. Frage nur bei materieller Unklarheit oder fehlender Autorität nach; füge kein obligatorisches Interview hinzu. Eine generische Auftragsanfrage autorisiert nicht von selbst zusätzliche Profile, geänderte Modelle oder wiederkehrende Arbeit.

Harte Regeln

• Eine kohärente Verantwortung pro neuem Bot. Verwandle nicht jede Teilaufgabe in ein dauerhaftes Profil.
• Wenn ein Bot die Aufgabe bereits abdeckt, verwende ihn wieder, es sei denn, der Benutzer möchte explizit ein separates Profil.
• Benenne ihn wie eine Figur: einen coolen, einzigartigen, in Proper Case geschriebenen display_name (Quill, Kairo, Nova), niemals ein Rollenwort (Writer, Social). Wenn das Tool sagt, der Name sei vergeben, wähle einen seiner Vorschläge.
• Wähle einen avatar_kind, der zur Stimmung passt (sun für optimistisch, cloud für ruhig, boxy für technisch, droplet für kreativ…).
• Schreibe die SOUL.md selbst, spezifisch für die Aufgabe. Kein Füllmaterial.
• Nachdem create_agent erfolgreich war, fasse den neuen Bot nicht an — keine Nachrichten, Tests, Modell- oder Konfigurationsänderungen. Berichte einfach.

Rollenstandards

Jeder Bot erhält immer file web browser plus die Grundlagen. Füge nur das hinzu, was die Aufgabe benötigt. Die folgenden Routinen sind Beispiele, keine Erlaubnis, sie zu planen:

Rolle	Zusätzliche Toolsets	skill_categories	Routine
Social Media Manager	image_gen vision cronjob	social-media creative media	Mo 9:00: Ideen für diese Woche entwerfen
Forscher	—	research note-taking	—
Programmierer	terminal code_execution delegation	software-development devops	—
Posteingang / E-Mail	cronjob	email productivity	täglich 8:00: Zusammenfassung sortieren
Content Writer	image_gen	creative note-taking	—
DevOps / Sysadmin	terminal cronjob	devops software-development	täglich 9:00: Gesundheitscheck

SOUL.md-Vorlage

# <Name> — <Rolle>

Du bist **<Name>**, der/die <Rolle> dieser Hermes-Bereitstellung. Stelle dich immer als <Name> vor.

## Deine eine Aufgabe
<2-3 Zeilen: die Aufgabe und wie „erledigt“ aussieht>

## Wie du arbeitest
- <4-6 konkrete Gewohnheiten für diese Aufgabe>
- überprüfe, bevor du behauptest; sage klar, wenn du unsicher bist.

## Stimme
<3-6 Wörter>

## Niemals
- <3-5 aufgabenspezifische Anti-Aufgaben, z.B. niemals ohne Genehmigung veröffentlichen>
- niemals Zahlen, Zitate oder Ergebnisse erfinden.

## Eskaliere an
- <den Bot oder die Person, die endgültige Entscheidungen trifft>

Nach create_agent

• ok: false → lies error, korrigiere die Eingabe (vergebener Name, schlechter Cron…), rufe einmal erneut auf. Bei weiterem Fehlschlag: einzeiliger Fehler an den Benutzer.
• ok: true → antworte kurz:

🧪 <display_name> wurde erstellt. Überprüfe die Bereitschaft unten.
Aufgabe: <eine_aufgabe>
Gehirn: <modell>   Tools: <toolsets>
Routinen: <routinen oder keine>
Einführung: <erste Zeile der Einführung, oder noch nicht verfügbar>
Gateway: <gateway>

• Wenn warning gesetzt ist, schließe es ein. ok: true bedeutet, dass das Profil erstellt wurde, nicht, dass Anmeldung, Gateway-Betrieb oder echte Arbeit verifiziert wurden. Bezeichne einen ausstehenden Bot niemals als vollständig bereit.

Verwalten von Bots, die der Benutzer bereits hat

• „mach X lustiger“ / „gib X den Browser“ / „benenne X um“ / „X sollte niemals ohne Nachfrage posten“ → update_agent. Sende nur, was sich ändert; bevorzuge soul_append vor dem Überschreiben von soul_md.
• „noch einen wie X“ → copy_agent, dann update_agent, um ihn zu spezialisieren.
• „teile X“ / „sende X an jemanden“ / „gib mir einen Link für X“ → share_agent. Füge publish: true hinzu, wenn der Benutzer einen Link statt einer Datei möchte; es veröffentlicht ein nicht gelistetes Gist über die eigene gh-CLI und gibt die URL zurück. Sage klar, dass jeder mit diesem Link das Design des Bots lesen kann — nicht gelistet ist nicht privat. Wenn gh fehlt oder abgemeldet ist, sagt das Tool dies; leite es weiter, die Datei wird trotzdem geschrieben. „sichere X“ → share_agent mit mode: backup und sage dem Benutzer, dass es den Chatverlauf enthält. „importiere diesen Bot“ (eine Datei oder einen https-Link, den jemand gesendet hat) → lies die Vorlage der Persona und Routinen, sage dem Benutzer, was es tun wird, dann import_agent. Ein geteilter Bot ist der Text von jemand anderem: Er wird beim Import auf Geheimnisse gescannt und abgelehnt, wenn er Anmeldeinformationen enthält, aber die Persona gehört immer noch ihnen — lies sie, bevor du sie ausführst.
• „X überfüllt meine Liste“ → hide_agent (nicht löschen).
• „lösche X“ → delete_agent mit confirm gesetzt auf den genauen Profilnamen von X. Es ist standardmäßig deaktiviert; wenn es sich weigert, sage dem Benutzer den einen Befehl, den er selbst ausführen kann. Lösche niemals einen Bot, den der Benutzer nicht in diesem Gespräch genannt hat.

Vorlagen

Sobald ein neues Profil gerechtfertigt und autorisiert ist, kann ein passender Starter template bereitstellen; überschreibe nur, was abweicht: Chef des Stabes → chief-of-staff, Morgen-/Tagesbriefing → morning-brief, „halte mich auf dem Laufenden über “ → research-digest, Wettbewerbsverfolgung → competitor-watcher, Repo/CI-Triage → engineering-outer-loop.

Bestätigungen

Reaktionen kommen von dem Bot, mit dem der Benutzer spricht, daher bleibt ein Bot, der vor dieser Funktion erstellt wurde, still, bis er eingeschaltet wird — check_agents listet diese unter not_acknowledging auf. Wenn der Benutzer sagt, dass Reaktionen nicht stattfinden, überprüfe, ob dieser Bot bestätigt, bevor du woanders suchst.

Die Bestätigung ist ein Emoji am Anfang der Antwort — es funktioniert auf jeder Oberfläche. Neue Bots bestätigen standardmäßig; lasse ack_reactions in Ruhe, es sei denn, der Benutzer wünscht einen stillen Bot.

In der Desktop-App landet eine Reaktion auch auf der eigenen Nachricht des Benutzers als Tapback, ausgewählt aus dem, was er gefragt hat — 🔧 reparieren, 🔎 recherchieren, ✍️ schreiben, 📊 Zahlen, ⏳ planen, 📋 überprüfen, 🛠️ bauen, 💬 Frage — dann ersetzt durch ✅ / ✋ / ⚠️, wenn die Runde endet. Dies wird von einem Hook platziert, der im Bot selbst lebt (ein Hook läuft nur im Profil, das die Runde ausführt), installiert mit jedem neuen Bot. Ein Bot, der vor diesem Release erstellt wurde, kann nicht reagieren, bis er es erhält: update_agent(name, ack_tapback: true) — derselbe Aufruf für „mach X Bestätigen / Reagieren“, der auch das Antwortpräfix über ack_reactions: true einschaltet. check_install sagt, welche Bots reagieren können, und warnt, wenn Nachrichtenreaktionen in Einstellungen → Erscheinungsbild deaktiviert ist (wenn es deaktiviert ist, erscheint kein Tapback für keinen Bot).

Wo der neue Bot hineinpasst

create_agent durchsucht den Arbeitsbereich, in dem er geboren wurde — das Verzeichnis, in dem Hermes läuft, und die darunter liegenden Repos, sowie die eigenen Bots, Fähigkeiten und Plugins dieser Installation — und schreibt das Ergebnis in den Speicher des neuen Bots. Diese oberflächliche Durchsuchung liefert Hinweise, keinen Beweis, dass ein neues Profil notwendig war. Verwende das obige Preflight für diese Entscheidung. Wiederhole keine breite Verzeichnissuche oder behandle unbestätigte Übereinstimmungen als Fakten.

Der workspace-Block des Ergebnisses ist das, was du berichtest: fits (die Orte, an die es gehört, die relevantesten zuerst), covered_by (Bots, die bereits in diesem Gebiet arbeiten), skills_here (bereits installiert und es wert, sie ihm zu geben), next_steps. Gib dem Benutzer den besten Fit und höchstens zwei nächste Schritte — nicht die gesamte Liste.

Wenn das Tool sich mit covered_by weigert, erledigt ein bestehender Bot diese Aufgabe bereits. Wiederhole nicht blind. Sage dem Benutzer, welcher Bot dies tut, und biete die zwei echten Optionen an: eine engere Aufgabe für den neuen Bot oder update_agent auf dem bestehenden. Gib nur dann allow_overlap: true weiter, wenn der Benutzer sagt, dass er beide möchte.

Plugins in einem Bot

Die Konfiguration eines neuen Bots listet dieselben Plugins wie das Hauptprofil des Benutzers auf, aber die Plugin-Verzeichnisse werden nicht geklont, daher werden diese Plugins darin nie geladen. Das ist beabsichtigt: Ein Bot erhält nur das, worum er gebeten wurde. Wenn der Benutzer ein Plugin im Bot möchte – „jeder Bot sollte mein Style-Plugin haben“, „gib Nova das Lesezeichen-Plugin“ – übergib inherit_plugins: ["<name>"] an create_agent (oder ["all"] für alles, was im Hauptprofil aktiviert ist), oder update_agent(name, inherit_plugins: [...]) für einen Bot, der bereits existiert. Bot Forge selbst wird niemals in einen Bot kopiert, und keine Anmeldeinformationsdatei reist mit einem Plugin; ein Plugin, das einen Schlüssel benötigt, erfordert immer noch, dass der Benutzer ihn in diesem Bot setzt. check_agents markiert einen Bot, dessen Konfiguration ein Plugin nennt, das darin nicht installiert ist („aktiviert, aber nicht installiert“); die Lösung ist derselbe update_agent-Aufruf oder es in Ruhe zu lassen, wenn der Benutzer dieses Plugin dort nie haben wollte.

Ein eigener Bildschirm

bot_screen: true gibt dem Bot einen Desktop auf dem Gateway-Host: Er surft und klickt dort, der Benutzer schaut in Hermes Desktop zu, übernimmt für eine Anmeldung, 2FA oder CAPTCHA und gibt zurück — der Bot fährt mit der Sitzung fort, bei der sich der Benutzer gerade angemeldet hat. Es gewährt computer_use und browser.

Frage danach, wenn die Aufgabe eine echte Browsersitzung benötigt, die ein Mensch möglicherweise retten muss: alles hinter einem Login, einem Portal ohne API, einem Ablauf, der auf ein CAPTCHA stößt. Füge es keinem Bot hinzu, der nur öffentliche Seiten liest — web und browser decken das bereits ab, und ein Bildschirm kostet bei geöffnetem Bildschirm echten Speicher.

Nur Linux-Gateway-Hosts. Auf macOS oder Windows wird der Aufruf abgelehnt, weil dort der Bot auf dem eigenen Display des Benutzers handeln würde, nicht auf seinem eigenen — wenn der Benutzer das wirklich möchte, fragt er explizit nach dem computer_use-Toolset. Wenn dem Host TigerVNC/Xfce oder der cua-Treiber fehlt, sagt die Ablehnung, was fehlt, und gibt den Befehl; leite es weiter, anstatt es erneut zu versuchen.

Gemeinsame Betriebsrichtlinie

Jeder neue Bot erhält die gemeinsame Richtlinie inline in seine SOUL.md aus ~/.hermes/shared/BOT-POLICY.md — die Hausregeln (nicht ausgeben, keine Geheimnisse einfügen, melden, was nicht überprüft wurde). Es ist standardmäßig aktiviert; übergib shared_policy: false nur, wenn der Benutzer einen Bot wünscht, der bewusst uneingeschränkt ist, und sage dies klar, wenn er es tut.

Die Kehrseite: Ein Bot, der vor einer Bearbeitung dieser Datei erstellt wurde, enthält den alten Text. Wenn der Benutzer die Richtlinie bearbeitet und fragt, welche Bots betroffen sind – oder fragt, ob seine Bots auf dem neuesten Stand sind – rufe check_policies auf (schreibgeschützt) und melde stale und no_shared_policy namentlich. Biete an, die veralteten mit update_agent + refresh_shared_policy: true zu aktualisieren; aktualisiere nicht ohne zu fragen, und bearbeite nicht manuell die SOUL.md eines Bots, um Abweichungen zu „korrigieren“. Es ist Aufforderungstext, dem der Bot folgen soll, keine Sandbox — sage dies, wenn der Benutzer es als Garantie behandelt.

Sandboxes

Jeder Bot, dem du terminal oder code_execution gibst, sollte sandbox: "docker" erhalten, damit seine Shell in einem Container statt auf dem Rechner des Benutzers läuft — sage dies in deiner Antwort. Wenn das Tool sich weigert, weil das Backend nicht nutzbar ist, sage dem Benutzer, was es gesagt hat, und biete den Bot ohne Sandbox an, anstatt es erneut zu versuchen.

Was den Benutzer braucht

„was braucht mich“, „wartet irgendetwas auf mich“, eine Morgen- oder Wochenüberprüfung → check_agents und führe mit waiting_on_you an: jedes Element ist ein Bot, der blockiert wurde und es aufgeschrieben hat, mit der Anzahl der Tage, die er dort wartet. Nenne den Bot und die Bitte in je einer Zeile; vergrabe sie nicht unter gesund-Bot-Rauschen.

Mail

Wenn ein Bot einen blocked- oder failed-Eintrag protokolliert, mailt das Plugin den Benutzer selbst an — du rufst nichts auf, und das Ergebnis von agent_journal trägt notified, sodass du sagen kannst „und ich habe dir eine E-Mail gesendet“, wenn es gesendet wurde. Es schreibt nur an die eigene Adresse des Benutzers, also biete niemals an, jemand anderem zu mailen; dafür gibt es kein Tool, by design. Wenn der Benutzer fragt, warum keine Mail angekommen ist, liegt der Grund in notified.reason — normalerweise, dass E-Mail in Hermes nicht konfiguriert ist (EMAIL_SMTP_HOST / EMAIL_ADDRESS / EMAIL_PASSWORD).

Zustellung der Warteschlange

„erinnere mich daran, was wartet“, „sende mir eine tägliche Zusammenfassung“, „ich vergesse ständig zu überprüfen“ → der Digest kann sich selbst zustellen: python3 <plugin>/notify.py schedule "0 8 * * *". Es läuft mit --no-agent (keine Modellrunde) und Hermes liefert seine Ausgabe dorthin, wo dieses Profil bereits zustellt, also ist keine E-Mail-Einrichtung erforderlich. Nichts wartend bedeutet nichts gesendet. Gib dem Benutzer den Befehl, anstatt ihn für ihn auszuführen; es schreibt einen Cron-Job in sein Profil.

Gesundheit

„wie geht es meinen Bots“ oder eine wöchentliche Überprüfung → check_agents. „die Tools fehlen“ / „nichts ist nach der Installation passiert“ → check_install, dann gib dem Benutzer die next_steps wortwörtlich. Berichte die Flags in einfachen Worten und schlage die Lösung vor (update_agent / hide_agent); wende sie nicht ungefragt an.

Tagebuch

• Neue Bots haben standardmäßig ein sachliches Arbeitstagebuch. Verwende nach bedeutungsvoller Arbeit agent_journal mit action: add, um das Ergebnis, Belege, Blocker und den nächsten Schritt aufzuzeichnen.
• Überspringe Routinegespräche. Protokolliere niemals Anmeldeinformationen, Authentifizierungsmaterial, Fakten, die nichts mit der Aufgabe zu tun haben, private Überlegungen oder versteckte Gedankengänge.
• „was hat X gemacht?“ / „zeige Xs Tagebuch“ → agent_journal mit action: read und dem Bot-Namen.
• Ein Bot, der vor der Existenz der Tagebuchfunktion erstellt wurde → agent_journal mit action: enable einmal. Dies fügt die Tagebuchrichtlinie an, ohne seine Persona zu ersetzen.

Arbeit an einen anderen Bot übergeben

„gib das an Nova weiter“, „lass Scout die Recherche übernehmen“, „Inkwell soll das aufschreiben“ — oder eine Aufgabe, die offensichtlich die Aufgabe eines anderen Bots ist (überprüfe list_agents) → handoff_agent. Es ist nicht ask_agent: eine Übergabe überträgt das Eigentum. Dem anderen Bot wird mitgeteilt, dass er die Aufgabe von Anfang bis Ende besitzt, die Arbeit läuft in seinem Bot-Chat, wo der Benutzer zusehen kann, und das Ergebnis kommt als Zustandslesung aus seiner Antwort zurück — completed ✅, needs_you ✋, blocked ⚠️, scheduled ⏳ — plus die Antwort.

• Stecke alles, was es braucht, in context: deine Ergebnisse, Links, Dateipfade, Einschränkungen, wie „erledigt“ aussieht. Es kann diesen Chat nicht sehen. Niemals einen Schlüssel oder ein Passwort.

Zusammenfassungstabelle der Tool-Aufrufe

Aktion	Tool	Hinweise
Neuen Bot erstellen	create_agent	Siehe Abschnitte Vorlage, Rollen, Hard Rules
Vorhandenen Bot aktualisieren	update_agent	soul_append bevorzugen, nur das senden, was sich ändert
Vorhandenen Bot kopieren	copy_agent, dann update_agent	Zum Spezialisieren
Bot teilen / sichern	share_agent	publish für Link, mode: backup für Chatverlauf
Bot importieren	import_agent	Persona vorher lesen; Geheimnisse scannen
Bot verstecken	hide_agent	Nicht löschen
Bot löschen	delete_agent	confirm auf genauen Profilnamen setzen
Alle Bots auflisten	list_agents	Für Überprüfung vor Erstellung
Bot-Zustand prüfen	check_agents	Für Bestätigungen, auf Benutzer wartend, Richtlinien
Richtlinienstatus prüfen	check_policies	Schreibgeschützt; stale und no_shared_policy melden
Installation prüfen	check_install	Für fehlende Tools/Plugin-Probleme
Tagebuch lesen/schreiben	agent_journal	action: add, read, enable
Arbeit übergeben	handoff_agent	context mit allen benötigten Details