Você acabou de clonar um repo novo e quer que o agent entenda as regras dele desde o primeiro minuto: qual comando faz o deploy, como os checks de estilo rodam, como os testes são invocados. Antes, suas opções eram duas — enfiar skills num diretório global (que some na próxima máquina) ou torcer para o AGENTS.md cobrir tudo. Agora existe um terceiro caminho: as skills podem morar dentro do próprio repo, viajar com ele e funcionar para qualquer um que o clonar. O Hermes acaba de lançar esse recurso, chamado project-local skills, com uma trava de confiança acoplada.

Em resumo: coloque uma pasta de skills na raiz de um checkout git, e as sessões do Hermes iniciadas dentro desse repo a tratam como o nível de maior precedência — mas, por segurança, nada carrega até você confiar explicitamente no repositório (PR #88566, mesclado em 2026-08-17).

Skills que moram no repo: .hermes/skills/ e .agents/skills/

Adicionar skills locais ao repo é só criar uma pasta:

myproject/
├── .hermes/skills/        # local nativo do Hermes
│   ├── deploy.md          # runbook de deploy
│   └── api-conventions.md # regras de criação de API
├── .agents/skills/        # convenção entre ferramentas (compartilhada com outros CLIs de agent)
│   └── review.md
└── AGENTS.md

A “raiz do projeto” é o ancestral mais próximo que contém .git — worktrees e submodules contam. Inicie o Hermes de qualquer subdiretório e ele ainda encontra as skills do repo na raiz.

O gate de confiança: hermes skills trust

Skills são documentos de procedimento executáveis que o agent segue, então o Hermes não vai carregar cegamente skills de qualquer repo clonado — essa é a primeira linha de defesa contra prompt injection. Na primeira vez que você iniciar o Hermes num repo com skills de projeto, o banner mostra um aviso:

◆ 3 project skill(s) found in /home/you/myproject but not loaded — run `hermes skills trust` to enable them.

Confie no repo uma única vez (de dentro dele, ou pelo caminho):

hermes skills trust             # confia no repo atual
hermes skills trust ~/myproject # ou explicitamente
hermes skills untrust           # revoga

As raízes confiadas ficam em skills.trusted_project_dirs no ~/.hermes/config.yaml. Para desligar o recurso por completo (sem varredura, sem avisos), defina skills.project_discovery: false:

skills:
  project_discovery: true      # ligado por padrão
  trusted_project_dirs: []     # gerenciado por trust/untrust

Precedência: projeto → local → external_dirs

As skills de projeto são o topo da hierarquia inteira de skills: projeto → local (~/.hermes/skills/) → external_dirs. Uma skill do repo chamada deploy sobrescreve a sua skill global homônima nas sessões dentro daquele repo — e é exatamente esse o ponto: skills embarcadas no repo vencem no seu próprio território sem tocar no seu perfil global. No índice de skills do agent, as skills de projeto são marcadas com [project], então a proveniência fica sempre visível.

Assim como os diretórios externos, os diretórios de skills de projeto são tratados como posse do repo: o curator autônomo de skills nunca os modifica, e novas skills criadas pelo agent sempre vão para ~/.hermes/skills/.

A fronteira de segurança

O gate de confiança é um gate de carregamento real, não uma decoração. Um repo não confiado contribui com nada para o índice de skills, o skills_list, o skill_view, os comandos de barra ou os mounts de contêiner — a única superfície dele é o aviso de uma linha no banner. Só depois de confiar é que as skills do repo entram na visão do agent.

Um detalhe a mais: quando o agent roda em backends Docker/Modal, os diretórios de skills de projeto confiados são montados no contêiner sob um namespace project_skills/<idx>, com o mesmo isolamento. O AGENTS.md e as skills de projeto cobrem territórios diferentes: o AGENTS.md diz o que este repo é; uma skill de projeto diz como o trabalho deste repo é feito. Para o panorama mais amplo de skills, veja as nossas 8 skills embutidas mais úteis e os padrões de combinação de skills; para convenções em nível de repo, o nosso post sobre a cadeia de diretórios do AGENTS.md é um bom complemento.

Quando usar

O ponto ideal são os repositórios de equipe: escreva fluxos de deploy, convenções de commit e conhecimento de domínio como skills, faça commit delas, e todo membro (ou execução de CI) que clonar e rodar hermes skills trust uma única vez dá ao seu agent a mesma memória institucional. Projetos pessoais também ganham — reabrir um repo antigo não significa mais reensinar o agent do zero.

O recurso está no main — rode hermes update e experimente.