publish a profile

Listings point at your repository. You keep ownership, you keep version history, and you can unlist by asking. Publishing takes three steps.

01 EXPORT AND SANITIZE

Copy the distribution-owned files out of your profile into a fresh repository: SOUL.md, config.yaml, mcp.json, skills/, and cron/. Leave everything else behind. Or start from the hermes-profile-template, a GitHub template that already gitignores user-owned paths (.env, auth.json, state.db, memories/, sessions/, logs/).

READ THIS FIRST

MCP servers are configured inside config.yaml under mcp_servers, and API keys routinely sit there in plain text inside headers. That file is distribution-owned, so publishing it as-is hands a working credential to everyone who installs your profile. Replace every literal secret with a variable reference and declare it under env_requires.

headers:
  Authorization: Bearer ${APIFY_TOKEN}

Our indexer scans for credentials and refuses to list a profile that contains one. That check is a safety net, not a substitute for looking.

02 ADD A MANIFEST AND TAG A VERSION

Put distribution.yaml at the repository root, write a README that explains what the agent is for, then tag a release. The tag is what people install.

name: your-profile
version: 0.1.0
description: One sentence on what this agent does
hermes_requires: ">=0.12.0"
author: your-github-handle
license: MIT
env_requires:
  - name: OPENAI_API_KEY
    description: OpenAI API key
    required: true

git tag v0.1.0 && git push --tags

Verify it installs cleanly before submitting:

hermes profile install github.com/you/your-profile#v0.1.0

03 OPEN A PULL REQUEST

Fill in the form. It validates with the same schema CI uses, then opens GitHub's new-file page with your registry entry pre-filled. Nothing is uploaded to us. CI indexes your repository at the pinned ref and fails the check if the manifest is malformed or a credential is found, with masked findings visible in the job log.

Categories: coding, research, ops, writing, business, orchestration. The ref must be a semver tag or a full 40-character commit SHA. A branch name is rejected, because a listing has to describe a snapshot that cannot change under it. Abbreviated SHAs are rejected too, since a short hex string is indistinguishable from a branch named in lowercase hex.