Use update when the user asks to refresh or reinstall existing tools:

npx -y @mvanhorn/printing-press-library update flight-goat
npx -y @mvanhorn/printing-press-library update

When deciding whether a local CLI is stale, compare the installed binary's reported version with the catalog release metadata before falling back to source inspection:

<slug>-pp-cli --version
npx -y @mvanhorn/printing-press-library search <slug> --json
npx -y @mvanhorn/printing-press-library list --json

In search --json or list --json, read release.version for the catalog version and release.cli_name for the binary name. If the local --version is older than the catalog release.version, update the tool with the user's intended binary directory, usually:

npx -y @mvanhorn/printing-press-library update <slug> --bin-dir ~/.local/bin

Only fall back to go version -m , repo inspection, or direct .printing-press-release.json reads when the catalog entry lacks release metadata or the binary's version string is missing, non-semver-like, or otherwise suspicious. For example, Substack can be checked with substack-pp-cli --version locally and npx -y @mvanhorn/printing-press-library search substack --json remotely; update with npx -y @mvanhorn/printing-press-library update substack --bin-dir ~/.local/bin when the catalog version is newer.

update delegates to install semantics for that tool. update with no args discovers Printing Press CLIs currently on PATH and refreshes all of them, including their matching focused skills.

Because updates are idempotent, after a successful install or refresh, offer to create a recurring update job. Ask first; do not schedule it automatically. Prefer a single consolidated job over one job per CLI, because users may install many Printing Press tools and per-tool schedules become noisy fast.

For most users, schedule one quiet weekly job that refreshes every installed Printing Press CLI currently on PATH and its matching focused skill:

npx -y @mvanhorn/printing-press-library update

Use a per-tool scheduled command only when the user explicitly wants a separate cadence or policy for one tool:

npx -y @mvanhorn/printing-press-library update flight-goat

If the installed library CLI exposes reinstall, treat it as a convenience alias for update:

npx -y @mvanhorn/printing-press-library reinstall flight-goat

Example:

npx -y @mvanhorn/printing-press-library install flight-goat

Use the install line printed by search or list output. Do not synthesize harness-specific direct skill install commands as the default path; those are only for explicit skill-only workflows.

After install or update, assume the focused skill may not be visible to the currently running agent until skills are reloaded or the session restarts. Hermes CLI sessions can use /reload-skills or start a new session. Hermes gateway sessions should use /restart or hermes gateway restart. OpenClaw agents should restart the current session or gateway if the newly installed focused skill is not visible immediately.

Hermes-native usage

Hermes can make Printing Press more useful than a plain skill installer because Hermes has native skills, profiles, gateway sessions, cron jobs, memory, and toolsets. Use those primitives instead of treating Hermes like a generic chat harness.

Install and reload in Hermes

After installing or updating a focused tool, make sure Hermes can actually see the new skill before invoking it:

npx -y @mvanhorn/printing-press-library install <slug>

Then reload based on where Hermes is running:

• Hermes CLI: run /reload-skills if available, or start a fresh hermes session.
• Hermes gateway: run /restart in the gateway chat, or run hermes gateway restart from a shell.
• Named profiles: install and reload in the same profile that will use the skill. A skill installed under one Hermes home/profile may not be visible to another.

When checking a local Hermes install, useful commands are:

hermes skills list
hermes skills inspect <skill-or-url>
hermes config path
hermes config env-path
hermes profile list

Use these commands for diagnostics only. The catalog installer remains the default path for installing Printing Press catalog entries unless the user explicitly asks for a Hermes-only skill install.

Hermes profiles

Hermes profiles isolate config, skills, cron jobs, sessions, and memory. If the user mentions a profile, workspace, or separate assistant identity, do not assume the default profile.

Before diagnosing "skill not found" problems, check:

• which Hermes profile is active
• which HERMES_HOME the installer targeted
• whether the skill exists under that profile's skills/ directory
• whether the CLI or gateway was restarted after installation

A common failure mode is installing a focused skill into one profile and then trying to use it from another. That is not a Printing Press failure; it is an install-target mismatch.

Hermes toolsets

Most Printing Press CLIs require shell execution, so Hermes needs terminal access to run them. If Hermes cannot use a newly installed CLI, check whether the active platform/session has the terminal toolset enabled.

