Te pasas una tarde escribiendo el runbook de despliegue que tu equipo realmente necesita: primero el backup, luego el cambio de tráfico, una ventana de rollback de cinco minutos y una lista de qué tablas migran al final. Funciona. En cada release, el agente lo sigue.

Y un día se «mejora» a sí mismo. El curator decide que el skill es demasiado verboso y fusiona algunos pasos; la revisión de automejora añade un «orden más eficiente». Cuando te das cuenta, el paso de backup ha quedado después del cutover, y ese release ya salió.

El problema no es que el agente no sepa seguir reglas. Es que los skills que escribiste tú y los que escribió el agente viven en la misma bolsa y con los mismos permisos. Hermes siempre ha tenido pin, pero pin solo impide el borrado y el archivado automático: las ediciones y los patches siguen pasando. La v0.22.6 añade el lock de verdad.

pin vs lock, en una línea cada uno

• pin: el curator no lo marca como stale ni lo archiva, y el agente no puede borrarlo; todavía se puede editar.
• lock: el agente no puede cambiarlo en absoluto, mientras el skill sigue siendo legible, aparece en el índice de skills, se autocarga y se usa exactamente igual que antes.

Pin significa «no lo tires». Lock significa «no lo toques».

Cómo bloquear

hermes curator lock <skill>      # bloquearlo
hermes curator unlock <skill>    # levantar el bloqueo
hermes curator status            # listar lo que está bloqueado

En la app de escritorio no necesitas la CLI: abre Capabilities → Skills, selecciona el skill y usa su interruptor de lock.

El registro vive en el skills/.usage.json del perfil activo — el mismo sidecar que pinned — como "locked": true. Eso lo hace por perfil:

hermes -p work curator lock deploy-runbook    # solo la copia del perfil work

Casi todo lo bloqueable es bloqueable: escrito a mano, creado por el agente, incluido en el bundle o instalado desde el hub, siempre que el nombre resuelva en ese perfil. A la inversa, lock rechaza un nombre que no puede resolver, así que una errata no puede falsificar un registro.

Qué bloquea realmente el lock

Para un skill bloqueado, toda ruta de escritura del agente se rechaza — más amplio de lo que la mayoría espera:

• toda acción mutadora de skill_manage (create, edit, patch, delete);
• write_file / patch apuntando a cualquier ruta dentro del directorio de ese skill;
• cualquier comando de terminal que escribiría ahí — redirecciones, tee, cp/mv/rm, editores en sitio como sed -i, mutaciones de git dentro del árbol del skill, un cd previo hacia él, y código de intérprete en línea que nombre la ruta.

Esos límites se mantienen también bajo --yolo, y tanto en turnos normales como en cron jobs, subagentes, la revisión de automejora en segundo plano y la propia pasada del curator. El curator tampoco archivará un skill bloqueado.

Un detalle merece su propia frase: el agente no puede desbloquearlo. Su intento de ejecutar hermes curator unlock se rechaza en la capa de terminal, y mientras haya cualquier skill bloqueado, el archivo de registro del lock está protegido de la misma forma. El rechazo le pide que describa el cambio que quería hacer, para que decidas tú.

Tus propias ediciones no están restringidas en absoluto: tu editor, el editor de skills de escritorio y la CLI siguen funcionando. El lock limita al agente, no a ti.

Qué no es un lock

Tres fronteras que la documentación deja claras:

1. Solo limita al agente — no esperes que te proteja de tus propios errores.
2. Es una comprobación de política, no un sandbox. El guard de terminal lee los destinos de escritura de un comando (redirecciones, tee, cp/mv/rm, sed -i, git dentro del árbol del skill, cd, código en línea que nombre la ruta). Un script que escribe ahí a través de su propia lógica no se detecta. El aislamiento real sigue siendo un contenedor o un backend de terminal restringido.
3. Un .usage.json corrupto falla en cerrado en las rutas de fondo, no en todas: las pasadas que cambiarían skills (la revisión de automejora, el curator) se rechazan, mientras los turnos normales siguen funcionando, así que un archivo roto no congela todas las ediciones de skills. Repara el archivo, o ejecuta hermes curator unlock <skill> para reescribirlo.

Cuándo vale la pena usarlo

• Runbooks de producción, procedimientos de compliance, playbooks de incidentes — cualquier cosa donde un paso equivocado sale caro.
• Una biblioteca de skills de equipo que mantienes tú: quieres que el agente la use, no que la «optimice amablemente».
• Un skill de terceros que acabas de revisar: úsalo un tiempo y luego decide si aflojas el lock.

Si sí quieres que el agente itere sobre un skill, déjalo sin bloquear y usa pin para evitar que se archive.

Para la foto más amplia de confianza, otros dos posts encajan bien: los puntos ciegos del guard de skills cubre lo que el propio checker no ve, y integridad de skills y rug-pulls en la cadena de suministro cubre cómo un skill instalado puede ser sustituido bajo tus pies. Un lock responde a la tercera pregunta: una vez instalado, ¿quién tiene permiso para cambiarlo?

La capacidad llega en el tag v0.22.6: actualiza y la tienes disponible; hermes curator status lista por nombre cada skill bloqueado.