Skills mvanhorn cli-printing-press CLI Printing Press
printing-press
- Use it when:
- You want an agent-friendly command-line tool for an API or website, whether or not it publishes a spec.
- It does:
- Researches the API and competing CLIs and MCP servers, has you approve a feature list, generates and builds the Go code, then runs shipcheck and live tests.
- You get:
- A Go CLI with its README, SKILL.md and MCP server in your local press library, plus manuscripts: research brief, feature manifest, build log and test proofs.
- Runs:
- 21 phases, each read from its own file and logged in a receipt ledger; a run takes 30 to 60 minutes.
- Needs:
- The cli-printing-press binary and Go, and subagents; a browser only if you approve capturing a site.
- Asks first:
- Before browser capture and before building the feature list; publishing is left to printing-press-publish.
Skill 1 of 9 in the CLI Printing Press bundle, before printing-press-output-review.
Only works inside its bundle: Invokes printing-press-output-review and printing-press-polish on every run, so both must be installed alongside it. Install CLI Printing Press instead.
Needs the cli-printing-press binary and Go; a run takes 30 to 60 minutes. Capturing a site's traffic asks first and may install browser-use or agent-browser or drive your logged-in Chrome. Live tests use your API key when you give one. Every run invokes printing-press-polish, so install it alongside.
TL;DR
The main skill of CLI Printing Press, which drives its cli-printing-press generator. A preflight checks that the binary is installed and current, then it resolves the target from a name, URL, spec or HAR file and reuses earlier research when it's good enough. It writes a research brief and, when the docs fall short, offers to capture the site's hidden API in a browser, only with your consent, through browser-use, agent-browser, your Chrome via its extension, or a HAR you export. An absorb manifest then lists every feature of competing CLIs, MCP servers and skills, plus new ones a subagent proposes, for you to approve. It generates the Go code, builds every approved feature, runs shipcheck (dogfood, verify, skill and narrative checks and a scorecard), reviews the generated SKILL.md and README, has printing-press-output-review judge sampled command output, and runs a live test matrix against the real API, mandatory when you have a key. Every run calls printing-press-polish, then promotes the CLI to your library and archives the manuscripts. Secret values must never reach code, proofs or anything committed. The final menu offers publishing through printing-press-publish, another polish, or stopping.
Summarizes the skill at 94ce80e. Its SKILL.md has changed by 2 words since.
npx skills add https://github.com/mvanhorn/cli-printing-press --skill printing-press skills.sh pageSource on GitHubAll skills from mvanhorn/cli-printing-press
- Total Downloads
- 7,900 on skills.sh, Nov 9, 2026
- Repo stars
- 4,936 mvanhorn/cli-printing-press
- First seen
- May 7, 2026 on skills.sh
Weekly values
| Week to | Installs |
|---|---|
| Sep 21 | 157 |
| Sep 28 | 135 |
| Oct 5 | 180 |
| Oct 12 | 154 |
| Oct 19 | 169 |
| Oct 26 | 183 |
| Nov 2 | 164 |
| Nov 9 | 112 |
| Category |
Build agents, orchestrate workers and give agents memory. Test-first work, implementation from specs, git hygiene and scope control. Everything for building software: planning, coding, debugging, design, frameworks, cloud, agents and skills. |
|---|---|
| Type |
A multi-step process the agent follows: interview, debug, run a TDD loop, review. |
| Effect |
Its own steps create or change files, git state or local tools. |
| Needs |
A specific command-line tool or desktop app must be installed, such as gh, agent-browser, LibreOffice, Obsidian or a vendor CLI. Relies on the agent being able to spawn subagents. |
| Publisher |
A verified publisher on skills.sh, or the company or maintainer behind the product the skill operates. |
| Topics | |
| Stack |
SKILL.md
From mvanhorn/cli-printing-press at 7bf298b. Checked daily, last changed Nov 9, 2026.
Frontmatter
name: printing-press
description: Set up a new integration, connector, or CLI binding for any API. Wrap or generate a ship-ready Go CLI from an OpenAPI, HAR, or Postman spec via the lean research -> generate -> build -> shipcheck loop. Use when the user says build a CLI, wrap this API, set up a new integration, add a connector, integrate with a service, or names an API by domain.
version: 3.0.0
min-binary-version: "4.35.4"
allowed-tools:
- Bash
- Read
- Write
- Edit
- Glob
- Grep
- WebFetch
- WebSearch
- AskUserQuestion
- Agent
created_by: user/printing-press
Result: A working Go CLI in $PRESS_LIBRARY/<api-slug>/, plus up to five dense
manuscripts archived to $PRESS_MANUSCRIPTS/<api-slug>/<run-id>/: research brief,
absorb manifest, build log, shipcheck proof, and live smoke proof when live testing ran.
Next consumer: The user, who runs the CLI or ships it, and the sibling skills that
take it from here: printing-press-polish for a second pass, printing-press-publish
for the public library, printing-press-retro for findings against the Press itself.
Done: Every feature approved at the absorb gate is implemented, shipcheck reached ship, the live dogfood matrix ran against real targets, the CLI is promoted, and the receipt ledger closes on the last phase.
Intent: The best useful CLI for an API without an hour of phase theater. Optimize for time-to-ship, not time-to-document: reuse prior research when it is already good enough, run the cheap high-signal checks early, fix blockers before polish.
Boundaries
- Never leak a secret. API key values, token values, passwords, and session cookies must never reach source, manuscripts, proofs, READMEs, HARs, receipts, or anything committed. Env var names and placeholders are safe. Phase 5.6 and publish apply references/secret-protection.md.
- Never ship untested.
go buildandverifypass-rate are structural signals, not correctness signals. A CLI that has not been through the live matrix in phases/18-dogfood-testing.md is not shippable, and a bug a 1-3 file edit resolves is fixed now, not filed for v0.2. - Never quote human-time estimates for sub-tasks ("~15-30 min", "quick fix"). The agent does the work, not the user; describe scope instead. The carve-outs are the genuinely time-bound: the whole run (30-60 minutes), tool installs, and the network-bound printing-press subcommands.
- Never sequence from memory. The receipt ledger decides which phase comes next; see references/phase-receipts.md.
Authority
Invocation authorizes reading and writing under $PRESS_RUNSTATE/, $PRESS_LIBRARY/,
and $PRESS_MANUSCRIPTS/, running the printing-press binary and the Go toolchain, and
researching the API on the open web. It does not authorize publishing to the public
library, opening a pull request, or writing anywhere else on the user's machine.
Steps
Enter phases/01-preflight.md before any user-facing prompt, then read references/run-resolution.md: it resolves the API target, the briefing context, and the source priority for combo runs.
Never execute a phase from memory. When you enter a phase, Read its file from phases/ first.
Code orchestration in phases/10-generate.md serves reads on <api>_read and previews state-changing <api>_execute calls until confirm is boolean true.
Follow each file's final Next: pointer, and record the receipt handoff each phase
names. Late procedure lives in the phase file or a role-named reference it loads
(references/phase-receipts.md, references/codex-delegation.md,
references/fetch-docs.md). Do not restate those files here.