Plugin packs
A plugin pack is a declarative, shareable YAML file ( hermes-pack.yaml ) that pins a set of plugins - like sharing a modpack. Installing a pack fans out to ordinary pinned installs; nothing new exists at runtime. Supply-chain posture. Every entry's ref must be an exact 40-character commit SHA - tags and branch names are rejected with an error naming the entry, the same rule as the plugin catalog. Pack installs ride the exact same pinned install path as hermes plugins install --ref <sha> and record the same provenance in plugins/.install-metadata.json , so two installs of the same pack resolve identically. Packs build on the manifest v2 fields ( manifest_version , api_version , requires_plugins ) - each plugin's own manifest still validates through the normal install path. Consent is never bulk-granted. pack install shows a mandatory review screen (every plugin, source, pinned ref, and the capabilities it declares), then asks one confirmation for the pack contents. After that, each plugin's declared capabilities go through the standard per-plugin capability-consent prompt - identical to a single hermes plugins install . There is no --yes , and non-interactive sessions cannot install…
From the official Hermes Agent documentation.
name: voice-assistant-pack
description: STT + streaming TTS + approval relay
author: hyper
version: 1.0.0
plugins:
- name: hermes-telegram-business # bare plugin-catalog name…
ref: e905f3bc5eeaa5a9dab9bc5155601b3ebec75757
- repo: owner/approval-relay # …or explicit owner/repo (or git URL)
ref: 8f3c2d1a9b4e5f6071829304a5b6c7d8e9f00112
subdir: plugins/relay # optional monorepo path
config: # optional, non-secret seeds only
hermes-media-studio:
default_model: flux-3
skills: [] # declared list only (not auto-installed yet)