The catalog says 574 CLIs and warns not to edit the line

The count is generated, and the file says not to edit it

The most important line on the page is a comment. The catalog counts block reads 574 CLIs across 22 categories, and it is bracketed by markers saying the line is generated by tools/generate-registry and must not be hand-edited. The catalog table further down carries the same instruction at its start and end markers. So the size of this project and the shape of its documentation are both machine-maintained: a script reads registry.json and rewrites the sections, and a human editing either block will have their change overwritten. That is the right design for a catalog of hundreds of entries, and it also means the README is a rendering of registry.json rather than an independent description. Everything the table shows, from the category path to the focused skill path to the latest build link, is derived from that one file, which is also what the installer reads.

Every tool carries its own -current tag

The project does not have one version stream. Each tool carries its own tag, and the newest entries show the pattern: uber-jobs-current at 2026-10-06, toretabi-current at 2026-10-05 and tabiwa-current on the same day, each named after the tool with a -current suffix. The catalog table links each row to a tag of that shape, so what a row shows is the version of that one tool rather than of the catalog. The last push to the default branch was on 2026-10-06, matching the newest tag, so tags are cut as part of the ordinary publishing flow rather than in a batch. Two consequences follow. A user who wants to be current with one tool can track that tool's tag without taking everything else. And a user who wants a stable catalog has to make that choice per row, because there is no aggregate version to pin and nothing in the README says which tags are considered stable.

One command installs a binary and a skill together

The install path is npm, and the unit of installation is a pair.

npx -y @mvanhorn/printing-press-library install starter-pack

That command installs a starter pack of four hand-picked tools, and the -y flag only suppresses the interactive npm prompt. The starter pack is espn for live sports, flight-goat for flight search, movie-goat for movie discovery and recipe-goat for recipe ranking. Every install pulls the Go binary and the focused skill in one shot, and you can take just one half with --cli-only or --skill-only. One tool is the same command with a single name, and several at once is the same command with several names, with bundles and CLI names mixing freely, so install espn sentry dub and install starter-pack cal-com both work. The package name changed: @mvanhorn/printing-press-library replaces the older @mvanhorn/printing-press, and the unambiguous printing-press-library binary is the catalog installer for browsing, searching, installing and keeping tools fresh.

Pinning is to a commit, with an exception that matters

The installer is described as a thin orchestrator that reads the live catalog in registry.json, resolves each CLI's Go module path, and pins released Go CLI builds to the catalog's full source_commit, falling back to @latest only for legacy entries that have no build metadata. The stated purpose is to prevent accidental drift from a later main-branch update. That exception is the part to notice: legacy entries without build metadata float, so for those tools you get whatever is newest at install time. What this does not do is stated just as plainly. Pinning does not authenticate the mutable live catalog, and it does not authenticate the separately versioned skill installer. So the pinning story covers one of three moving parts, and the sentence naming the gap is the honest boundary of the guarantee. Install also accepts catalog slugs and generated binary names, so both airbnb and airbnb-pp-cli resolve to the same Airbnb tool.

Some tools sniff a website because no API exists

The three tools suggested as starting points each illustrate a different approach, and the labels on them matter. ESPN is marked sniffed with no official API, framed as one call that returns tonight's NBA playoff games with live score, series state, each team's leading scorer stat line and injury or lineup news from the last 24 hours. flight-goat combines Kayak nonstop search with sniffed Google Flights, answering a non-stop flight query for four people over eight hours from Seattle for a date range, cheapest first, from two sources in one query. sentry-pp-cli is described as a local SQLite mirror with SQL across orgs and projects, answering compound queries that the Sentry API itself cannot answer. So the catalog spans three shapes: scraped front ends, federated search across commercial sources, and a local database you can query with SQL. The first two carry the risk that the pages they read change, and the third carries the cost of maintaining the mirror.

Four harnesses, four ways to install the same skill

The discovery layer exists separately from the binaries, and the README enumerates harness after harness because each has its own installer. A discovery skill that lets an agent search the catalog and choose a focused pp-* skill is installed first for OpenClaw, Hermes, Claude Code, Codex, Cursor or anything else supporting agent skills. OpenClaw users run clawhub install printing-press-library. Harnesses compatible with Vercel Agent Skills run npx skills add pointing at either the skills/ path for discovery or the cli-skills/ path for one focused tool, with a -g -y pair for global non-interactive install, and the same installer from the repository root when you select the catalog skill explicitly. Hermes has its own command, hermes skills install, and also a slash command inside its chat TUI. The catalog installer remains the path for humans, scripts and CLI-first setup, and its discovery commands print human-readable cards by default with a --json flag for scripts and agents.

Where the catalog is the wrong choice

Four cases. Anyone who needs to audit the data path is out of scope. An entry described as sniffed has no official API behind it, so the reliability and the terms of use both come from a web page nobody guarantees will keep its shape, and a tool that parses HTML is one markup change away from returning wrong answers quietly. The second is a security review. A .gitleaksignore file at the repository root tells you the project has thought about secret scanning and has an allowlist, and the skills come from many contributors, so installing a skill from this catalog is installing code from many authors into an agent harness that may have file and shell access. Reproducibility across time fails for the same reason. Pinning is per tool, legacy entries float, and the catalog itself is mutable and unauthenticated, so a rebuild six months later is not the same set of binaries. Fourth is a project that only needs one integration. If you need one API, writing the client yourself against the vendor's documentation is smaller than adopting a catalog, a skill system and four harness installers.

Editorial conclusion

The catalog suits an agent harness that needs a focused command per data source rather than a general-purpose HTTP client, and a developer who wants the binary and its skill installed together. It does not suit anyone who needs a source you can audit, since several entries are described as sniffed where no official API exists. Before adopting, read the entry for the tool you want in registry.json, check whether its data comes from an official API, and pin deliberately knowing that legacy entries fall back to a floating tag.

Frequently asked questions

Official sources

1. Issues
2. mvanhorn/printing-press-library on GitHub
3. README
4. Releases