Segunda-feira de manhã você abre uma session nova e cola as mesmas três linhas antes de conseguir começar: siga o nosso template interno, rode o script de QA antes de publicar, nunca use emoji como título. Na quarta você troca de modelo e o agent esquece o template. Na sexta, depois de uma passada de compressão, ele começa a escrever numa estrutura completamente diferente — e tudo o que você queria era que aquele processo simplesmente estivesse lá, sem precisar repetir.

O sistema de skills foi projetado para ser sob demanda: o agent lê a descrição curta de cada skill de graça e só carrega o corpo completo quando uma tarefa realmente pede. Esse desenho economiza tokens, mas parte do princípio de que a tarefa parece precisar da skill. Quando o seu processo é uma restrição permanente — um estilo de escrita, um checklist de revisão, um procedimento de release —, o carregamento sob demanda muitas vezes chega tarde demais.

O que o auto_load muda

No config.yaml do profile:

skills:
  auto_load:
    - release-notes
    - qa-multilingual

Essas skills agora são totalmente carregadas no início de toda session nova (injetadas no prompt do sistema como skills carregadas), e não apenas listadas no catálogo. Isso cobre toda superfície de agent: CLI, TUI, gateway, jobs de cron e agents de API. O padrão é uma lista vazia, o que significa o comportamento sob demanda que você já tinha.

O paralelo é fácil de traçar: o Cursor entrega esse padrão como Custom Modes — escolha uma skill, fixe, mantenha o agent num playbook. Do lado do Hermes é uma lista de configuração com escopo de profile, então o playbook está lá independentemente de qual interface ou modelo você usa hoje.

Um detalhe que vale destacar: skills em auto_load são deduplicadas pelo nome canônico em relação a pedidos explícitos de --skills, e passam pelos mesmos gates — uma skill desativada não é injetada, e uma ativada ainda conta para o uso do Curator, então uma skill que ninguém usa acaba sendo limpa em vez de continuar “popular” para sempre só porque foi fixada.

No que ele difere das outras três formas de uma skill chegar ao prompt

Rota	Quando se aplica	Bom para
O índice de descrições (padrão)	Sempre presente, mas só a descrição curta	A maioria das skills: o agent decide quando precisa de uma
skills.auto_load	Toda session nova, corpo completo carregado	Restrições permanentes: estilo da casa, checklists de revisão, procedimento de release
--skills explícito na linha de comando	Apenas esta invocação	Tarefas pontuais, ou experimentar uma skill
Diretórios de skills locais do projeto	Descobertos quando o gatilho deles se aplica	Convenções do repositório que viajam com o código

Eles se somam. O auto_load é o piso, --skills é “o que esta execução precisa adicionalmente”, e as skills locais do projeto são “as regras deste repositório”.

Por que isso não explode o custo do seu prompt

Esta é a parte mais cuidadosa da implementação, e é por isso que o recurso merece confiança. Fixar uma skill significa que toda session carrega um bloco fixo de prompt de sistema — implementado de forma descuidada, isso quebra duas coisas de uma vez: o tamanho da requisição e o cache de prompt.

O que acontece de fato: a injeção é resolvida uma única vez, quando o prompt de sistema do agent é construído pela primeira vez, e os bytes exatos renderizados são reaproveitados entre trocas de modelo, compressão e restauração de prefixo estático. Em outras palavras, ela passa a fazer parte do prefixo em cache em vez de ser conteúdo mutável remontado a cada turno. O PR verifica isso especificamente: depois que o arquivo da skill em disco é alterado, a renderização de auto-load do mesmo agent continua estável byte a byte — caso contrário o cache seria invalidado na hora.

A mesma verificação cobre mais dois comportamentos: uma skill ausente emite um aviso e é pulada em vez de impedir o início da session, e --ignore-rules (ou HERMES_IGNORE_RULES=1) suprime o auto-load junto com o resto do contexto injetado automaticamente.

Quando não usar

• Não fixe uma dúzia de skills. Toda skill fixada ocupa contexto permanente; fixe dez e você começa a pagar tokens por procedimentos que nunca toca. Duas ou três restrições genuinamente globais é o ponto certo.
• Não fixe uma skill que você está iterando ativamente. Como a renderização é resolvida uma vez e estável byte a byte, editar o arquivo da skill no meio da session não altera a session em execução. Isso é o recurso funcionando como projetado — só significa “edite e depois inicie uma session nova”.
• De vez em quando você quer uma execução limpa: HERMES_IGNORE_RULES=1 hermes chat -q "...", ou --ignore-rules; no CI, adicione --ignore-user-config para uma execução totalmente isolada.

Um uso real: fixe o seu procedimento de release

Digamos que você tenha uma rotina de release fixa — como o número de versão é derivado, qual script de QA roda, qual é a ordem das seções. Escreva isso como uma skill e depois fixe:

skills:
  auto_load:
    - release-notes
    - qa-multilingual

Depois confira três coisas:

hermes config get skills.auto_load          # confirme o valor no profile
hermes session new                          # inicie uma session nova
hermes skills list                          # ela conta como carregada?

Agora peça o trabalho e veja se ele usa o seu template na primeira tentativa, sem você dizer “siga o nosso template” antes. Se não usar, confira os nomes das skills (um erro de digitação só produz um aviso e a skill é pulada) e depois confira se você não iniciou a session com --ignore-rules.

Isso também é o que torna a troca de modelo segura: troque para um modelo barato no trabalho de rotina e um forte nos casos difíceis, e as skills fixadas vêm junto — e, como os bytes renderizados não mudam, o prefixo em cache sobrevive à troca. Se você quer o mesmo processo também em execuções sem supervisão, combine com o stream-json para o CI conseguir decidir se a execução deu certo, e com as skills locais do projeto para as convenções do próprio repositório viajarem com o código.

A versão curta

O skills.auto_load parece uma pequena conveniência e se comporta como um recurso de confiabilidade: ele transforma “uma restrição que eu repito toda vez” em “o estado padrão de uma session”. Você paga contexto permanente em troca de consistência de comportamento — o que importa mais justamente quando o agent está rodando com um modelo diferente, depois de uma compressão, ou sem supervisão em um agendamento. Para ver qual release entregou isso e o que mais mudou junto, leia o que a v0.21.4 realmente entregou; para o sistema mais amplo, veja a referência do comando hermes skills.