Você passa uma tarde escrevendo o runbook de deploy que o seu time realmente precisa: backup primeiro, depois a virada de tráfego, uma janela de rollback de cinco minutos e uma lista de quais tabelas precisam migrar por último. Funciona. A cada release, o agente segue o runbook.

Então um dia ele "se aprimora". O curator decide que a skill é verbosa demais e funde alguns passos; a revisão de autoevolução adiciona uma "ordenação mais eficiente". Quando você percebe, o passo de backup foi para depois do cutover — e esta release já foi publicada.

O problema não é que o agente não saiba seguir regras. É que skills que você escreveu e skills que o agente escreveu vivem no mesmo pool, com as mesmas permissões. O Hermes sempre teve pin, mas o pin só impede exclusão e arquivamento automático — edições e patches ainda passam. A v0.22.6 acrescenta o lock de verdade.

pin vs lock, em uma linha cada

• pin: o curator não vai marcá-la como stale nem arquivá-la, e o agente não pode apagá-la; ela ainda pode ser editada.
• lock: o agente não pode alterá-la de jeito nenhum, e a skill continua legível, listada no índice de skills, carregável automaticamente e utilizável exatamente como antes.

Pin quer dizer "não jogue fora". Lock quer dizer "não encoste".

Como travar

hermes curator lock <skill>      # trava
hermes curator unlock <skill>    # destrava
hermes curator status            # lista o que está travado

No app desktop você não precisa da CLI: abra Capabilities → Skills, selecione a skill e use o switch de lock dela.

O registro fica no skills/.usage.json do profile ativo — o mesmo sidecar do pinned — como "locked": true. Isso o torna por profile:

hermes -p work curator lock deploy-runbook    # só a cópia no profile work

Quase tudo que pode ser travado pode ser travado: escrita à mão, criada pelo agente, bundled ou instalada do hub, desde que o nome resolva naquele profile. Por outro lado, o lock recusa um nome que não consegue resolver, então um erro de digitação não forja um registro.

O que o lock realmente bloqueia

Para uma skill travada, todo caminho de escrita do agente é recusado — mais amplo do que a maioria espera:

• toda ação de mutação do skill_manage (create, edit, patch, delete);
• write_file / patch mirando qualquer caminho dentro do diretório daquela skill;
• qualquer comando de terminal que escreveria ali — redirecionamentos, tee, cp/mv/rm, editores in-place como sed -i, mutações de git dentro da árvore da skill, um cd para dentro dela antes, e código de interpretador inline que cite o caminho.

Esses limites valem também sob --yolo, e em turnos normais, jobs de cron, subagentes, a revisão de autoevolução em background e a própria passagem do curator. O curator também não arquiva uma skill travada.

Um detalhe merece uma frase própria: o agente não consegue destravar. A tentativa dele de rodar hermes curator unlock é recusada na camada de terminal e, enquanto qualquer skill estiver travada, o arquivo de registro de locks fica protegido do mesmo jeito. A recusa diz para ele descrever a mudança que queria, para você decidir.

Suas próprias edições não passam por gate nenhum: seu editor, o editor de skills do desktop e a CLI continuam funcionando. O lock restringe o agente, não você.

O que um lock não é

Três fronteiras que a documentação declara sem rodeios:

1. Ele restringe apenas o agente — não espere que proteja você dos seus próprios erros.
2. É uma checagem de política, não um sandbox. O guard de terminal lê os alvos de escrita de um comando (redirecionamentos, tee, cp/mv/rm, sed -i, git dentro da árvore da skill, cd, código inline que cite o caminho). Um script que escreve ali pela própria lógica não é visto. Isolamento de verdade ainda significa um container ou um backend de terminal restrito.
3. Um .usage.json corrompido falha fechado nos caminhos de background, não em tudo: as passagens que mudariam skills (revisão de autoevolução, curator) são recusadas, enquanto os turnos normais continuam funcionando, então um arquivo quebrado não congela toda edição de skill. Repare o arquivo, ou rode hermes curator unlock <skill> para regravá-lo.

Quando vale a pena usar

• Runbooks de produção, procedimentos de compliance, playbooks de incidente — qualquer coisa em que um passo errado custa caro.
• Uma biblioteca de skills do time que você mantém: você quer que o agente a use, não que ele a "otimize por conta própria".
• Uma skill de terceiros que você acabou de revisar: rode por um tempo, depois decida se afrouxa o lock.

Se você quer que o agente itere numa skill, deixe-a destravada e use pin para evitar que ela seja arquivada.

Para o quadro mais amplo de confiança, mais dois posts combinam bem: os pontos cegos do guard de skills cobrem o que o próprio verificador deixa passar, e integridade de skills e rug-pulls na cadeia de suprimentos cobre como uma skill instalada pode ser trocada por baixo de você. Um lock responde à terceira pergunta: depois que ela está instalada, quem tem permissão para mudá-la?

A capacidade está na tag v0.22.6 — atualize e ela está disponível; hermes curator status lista cada skill travada por nome.