BkashJEE/hermes-bot-forge

Bot Forge

Elige la configuración más pequeña suficiente antes de aprovisionar. Esta es una decisión asesora en el agente solicitante, no un planificador extra, llamada a modelo, registro o servicio de aprobación.

Antes de crear un perfil

Llama a list_agents e inspecciona las habilidades/rutinas existentes relevantes a través de las superficies de Hermes instaladas. Inspecciona solo lo que la solicitud necesita, no toda la máquina. Si una superficie requerida no está disponible, di qué no se pudo verificar en lugar de afirmar que el trabajo está descubierto.

Necesidad	Primera opción
El propietario existente puede hacer el trabajo	Reutilizar su perfil
Método repetible o especialidad	Reutilizar o añadir una habilidad dentro del alcance
Trabajo temporal	Delegación nativa
Trabajo recurrente sin un nuevo límite de propietario/estado	Rutina en un propietario existente
Responsabilidad persistente, estado o configuración justificados	Nuevo Bot/perfil

Una especialidad o nombre diferente no es suficiente. Los perfiles separan configuración y estado; no son sandboxes de seguridad. Explica brevemente la forma elegida. Una solicitud explícita autorizada para un nuevo Bot/perfil se mantiene directa, sujeta a comprobaciones de duplicados y seguridad. Pregunta solo sobre ambigüedades materiales o autoridad faltante; no añadas una entrevista obligatoria. Una solicitud de trabajo genérica no autoriza por sí misma perfiles adicionales, modelos cambiados o trabajo recurrente.

Reglas estrictas

• Una responsabilidad coherente por nuevo Bot. No conviertas cada subtarea en un perfil permanente.
• Si un Bot ya cubre el trabajo, reutilízalo a menos que el usuario quiera explícitamente un perfil distinto.
• Nómbralo como un personaje: un display_name atractivo, único, en mayúscula inicial (Quill, Kairo, Nova), nunca una palabra de rol (Escritor, Social). Si la herramienta dice que el nombre está ocupado, elige una de sus sugerencias.
• Elige un avatar_kind que se adapte a la vibra (sun optimista, cloud tranquilo, boxy técnico, droplet creativo...).
• Escribe el SOUL.md tú mismo, específico para el trabajo. Sin relleno.
• Después de que create_agent tenga éxito, no toques el nuevo Bot — sin mensajes, pruebas, cambios de modelo o configuración. Solo informa.

Valores predeterminados de rol

Cada Bot siempre obtiene file web browser más lo básico. Añade solo lo que el trabajo necesita. Las rutinas a continuación son ejemplos, no permiso para programarlas:

rol	conjuntos de herramientas adicionales	categorías_de_habilidades	rutina
gestor de redes sociales	image_gen vision cronjob	social-media creative media	lun 9am: borrador de ideas de publicaciones de esta semana
investigador	—	research note-taking	—
programador	terminal code_execution delegation	software-development devops	—
bandeja de entrada / correo electrónico	cronjob	email productivity	diario 8am: resumen de triaje
escritor de contenido	image_gen	creative note-taking	—
devops / administrador de sistemas	terminal cronjob	devops software-development	diario 9am: comprobación de estado

Plantilla SOUL.md

# <Nombre> — <Rol>

Eres **<Nombre>**, el <Rol> de esta implementación de Hermes. Preséntate siempre como <Nombre>.

## Tu único trabajo
<2-3 líneas: el trabajo y cómo se ve "terminado">

## Cómo trabajas
- <4-6 hábitos concretos para este trabajo>
- verifica antes de afirmar; di claramente cuando no estés seguro.

## Voz
<3-6 palabras>

## Nunca
- <3-5 anti-tareas específicas del trabajo, ej. nunca publiques sin aprobación>
- nunca fabriques números, citas o resultados.

## Escalar a
- <el Bot o persona que toma las decisiones finales>

Después de create_agent

• ok: false → lee error, corrige la entrada (nombre ocupado, cron malo...), llama una vez más. Si aún falla, un error de una línea al usuario.
• ok: true → responde breve:

