PluginBench
Skill
Review
Audit score 70

printing-press

mvanhorn/cli-printing-press

Generate ship-ready Go CLIs from OpenAPI, HAR, or Postman specs via structured research-generate-build-test loop.

What is printing-press?

Printing Press automates the creation of production-ready Go CLI bindings for any API. It guides you through a 21-phase workflow—from API research and spec absorption through code generation, testing, and promotion—ensuring the CLI is tested against live targets before shipment.

  • Generate Go CLI source from OpenAPI, HAR, or Postman API specifications
  • Research and validate API reachability, authentication, and ecosystem compatibility before generation
  • Build and verify the CLI with automated shipcheck gates and live dogfood testing
  • Archive research briefs, build logs, and test proofs for each run
  • Promote tested CLIs to a library and prevent shipping untested code
  • Reuse prior research and specs when available to accelerate multi-API runs

How to install printing-press

npx skills add https://github.com/mvanhorn/cli-printing-press --skill printing-press
Prerequisites
  • Go toolchain installed (version compatible with generated code)
  • OpenAPI, HAR, or Postman specification for the target API
  • Network access to research the API and run live testing
  • Bash shell for running the printing-press binary
Claude Code
Cursor
Windsurf
Cline

How to use printing-press

  1. 1.Run the skill and provide the API name, domain, or specification file when prompted
  2. 2.The skill enters preflight checks and initializes the run state
  3. 3.Follow the 21-phase workflow: research gates validate the API, generation creates the CLI, build and shipcheck verify correctness
  4. 4.Review archived manuscripts (research brief, build log, test proofs) in $PRESS_MANUSCRIPTS
  5. 5.Run the generated CLI from $PRESS_LIBRARY/<api-slug>/ or ship it to your target environment
  6. 6.Use sibling skills (printing-press-polish, printing-press-publish) for refinement or public release

Use cases

Good for
  • Wrap a third-party REST API into a usable command-line tool for your team
  • Build internal CLI connectors for SaaS integrations without manual coding
  • Generate multiple API bindings in sequence, reusing research across similar services
  • Test a new API integration against live endpoints before committing to production
  • Create ship-ready CLIs that pass automated correctness and security checks
Who it's for
  • Backend engineers building internal tools and integrations
  • DevOps and platform teams automating API access
  • Developers wrapping public APIs into CLI form
  • Teams standardizing CLI generation across multiple services

printing-press FAQ

What happens if the API is unreachable or the spec is invalid?

The skill runs reachability and ecosystem gates (phases 9, 8) that block generation if critical checks fail. You can fix the spec or API access and re-run; prior research is reused if still valid.

Can I use this for APIs without an OpenAPI spec?

Yes. The skill accepts HAR (HTTP Archive) files or Postman collections as input. You can also provide the API domain and let the skill research and extract the spec.

Are secrets safe in the generated CLI and manuscripts?

Yes. The skill enforces strict secret protection: API key values, tokens, and passwords never reach source code, READMEs, or archived files. Only environment variable names and placeholders are used.

How long does a full run take?

A typical run takes 30–60 minutes, depending on API complexity and live testing scope. Research reuse and early gate failures can reduce time significantly.

What if the generated CLI has bugs?

The skill runs live dogfood testing (phase 18) against real API endpoints. Small bugs caught there are fixed immediately (1–3 file edits) before promotion; larger issues block shipment.

Full instructions (SKILL.md)

Source of truth, from mvanhorn/cli-printing-press.


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.0.0" 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 build and verify pass-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.

StepFile
1phases/01-preflight.md
2phases/02-run-initialization.md
3phases/03-resolve-and-reuse.md
4phases/04-research-brief.md
5phases/05-pre-browser-sniff-auth-intelligence.md
6phases/06-browser-sniff-gate.md
7phases/07-crowd-sniff-gate.md
8phases/08-ecosystem-absorb-gate.md
9phases/09-api-reachability-gate.md
10phases/10-generate.md
11phases/11-build-the-goat.md
12phases/12-shipcheck.md
13phases/13-sync-param-drop-gate.md
14phases/14-agentic-skill-review.md
15phases/15-readme-skill-agents-correctness-audit.md
16phases/16-agentic-output-review.md
17phases/17-local-code-review.md
18phases/18-dogfood-testing.md
19phases/19-polish.md
20phases/20-promote-and-archive.md
21phases/21-next-steps.md

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.