hermes - 💡(How to fix) Fix Feature Request: Profile Distributions (shareable, packaged Hermes profiles) [1 participants]

Hey team, first off: Hermes v0.12.0 is incredible. The profile system, the autonomous curator, 18 messaging platforms, the whole thing. I have been building on top of it for the past few weeks and the experience has been genuinely great.

This feature request comes from a real pain point I keep hitting, and I wanted to lay it out in enough detail that you can see both the problem and a path to solving it without it becoming a maintenance burden.

The problem

I have a specialized Hermes profile. Custom SOUL.md, curated skills, MCP server connections, pipeline settings, cron jobs, the works. It runs beautifully on one machine. But when I need to deploy it to a second machine, or share it with a colleague, the process is: manually create the profile, copy files, remember which env vars to set, hope nothing was missed. Every deployment is manual reconstruction with no guarantee of consistency.

What I am proposing: Profile Distributions

A distribution is a packaged Hermes profile that can be installed with a single command. Think of it as the profile equivalent of what skills already have with URL-based installation, but at the profile level.

hermes distribution install https://github.com/user/my-profile-distro
# prompted for required API keys
# done

A distribution would contain:

my-distribution/
  distribution.yaml     # manifest: name, version, hermes_requires, description
  SOUL.md
  config.yaml
  mcp.json
  skills/
  cron/
  .env.template         # required env vars (descriptions, not actual keys)

The manifest declares what the distribution needs:

name: telemetry
version: 0.1.0
description: "Telemetry - Compliance monitoring and review harness"
hermes_requires: ">=0.12.0"
alias: telemetry
env_requires:
  - name: OPENAI_API_KEY
    description: "OpenAI API key for model access"
    required: true
  - name: GRAPHITI_MCP_URL
    description: "URL for Graphiti memory MCP server"
    required: false
    default: "http://127.0.0.1:8000/sse"

Update semantics

This is where it gets interesting. When a distribution updates, what gets replaced and what gets preserved?

Distribution-owned (replaced): SOUL.md, config (merged with local overrides), skills shipped by the distribution, cron jobs shipped by the distribution.

User-owned (preserved): memories, sessions, state.db, auth.json, .env (actual keys), user-added skills, anything in a local/ directory.

Same pattern as OS package managers: config merges, data is never touched.

Anticipating concerns

If I were in your shoes managing this level of output and community momentum, I would probably be thinking:

• "This is just profiles with extra steps. People can clone a git repo into ~/.hermes/profiles/ and they are good."
• "Skills are our extensibility unit, not profiles. We do not want to maintain a second packaging system."
• "This adds surface area and maintenance burden for something that might be an edge case."

I totally get that, and those are fair points. But I think the stronger case can be made for distributions because:

1. git clone works for a single deployment, but it does not prompt for required environment variables, does not check Hermes version compatibility, and does not know how to update a profile without blowing away the user's memories and sessions. The moment you have two machines or two people sharing a profile, the manual approach falls apart. The distribution layer is the thin piece that makes profiles truly portable.

2. Skills are absolutely the right unit for individual capabilities. A distribution does not replace skills; it bundles them. A profile is a coherent opinion about how to use Hermes: which skills, which MCP servers, which SOUL, which cron schedule, all working together as a system. Skills and distributions operate at different levels of abstraction and complement each other.

3. The v1 implementation is genuinely lightweight. hermes distribution install <path> copies files into ~/.hermes/profiles/<name>/, reads the manifest, prompts for env vars, done. hermes distribution export is even simpler: basically cp -r plus generating a manifest. No registry, no publishing, no three-way merge needed for v1. The heavier features can come later if there is demand.

4. The more people building specialized profiles on Hermes, the more people running Hermes as their daily driver. Imagine someone builds a "Code Review Specialist" profile, or a "Research Assistant" profile, or a compliance monitoring harness, complete with the right SOUL, the right skills, the right MCP connections, and the right cron schedule. Today there is no way to share that as a unit. Distributions would make profiles a first-class shareable artifact and lower the barrier for others to adopt what someone has built. That is how ecosystems compound.

My use case

Telemetry is a compliance-related harness built as a Hermes profile. It includes a custom SOUL.md, MCP connections to a Graphiti memory graph, specialized skills for compliance-related work, a multi-model intelligence pipeline, and domain-specific cron jobs. Today, deploying Telemetry to a new machine means manually creating the profile and copying files. With distributions it would be:

hermes distribution install https://github.com/user/telemetry-distribution
# prompted for API keys
# done

CLI surface (proposed)

hermes distribution install <path-or-url>
hermes distribution export <profile-name> <dest>
hermes distribution update <profile-name>
hermes distribution list
hermes distribution info <profile-name>

I'd be happy to contribute however I can to the implementation of this feature. The design is informed by building Telemetry as a Hermes profile over the past few weeks and running into portability limitations repeatedly. Thanks for considering it.