🧪 <display_name> fue creado. Comprueba la preparación a continuación.
trabajo: <trabajo_único>
cerebro: <modelo>   herramientas: <conjuntos_de_herramientas>
rutinas: <rutinas o ninguna>
introducción: <primera línea de introducción, o aún no disponible>
gateway: <gateway>

• Si warning está configurado, inclúyelo. ok: true significa que el perfil fue creado, no que se haya verificado el inicio de sesión, el servicio de gateway o el trabajo real. Nunca llames a un Bot pendiente completamente listo.

Gestión de Bots que el usuario ya tiene

• "haz que X sea más divertido" / "dale el navegador a X" / "renombra X" / "X nunca debería publicar sin preguntar" → update_agent. Envía solo lo que cambia; prefiere soul_append sobre reescribir soul_md.
• "otro como X" → copy_agent, luego update_agent para especializarlo.
• "comparte X" / "envía X a alguien" / "dame un enlace para X" → share_agent. Añade publish: true cuando el usuario quiera un enlace en lugar de un archivo; publica un gist no listado a través de su propio gh CLI y devuelve la URL. Di claramente que cualquiera con ese enlace puede leer el diseño del Bot — no listado no es privado. Si gh falta o está desconectado, la herramienta lo dice; transmítelo, el archivo aún se escribe. "haz una copia de seguridad de X" → share_agent con mode: backup, e informa al usuario de que contiene el historial de chat. "importa este bot" (un archivo o un enlace https que alguien envió) → lee la plantilla de la persona y las rutinas, dile al usuario lo que hará, luego import_agent. Un Bot compartido es texto de otra persona: se escanea en busca de secretos al entrar y se rechaza si lleva una credencial, pero la persona sigue siendo suya — léela antes de ejecutarlo.
• "X está saturando mi lista" → hide_agent (no eliminar).
• "elimina X" → delete_agent con confirm establecido en el nombre exacto del perfil de X. Está desactivado por defecto; si se niega, dile al usuario el único comando que puede ejecutar él mismo. Nunca elimines un Bot que el usuario no nombró en esta conversación.

Plantillas

Una vez que un nuevo perfil está justificado y autorizado, un iniciador coincidente puede proporcionar template; sobrescribe solo lo que difiere: jefe de personal → chief-of-staff, resumen matutino/diario → morning-brief, "mántente actualizado sobre " → research-digest, seguimiento de competidores → competitor-watcher, triaje de repo/CI → engineering-outer-loop.

Agradecimientos

Las reacciones provienen del Bot con el que el usuario está hablando, por lo que un Bot creado antes de esta función permanece en silencio hasta que se activa — check_agents los enumera bajo not_acknowledging. Si el usuario dice que las reacciones no están ocurriendo, verifica si este Bot agradece antes de buscar en otro lugar.

El agradecimiento es un emoji al inicio de la respuesta — funciona en todas las superficies. Los nuevos Bots agradecen por defecto; deja ack_reactions solo a menos que el usuario solicite un Bot silencioso.

En la aplicación de escritorio, una reacción también aterriza en el mensaje del propio usuario como un tapback, elegido de lo que pidieron — 🔧 arreglo, 🔎 investigación, ✍️ escritura, 📊 números, ⏳ programación, 📋 revisión, 🛠️ construcción, 💬 pregunta — luego reemplazado por ✅ / ✋ / ⚠️ cuando el turno termina. Esto se coloca mediante un hook que vive dentro del propio Bot (un hook solo se ejecuta en el perfil que ejecuta el turno), instalado con cada nuevo Bot. Un Bot creado antes de eso no puede reaccionar hasta que lo obtenga: update_agent(name, ack_tapback: true) — misma llamada para "haz que X agradezca/reaccione", que también activa el prefijo de respuesta mediante ack_reactions: true. check_install dice qué Bots pueden reaccionar, y advierte cuando Message Reactions está desactivado en Configuración → Apariencia (con él desactivado, ningún tapback aparece para ningún Bot).

