agentsclimarketplace

Publish hermes skill repo

Skill srinitude/publish-hermes-skill-repo

Publish a local Hermes skill as a public GitHub repo, protect its main branch with required CI, version it, and reinstall it natively with hub provenance. Use when the user says "publish this skill to GitHub", "make a skill repo with CI", "add branch protection to a skill repo", "version a Hermes skill", "release a skill", "reinstall the skill from GitHub", or "turn this skill into an open-source repo", even if they do not say "Hermes" explicitly. Do NOT use for authoring skill content (use building-deterministic-skills), generic repo creation unrelated to skills (use github-repo-management), or installing third-party skills you did not author (use hermes-skill-operations).From its SKILL.md

Install
npx -y skills add srinitude/publish-hermes-skill-repo

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its file declares

Copied from the file, not written here

The file declares its own license as Apache-2.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

9.5 KB, ~2.2k tokens by cl100k_base, as published. Nobody here has run it

Publish, protect, version, and reinstall a Hermes skill repo

Take a local Hermes skill directory and ship it as a public, contribution-ready GitHub repo: Apache-2.0 license, CI that runs the skill's own validators, branch protection requiring CI, a versioned release, then a clean native reinstall from GitHub so the installed copy is hub-tracked and commit-pinned.

CRITICAL RULES

  1. The repo name MUST equal the skill's frontmatter name. On install the repo name becomes the skill directory, and Hermes enforces name == directory. A mismatch fails validation. Confirm both match before gh repo create.
  2. NEVER hand-edit the Hermes config.yaml (under ~/.hermes/) — it is a protected file. Use hermes plugins enable/disable and hermes CLI commands only.
  3. NEVER commit .git/, __pycache__/, caches, or reports/ scrape junk into the published tree via a raw copy. Stage with git archive HEAD | tar -x so only committed files ship.
  4. Reinstall ONLY through Hermes' quarantine APIs (scan_skillshould_allow_installinstall_from_quarantine), NEVER by copying into ~/.hermes/skills/. The quarantine path writes hub lock provenance, content hashes, and audit logs.
  5. A reinstall MUST be blocked unless should_allow_install(result) returns True. If the verdict is dangerous, stop. If caution blocks a community source, sanitize the false positives (see reference) instead of forcing.
  6. Run the Hermes venv Python for all scan/install steps: /Users/kiren/.hermes/hermes-agent/venv/bin/python3. System python3 (3.9) cannot import Hermes modules that use 3.10+ syntax.
  7. Wait for GitHub CI to pass on the pushed commit BEFORE tagging a release or reinstalling. Tag and install only commit-verified-green code.
  8. Offload counting, scan verdicts, and frontmatter checks to the scripts in scripts/; do not eyeball them.
  9. If a required fact is missing (skill path, GitHub owner, repo name, version), output INSUFFICIENT CONTEXT: <field> and stop instead of guessing.

Gotchas

  • Repo named <skill>-repo or any suffix: WRONG. The install would fail the name == directory check. Name the repo exactly <skill-name>.
  • Bare owner/repo or owner/repo/. install often fails for root-level skill repos with "Could not fetch ... from any source" even though inspect succeeds. Use the quarantine install fallback in the reference, not --force.
  • Scanning the LOCAL git worktree inflates findings: scan_skill recurses into .git/. Always scan the git archive staged tree (no .git), which is what actually installs.
  • caution verdict on community source blocks install. Common false positives: the literal word "context" tripping context_exfil; invisible/zero-width Unicode in scraped JSON tripping invisible_unicode. Sanitize, do not force.
  • Hand-editing config.yaml to enable a plugin: blocked (protected file).
  • enforce_admins=true blocks YOUR direct pushes too. Default to false so admins keep direct-push convenience while contributor PRs stay gated.
  • fish shell cannot do VAR=$(...) or heredocs. Use bash for variable capture and write_file for scripts; wrap CLI that needs profile env in /opt/homebrew/bin/fish -lc '...'.

One-term-per-concept

  • SKILL DIR = the local ~/.hermes/skills/<name>/ directory.
  • STAGE = a clean git archive export with no .git (what gets scanned/installed).
  • HUB INSTALL = install via quarantine APIs that writes .hub/lock.json.
  • CI GATE = the GitHub Actions checks required by branch protection.

Prerequisites

  1. gh auth status shows a logged-in account with repo and workflow scopes.
  2. The skill already passes its own validators locally (author it first with the building-deterministic-skills skill).
  3. You know: the skill directory, the GitHub owner, the repo name (= skill name), and the version string (default 0.1.0).

Ordered workflow

