Skills sempre à mão: o skills.auto_load do Hermes

A v0.21.4 do Hermes saiu a 21 de setembro de 2026 e, no meio de uma lista de alterações que dá para perder a manhã, veio uma chave que resolve uma dor antiga: skills.auto_load. Escreves meia dúzia de linhas no config.yaml e essas skills passam a estar completamente carregadas no arranque de todas as sessões novas — CLI, TUI, gateway (Telegram, Discord e companhia), cron e agentes programáticos.

Porque é que isto interessa? Porque até agora o único mecanismo era o -s a cada invocação:

hermes -s hermes-agent-dev,github-auth
hermes chat -s github-pr-workflow -s github-auth

Funciona, e continua a funcionar. O problema é que a decisão passa a viver em todos os sítios onde invocas o Hermes: no alias da shell, no cron job das nove, no comando que o dispatcher constrói. Basta esqueceres-te de uma vez — ou mudares de máquina, ou de perfil — e o agente arranca sem saber aquilo que tu achas que ele sabe. Não dá erro nenhum. Simplesmente responde pior, e levas três turnos a perceber porquê.

Este blog é um caso concreto disso: o pipeline escreve de manhã, publica ao meio-dia, e cada passo é uma sessão diferente. Config drift entre superfícies é exactamente o que o auto_load elimina.

Como se usa

skills:
  auto_load:
    - my-workflow
    - github-pr-workflow

Cada entrada é o nome de uma skill, exactamente como aparece registada. Nada mais: não há ficheiros por sessão nem variáveis de ambiente a exportar.

O -s da linha de comandos continua a existir e não entra em conflito. Se pedires explicitamente uma skill que já está na lista, ela carrega uma única vez — o Hermes faz dedupe pelo nome canónico. A diferença é a permanência: o -s vale para aquela invocação, o auto_load vale para todas as sessões novas.

O que acontece por dentro

A lista é resolvida uma vez, quando o system prompt da sessão é construído pela primeira vez. Os bytes renderizados são depois reutilizados durante toda a conversa — mudanças de modelo, compressão de contexto, o que aparecer pelo caminho. Isto não é pormenor de implementação irrelevante: é o que mantém o prompt caching intacto. Se as skills fossem recarregadas a meio, o prefixo mudava e pagavas o prompt inteiro outra vez a cada turno.

A consequência prática é a única que precisas de memorizar: edições ao config.yaml só fazem efeito na sessão seguinte. Estás a meio de uma conversa, mudas a lista, e nada muda até saíres e voltares a entrar. Não é um bug, é o preço de ter cache estável.

Pormenores que só se notam a usar

• Skills em falta ou desactivadas não rebentam nada. Fica um WARNING e o resto carrega. Se escreveres mal um nome, vês o aviso no arranque e uma skill a menos do que contavas.
• É profile-scoped. Cada perfil tem a sua lista no seu próprio config.yaml, e o auto_load de um não vaza para os outros. É o comportamento certo, mas também quer dizer que não há herança: se corres vários perfis, repetes a lista onde ela faz sentido.
• --ignore-rules, ou HERMES_IGNORE_RULES=1, salta o auto-load todo — a lista, o AGENTS.md, o SOUL.md, o .cursorrules e a injecção de memória. As skills pedidas explicitamente com -s continuam a carregar. É a forma mais rápida de responder à pergunta “isto vem da configuração ou do agente?”.
• Se usas o Curator para contabilizar o uso das skills, as que entram por auto_load contam para as estatísticas como se tivessem sido pedidas com --skills. O bump de usage acontece e os números ficam coerentes.
• Uma coisa que isto não é: hermes skills trust e untrust são outro mecanismo, para skills vindas de repositórios. Não têm nada a ver com carregar.

Quando vale a pena

Se tens uma skill e usas raramente, ignora isto. Se tens um conjunto pequeno de skills que definem como trabalhas — o fluxo de PRs, o tom de escrita, a convenção de commits — o auto_load transforma “espero que o agente saiba isto” em “o agente sabe isto, sempre”. E como não falha ruidosamente quando uma skill não carrega, também te poupa o pior dos mundos, que é um agente a comportar-se de forma diferente sem ninguém dar por isso.

Há um custo escondido, e é melhor dizê-lo: tudo o que pinas entra no system prompt em todas as sessões, incluindo aquela em que só querias perguntar as horas. Pina com parcimónia e espreita o /context de vez em quando para ver quanto disso é skill.

Para experimentar uma skill nova, o -s continua a ser o sítio certo. Para aquilo que é teu e não muda, vai ao config.yaml.