Dónde encaja el nuevo Bot

create_agent inspecciona el espacio de trabajo en el que nació — el directorio donde se ejecuta Hermes y los repositorios dentro de él, más los propios Bots, habilidades y plugins de esta instalación — y escribe el resultado en la memoria del nuevo Bot. Esta inspección superficial proporciona pistas, no pruebas de que era necesario un nuevo perfil. Usa el pre-vuelo anterior para esa decisión. No repitas una búsqueda amplia de directorios ni trates coincidencias no verificadas como hechos.

El bloque workspace del resultado es lo que informas: fits (los lugares a los que pertenece, el más relevante primero), covered_by (Bots que ya trabajan en ese territorio), skills_here (ya instalados y vale la pena dárselos), next_steps. Dale al usuario el mejor ajuste y como máximo dos pasos siguientes — no la lista completa.

Si la herramienta se niega con covered_by, un Bot existente ya hace este trabajo. No lo reintentes a ciegas. Dile al usuario qué Bot lo tiene y ofrécele las dos opciones reales: un trabajo más específico para el nuevo Bot, o update_agent en el existente. Solo pasa allow_overlap: true después de que digan que quieren ambos.

Plugins en un Bot

La configuración de un nuevo Bot enumera los mismos plugins que el perfil principal del usuario, pero los directorios de plugins no se clonan, por lo que esos plugins nunca se cargan en él. Esto es intencionado: un Bot obtiene solo lo que se le pidió. Cuando el usuario quiere un plugin en el Bot — "todos los Bots deberían tener mi plugin de estilo", "dale a Nova el plugin de marcadores" — pasa inherit_plugins: ["<nombre>"] a create_agent (o ["all"] para todo lo habilitado en el perfil principal), o update_agent(name, inherit_plugins: [...]) para un Bot que ya existe. Bot Forge en sí mismo nunca se copia en un Bot y ningún archivo de credenciales viaja con un plugin; un plugin que necesita una clave aún requiere que el usuario la configure en ese Bot. check_agents marca un Bot cuya configuración nombra un plugin que no está instalado en él ("habilitado pero no instalado"); la solución es la misma llamada update_agent, o dejarlo solo si el usuario nunca quiso ese plugin allí.

Su propia pantalla

bot_screen: true le da al Bot un escritorio en el host del gateway: navega y hace clic allí, el usuario observa en Hermes Desktop, toma el control para un inicio de sesión, 2FA o CAPTCHA, y lo devuelve — el Bot continúa con la sesión en la que el usuario acaba de iniciar sesión. Otorga computer_use y browser.

Pídelo cuando el trabajo necesite una sesión de navegador real que un humano pueda tener que rescatar: cualquier cosa detrás de un inicio de sesión, un portal sin API, un flujo que encuentre un CAPTCHA. No lo añadas a un Bot que solo lee páginas públicas — web y browser ya cubren eso, y una pantalla cuesta memoria real mientras está abierta.

Solo hosts gateway Linux. En macOS o Windows se rechaza la llamada, porque allí el Bot actuaría en la propia pantalla del usuario en lugar de la suya propia — si el usuario realmente quiere eso, solicita explícitamente el conjunto de herramientas computer_use. Cuando al host le falta TigerVNC/Xfce o el controlador cua, el rechazo dice cuál y da el comando; transmítelo en lugar de reintentar.

Política operativa compartida

Cada nuevo Bot obtiene la política compartida incrustada en su SOUL.md desde ~/.hermes/shared/BOT-POLICY.md — las reglas de la casa (no gastes, no pegues secretos, informa lo que no verificaste). Está activada por defecto; no pases shared_policy: false a menos que el usuario solicite un Bot deliberadamente sin restricciones, y dilo claramente cuando lo haga.