Default path: stage a clean copy, scaffold OSS files + CI, push, protect, tag, reinstall. Read references/publish-commands.md for the full copy-paste recipes. Progress:

  1. If the skill directory, GitHub owner, repo name, or version is unknown, output INSUFFICIENT CONTEXT: <field> and stop.
  2. Confirm gh auth status shows repo + workflow scopes.
  3. Confirm the repo name equals the skill frontmatter name (grep '^name:' <skilldir>/SKILL.md). Fix the mismatch before continuing.
  4. Stage a clean copy into a build dir whose basename equals the skill name: cp -R <skilldir>/. <stage>/ then delete __pycache__ and caches.
  5. Add license: Apache-2.0 and version: <version> to the staged SKILL.md frontmatter if absent.
  6. Fetch the Apache 2.0 text into LICENSE: curl -fsSL https://www.apache.org/licenses/LICENSE-2.0.txt -o LICENSE.
  7. Write README.md, NOTICE, CONTRIBUTING.md, CODE_OF_CONDUCT.md, SECURITY.md, .gitignore from the recipes in the reference.
  8. Write .github/workflows/ci.yml that runs the skill's validators on Python 3.9/3.11/3.12 plus a ruff lint job. Make frontmatter-check CI-portable (it must pass with no Hermes installed).
  9. Write .github/ISSUE_TEMPLATE/ forms and PULL_REQUEST_TEMPLATE.md.
  10. Run the local validator pipeline in the stage and fix every failure.
  11. git init -b main, commit, and gh repo create <name> --public --source . --remote origin --push.
  12. Set repo topics and disable the wiki via gh repo edit.
  13. Watch CI to green: gh run watch <id> --exit-status. Do not proceed until green.
  14. Apply branch protection with the 4 required checks (assets/branch-protection.json) via gh api -X PUT repos/<owner>/<name>/branches/main/protection.
  15. Tag and publish the release: gh release create v<version> --title v<version> --notes "...".
  16. Stage a fresh git archive HEAD export (no .git), then run the quarantine reinstall script in assets/reinstall-from-github.py with the Hermes venv Python.
  17. Require the install scan verdict safe (or caution allowed) and should_allow_install == True; if blocked, sanitize per the reference and repeat from step 11.
  18. Run the full Validation pipeline below and fix every failure before returning.

Validation pipeline

  1. Frontmatter: python3 scripts/check-skill-frontmatter.py
  2. Readability: python3 scripts/check-dumb-model-readability.py SKILL.md
  3. No dead links: python3 scripts/check-no-dead-links.py
  4. Determinism: python3 scripts/check-determinism.py
  5. Workflow coverage: python3 scripts/check-workflow-coverage.py
  6. Hermes security scan: with the venv Python, import tools.skills_guard.scan_skill (source agent-created) and require tools.skills_guard.should_allow_install(result) returns True.
  7. GitHub state: gh api repos/<owner>/<name>/branches/main shows protected: true; gh release view v<version> exists; CI is green.

Output template

Repo: https://github.com/<owner>/<name>
Skill name == repo name: YES
Version: <version>  | Release: v<version> published
CI: green (Python 3.9/3.11/3.12 + ruff)
Branch protection: <N> required checks, strict, PR review, linear history
Reinstall: <safe|caution-allowed>, hub lock commit=<sha10> version=<version>
config.yaml hand-edited: NO

INSUFFICIENT CONTEXT escape hatch

If any of these are unknown, emit INSUFFICIENT CONTEXT: <field> and stop: the skill directory path, the GitHub owner/org, the repo name (= skill name), or the version string. Do not invent an owner or guess a version.

Critical-rule placement note

These critical rules are intentionally front-loaded at the top of this file and book-ended: the final self-check below repeats the load-bearing ones so a weak model re-reads them before finishing.

Verification checklist

  • Repo name equals the skill frontmatter name.
  • config.yaml was never hand-edited (CLI only).
  • Published tree has no .git, __pycache__, or cache files (git archive).
  • Reinstall used the quarantine APIs and should_allow_install was True.
  • CI was green on the pushed commit before tagging and reinstalling.
  • Branch protection requires the CI checks (strict) and is protected: true.
  • gh release view v<version> exists and is not a draft.
  • Hub lock entry records the commit sha and version.
  • scripts/check-skill-frontmatter.py passes.
  • scripts/check-dumb-model-readability.py SKILL.md passes.
  • scripts/check-no-dead-links.py passes.
  • scripts/check-determinism.py passes.
  • scripts/check-workflow-coverage.py passes.
  • Critical rules stayed front-loaded and book-ended.

What ships with it: 16 files

44.5 KB alongside SKILL.md, 6 of them executable

evals/

references/

Keep looking

Skills are one crate of 326,286. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.