Acabas de clonar un repo nuevo y quieres que el agente conozca sus reglas desde el primer minuto: qué comando despliega, cómo se ejecutan las revisiones de estilo, cómo se invocan los tests. Antes solo tenías dos opciones: meter las skills en un directorio global (que desaparece en la siguiente máquina) o cruzar los dedos para que AGENTS.md lo cubriera todo. Ahora existe un tercer camino: las skills pueden vivir dentro del propio repo, viajar con él y servir a cualquiera que lo clone. Hermes acaba de lanzar esa función, llamada project-local skills, con un candado de confianza incorporado.

La versión corta: pon una carpeta de skills en la raíz de un checkout de git y las sesiones de Hermes iniciadas dentro de ese repo la tratan como la capa de skills de mayor prioridad — pero, por seguridad, nada se carga hasta que confíes explícitamente en el repositorio (PR #88566, fusionado el 2026-08-17).

Skills que viven en el repo: .hermes/skills/ y .agents/skills/

Añadir skills locales al repo es tan simple como crear una carpeta:

myproject/
├── .hermes/skills/        # Ubicación nativa de Hermes
│   ├── deploy.md          # Runbook de despliegue
│   └── api-conventions.md # Reglas de escritura de API
├── .agents/skills/        # Convención entre herramientas (compartida con otros CLIs de agentes)
│   └── review.md
└── AGENTS.md

La «raíz del proyecto» es el ancestro más cercano que contenga .git — los worktrees y los submodules también cuentan. Lanza Hermes desde cualquier subdirectorio y seguirá encontrando las skills del repo en la raíz.

La puerta de confianza: hermes skills trust

Las skills son documentos de procedimiento ejecutables que el agente sigue, así que Hermes no va a auto-cargar a ciegas las skills de cualquier repo clonado — es la primera línea de defensa contra el prompt injection. La primera vez que inicies Hermes en un repo con skills de proyecto, el banner mostrará un aviso:

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

Confía en el repo una sola vez (desde dentro de él, o por ruta):

hermes skills trust             # confía en el repo actual
hermes skills trust ~/myproject # o de forma explícita
hermes skills untrust           # revoca la confianza

Las raíces confiadas se guardan en skills.trusted_project_dirs dentro de ~/.hermes/config.yaml. Para apagar la función por completo (sin escaneo ni avisos), define skills.project_discovery: false:

skills:
  project_discovery: true      # activado por defecto
  trusted_project_dirs: []     # gestionado por trust/untrust

Prioridad: project → local → external_dirs

Las skills de proyecto son la capa superior de toda la jerarquía de skills: project → local (~/.hermes/skills/) → external_dirs. Una skill del repo llamada deploy supera a tu skill global con el mismo nombre en las sesiones dentro de ese repo — ese es el punto: las skills que viajan con el repo ganan en su propio terreno sin tocar tu perfil global. En el índice de skills del agente, las skills de proyecto llevan la etiqueta [project], así que su procedencia siempre queda a la vista.

Al igual que los directorios externos, los directorios de skills de proyecto se tratan como propiedad del repo: el curator de skills autónomo nunca los modifica, y las skills nuevas creadas por el agente siempre van a ~/.hermes/skills/.

El límite de seguridad

La puerta de confianza es una compuerta de carga real, no un adorno. Un repo no confiado no aporta nada al índice de skills, a skills_list, a skill_view, a los comandos slash ni a los montajes de contenedor — su única superficie es el aviso de una línea en el banner. Solo después de confiar en él, las skills del repo entran en la vista del agente.

Un detalle más: cuando el agente corre en los backends Docker/Modal, los directorios de skills de proyecto confiados se montan dentro del contenedor bajo un espacio de nombres project_skills/<idx>, con el mismo aislamiento. AGENTS.md y las skills de proyecto cubren terrenos distintos: AGENTS.md dice qué es este repo; una skill de proyecto dice cómo se hace el trabajo de este repo. Para ver el panorama completo de skills, mira nuestras 8 skills integradas más útiles y los patrones de combinación de skills; para las convenciones a nivel de repo, nuestro artículo sobre la cadena de directorios de AGENTS.md es un buen compañero de lectura.

Cuándo usarlo

El punto dulce son los repos de equipo: escribe los flujos de despliegue, las convenciones de commit y el conocimiento de dominio como skills, haz commit de ellas, y cada miembro (o cada ejecución de CI) que clone y ejecute hermes skills trust una vez le dará a su agente la misma memoria institucional. Los proyectos personales también salen ganando — volver a abrir un repo viejo ya no significa volver a enseñarle al agente desde cero.

La función ya está en main — ejecuta hermes update y pruébala.