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, or you can paste the prompt below into an agent that already has a terminal and GitHub CLI.

00 LET AN AGENT PUBLISH IT

The agent runs pack then propose on your machine. It uses your gh login. Nothing is uploaded to this site. Confirm before it creates a public repo.

Publish a local Hermes bot as a listing on profiles for bots. In Hermes, a bot is a profile. Do not use Import profile or a .tar.gz. That path is a laptop move, not a listing. Do not git init inside ~/.hermes/profiles/. Secrets live there. Confirm GitHub CLI is logged in with `gh auth status`. If it is not, tell the human to run `gh auth login` and stop. Run `npx profiles-for-bots pack <profile-name>` (the folder name under ~/.hermes/profiles/). If pack reports credentials, stop. Replace literals in config.yaml with ${NAME}, declare them under env_requires, then pack again. Run `npx profiles-for-bots propose <packed-dir> --category <category> --tagline "<one line, 90 chars or fewer>"`. Confirm before it creates a public GitHub repo and prints the listing pull-request URL. Categories: coding, research, ops, writing, business, orchestration.

Same commands, if you want to run them yourself:

npx profiles-for-bots pack my-bot
npx profiles-for-bots propose ./my-bot-distribution --category ops --tagline "One line about the bot."

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. npx profiles-for-bots pack does that copy. 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.