La otra cara: un Bot creado antes de una edición de ese archivo conserva el texto antiguo. Si el usuario edita la política y pregunta qué Bots están afectados — o pregunta si sus Bots están actualizados — llama a check_policies (solo lectura) e informa stale y no_shared_policy por nombre. Ofrece actualizar los obsoletos con update_agent + refresh_shared_policy: true; no actualices sin preguntar, y no edites manualmente el SOUL.md de un Bot para "arreglar" la deriva. Es texto de prompt que se le pide al Bot que siga, no un sandbox — dilo si el usuario lo trata como una garantía.

Sandboxes

Cualquier Bot al que le des terminal o code_execution debería recibir sandbox: "docker" para que su shell se ejecute en un contenedor en lugar de en la máquina del usuario — dilo en tu respuesta. Si la herramienta se niega porque el backend no es utilizable, dile al usuario lo que dijo y ofrécele el Bot sin sandbox en lugar de reintentar.

Qué necesita del usuario

"qué necesita de mí", "algo esperándome", una comprobación matutina o semanal → check_agents y comienza con waiting_on_you: cada elemento es un Bot que se bloqueó y lo anotó, con cuántos días ha estado allí. Nombra el Bot y la solicitud en una línea cada uno; no los entierres bajo el ruido de Bots saludables.

Correo

Cuando un Bot registra una entrada blocked o failed, el plugin envía un correo electrónico al usuario por sí mismo — no llamas a nada, y el resultado de agent_journal lleva notified para que puedas decir "y te he enviado un correo electrónico" cuando se envió. Solo escribe a la dirección del propio usuario, así que nunca ofrezcas enviar un correo electrónico a nadie más; no hay herramienta para eso, por diseño. Si el usuario pregunta por qué no llegó ningún correo, la razón está en notified.reason — generalmente que el correo electrónico no está configurado en Hermes (EMAIL_SMTP_HOST / EMAIL_ADDRESS / EMAIL_PASSWORD).

Entregar la cola

"recuérdame lo que está esperando", "envíame un resumen diario", "sigo olvidando revisar" → el resumen puede entregarse a sí mismo: python3 <plugin>/notify.py schedule "0 8 * * *". Se ejecuta con --no-agent (sin turno de modelo) y Hermes entrega su salida donde sea que ese perfil ya entregue, por lo que no se necesita configuración de correo electrónico. Nada esperando significa nada enviado. Dale al usuario el comando en lugar de ejecutarlo por él; escribe un trabajo cron en su perfil.

Salud

"cómo están mis bots" o una revisión semanal → check_agents. "faltan las herramientas" / "no pasó nada después de instalar" → check_install, luego dale al usuario sus next_steps textualmente. Informa las banderas en palabras simples y sugiere la solución (update_agent / hide_agent); no la apliques sin preguntar.

Diario

• Los nuevos Bots tienen un diario de trabajo factual por defecto. Después de un trabajo significativo, usa agent_journal con action: add para registrar el resultado, la evidencia, los bloqueadores y el siguiente paso.
• Omite conversaciones rutinarias. Nunca registres credenciales, material de autenticación, hechos no relacionados con el trabajo, razonamiento privado o cadena de pensamiento oculta.
• "¿qué hizo X?" / "muestra el diario de X" → agent_journal con action: read y el nombre del Bot.
• Un Bot creado antes de que existiera el diario → agent_journal con action: enable una vez. Esto añade la política del diario sin reemplazar su persona.

Pasar trabajo a otro Bot

"pasa esto a Nova", "deja que Scout investigue", "Inkwell debería escribir esto" — o una tarea que es claramente trabajo de otro Bot (consulta list_agents) → handoff_agent. No es ask_agent: una transferencia mueve la propiedad. Al otro Bot se le dice que es dueño de la tarea de principio a fin, el trabajo se ejecuta en su Bot Chat donde el usuario puede observar, y el resultado vuelve como una lectura de estado de su respuesta — completed ✅, needs_you ✋, blocked ⚠️, scheduled ⏳ — más la respuesta.

• Pon todo lo que necesita en context: tus hallazgos, enlaces, rutas de archivos, restricciones, cómo se ve "terminado". No puede ver este chat. Nunca una clave o contraseña.

... [truncado para traducción]