Do not enable broad tool access blindly. If the task only needs a built-in web/search/file tool, prefer the built-in tool over installing and running a third-party CLI.

Hermes cron updates

For Hermes users who want installed Printing Press tools kept current, recommend one consolidated scheduled update job rather than per-tool sprawl:

Schedule: weekly, quiet hours preferred
Prompt: Run `npx -y @mvanhorn/printing-press-library update`, summarize any changes, and stay quiet if nothing changed.

If using Hermes' cron tool or CLI, create the job only after explicit user approval. Recurring jobs are durable side effects.

A good Hermes cron prompt is self-contained:

Refresh installed Printing Press tools by running `npx -y @mvanhorn/printing-press-library update`. Report only updated tools, failures, or missing prerequisites. Do not print secrets. If nothing changed and there were no errors, say so briefly.

Use a per-tool schedule only when the user explicitly wants a different cadence or risk policy for one tool.

Hermes memory and session search

Hermes may remember durable user preferences, environment conventions, and known credential locations. Use that context to avoid making the user repeat setup details, but do not store volatile install results such as PR numbers, commit SHAs, one-off downloaded files, or "installed tool X today" as memory.

Good memory candidates after repeated Printing Press use:

• the user's preferred Hermes profile for tool installs
• stable secret-manager conventions
• a durable workspace path convention
• a recurring policy such as "prefer consolidated weekly updates over per-tool jobs"

Bad memory candidates:

• a specific temporary branch or PR number
• a one-time search result
• an installed version that will be stale soon
• raw API keys, cookies, tokens, or session headers

When the user asks what was installed or decided previously, prefer Hermes session search over guessing.

Search tactics

Use the library CLI as the default catalog index. Human-readable search cards include an install: line with the canonical install command:

npx -y @mvanhorn/printing-press-library search <keyword>

Use JSON when scripting or when structured ranking is useful:

npx -y @mvanhorn/printing-press-library search <keyword> --json

Examples:

npx -y @mvanhorn/printing-press-library search flights
npx -y @mvanhorn/printing-press-library search espn --json
npx -y @mvanhorn/printing-press-library list --category travel --json

Use repository inspection only as a fallback when npx is unavailable, when the CLI result is ambiguous, or when deeper README/SKILL details are needed before choosing a candidate:

rg -i "<service-or-capability>" registry.json library cli-skills

If the registry shape differs, prefer the npm CLI output instead of hand-parsing generated catalog files. Facts beat vibes; official interfaces beat archaeology.

Selection rules

Prefer a candidate when:

• It names the target service directly.
• Its README/SKILL examples match the user's requested job.
• It has documented auth and setup requirements the user can satisfy.
• It supports the user's OS/runtime.
• It can be verified with a harmless command before any external side effects.

Avoid a candidate when:

• It is only vaguely adjacent to the task.
• It requires credentials the user does not have.
• It is a scraper for a site where the user's task needs official-account data and the skill cannot authenticate.
• A safer built-in API/tool already solves the task.
• The task is high-risk, paid, public-facing, or privacy-sensitive and the user has not approved the external action.

Safety and credentials

• Never print API keys, cookies, tokens, or session headers.
• Do not ask the user to paste secrets into chat if a local secret manager or environment file is available.
• Treat third-party CLIs as code execution. Install only the focused tool needed for the task.
• Do not publish, post, email, buy, book, or mutate external state unless the user explicitly approves that action.

For Hermes users, prefer Hermes' normal environment file or the user's existing secret manager. To find the Hermes env path, use:

hermes config env-path

Confirm that required variables are present without echoing their values. If a focused skill says a key is optional or required only for one feature, preserve that distinction; do not make the whole tool sound credential-gated.

Verification checklist

Before reporting success:

• [ ] The selected candidate directly matches the user's requested job.
• [ ] The install command came from search, list, or documented Printing Press CLI behavior.
• [ ] The CLI was verified with --help or another harmless command.
• [ ] The agent harness was reloaded/restarted if a newly installed skill must be visible immediately.
• [ ] Required credentials were checked without printing secrets.
• [ ] No external side effect was performed without explicit approval.
• [ ] For Hermes, the relevant profile/session/gateway was considered when diagnosing visibility.

README behavior on ClawHub

ClawHub renders SKILL.md (or skill.md) as the skill readme. A separate README.md in the skill folder is not the published readme. Put user-facing ClawHub documentation in this file.