cli-printing-press README

The project's README from github.com/mvanhorn/cli-printing-press. As one markdown file: README.md.

CLI Printing Press

CI Golden Release Go License

Nothing is more valuable than time and money. In a world of AI agents, that's speed and token spend. A well-designed CLI is muscle memory for an agent: no hunting through docs, no wrong turns, no wasted tokens. We built the Printing Press to print the best CLIs in the world for agents.

It reads the official API docs, studies every popular community CLI and MCP server, sniffs the web for the APIs nobody published (think Google Flights or Dominos), and applies the power-user playbook Peter Steinberger proved with discrawl and gogcli - local SQLite, compound commands, agent-native flags. It fuses all of that and prints a token-efficient Go CLI plus a Claude Code skill plus an MCP server for any API or any website.

Three CLIs printed by the press, installable today:

Browse the full catalog of printed CLIs at printingpress.dev or in the Printing Press Library, organized by category, most with full MCP servers.

Codex users: see docs/CODEX.md to install the Printing Press skills with --agent codex, verify the install, and understand how that differs from /printing-press <api> codex.

Cursor users: see docs/CURSOR.md for how to install a printed CLI, attach the matching skill, handle auth, and choose CLI vs MCP when your repo does not already document a workflow.

Install

You need both the binary and the Printing Press skills. The skills (/printing-press <app>) are the primary interface; they drive the binary behind the scenes.

The binary alone works (research, generation, verification, scoring) but skips the curated agent loop. The skills alone have nothing to call. Install both.

Prerequisites: Go 1.26.6 or newer, Claude Code or another skills-supported agent, and Node/npm for npx. The skills are tested with Claude Code; install for Codex with --agent codex when you want to try the same slash-command workflow there. Use Claude Code for the best-tested experience.

1. Install

curl -fsSL https://raw.githubusercontent.com/mvanhorn/cli-printing-press/main/scripts/install.sh | bash

The installer runs go install for the generator binary, then refreshes all Printing Press skills through skills@latest add --skill '*'. Restart or reload your agent session after it completes so the refreshed skills are loaded.

Use --cli-only or --skills-only when you only want one side:

curl -fsSL https://raw.githubusercontent.com/mvanhorn/cli-printing-press/main/scripts/install.sh | bash -s -- --cli-only
curl -fsSL https://raw.githubusercontent.com/mvanhorn/cli-printing-press/main/scripts/install.sh | bash -s -- --skills-only

Claude Code is the default install target. To install or refresh the skills for Codex instead, pass --agent codex:

curl -fsSL https://raw.githubusercontent.com/mvanhorn/cli-printing-press/main/scripts/install.sh | bash -s -- --skills-only --agent codex
npx -y skills@latest list -g -a codex --json

See docs/CODEX.md for the Codex-specific notes.

Verify with cli-printing-press --version. If install fails, confirm Go 1.26.6 or newer is installed, Node/npm is installed for npx, and $GOPATH/bin is on your PATH.

Older releases installed a generator binary named printing-press. That legacy entrypoint still works for compatibility, but the canonical generator command is now cli-printing-press so the public library installer can own printing-press list, printing-press search, and printing-press install.

Manual install

Install or update the binary:

go install github.com/mvanhorn/cli-printing-press/v4/cmd/cli-printing-press@latest

Use Vercel's open-agent-skills CLI to install the Printing Press skills from this repo into a supported agent. Claude Code is the default and tested path:

npx -y skills@latest add mvanhorn/cli-printing-press/skills --skill '*' -g -a claude-code -y

For Codex:

npx -y skills@latest add mvanhorn/cli-printing-press/skills --skill '*' -g -a codex -y
npx -y skills@latest list -g -a codex --json

To refresh the skills later without naming individual skills, rerun the installer in skills-only mode:

curl -fsSL https://raw.githubusercontent.com/mvanhorn/cli-printing-press/main/scripts/install.sh | bash -s -- --skills-only

Restart or reload the target agent after refreshing skills so the new skill text is loaded.

Once installed, you can start Claude Code from any folder. Codex users should start a fresh Codex session after installing or refreshing skills.

Developer path: load skills from a clone

Use this if you're editing the Printing Press itself and want local skill changes to take effect on the next session start.

git clone https://github.com/mvanhorn/cli-printing-press.git
cd cli-printing-press
claude --plugin-dir .          # load this repo's skills directly
claude --plugin-dir . -w       # ...in a new git worktree (parallel runs)

For a persistent local setup that survives restarts and also loads in background sessions, see Local Plugin Development.

2. Start a printing session

claude

Then inside Claude Code:

/printing-press <app-name>

For example:

/printing-press Notion                       # Print a CLI for an API by name
/printing-press https://postman.com/explore  # ...or point at a website (no spec needed)
/printing-press-reprint notion               # Reprint an existing CLI under the latest machine

/printing-press drives the cli-printing-press binary you installed — research, generation, scoring, and shipcheck all run through it. Two parts, one workflow.

One command. Lean loop. Produces a Go CLI plus an MCP server that absorbs every feature from every competing tool, then transcends with compound use cases only possible with local data. REST, GraphQL, or browser-sniffed traffic. No OpenAPI spec required.

Each run produces two binaries (<api>-pp-cli plus <api>-pp-mcp), research documents, verification proofs, and a Quality Score.

Where output goes

By default, active and published output are separated:

  • Active managed runs work in ~/printing-press/.runstate/<scope>/runs/<run-id>/working/<api>-pp-cli
  • Published CLIs go to ~/printing-press/library/<api>
  • Archived manuscripts go to ~/printing-press/manuscripts/<api>/<run-id>/
  • Manuscripts are split into research/, proofs/, discovery/, and pipeline/

<scope> is derived from the current git checkout path, so parallel worktrees do not stomp on each other. If you pass --output, that overrides the generated CLI location for that command.

Codex mode (60% fewer Opus tokens)
/printing-press HubSpot codex    # Offload code generation to Codex CLI
/printing-press HubSpot          # Standard Opus mode (default)

When you add codex, Phase 3's code generation tasks are delegated to Codex CLI. Claude stays the brain (research, planning, scoring, review). Codex does the hands (writing Go code from scoped prompts). Same quality, 60% fewer Opus tokens. If Codex fails 3 times in a row, the press falls back to doing it locally, no manual intervention needed.

Improve an existing CLI (Polish)

Targeted fix-up. Diagnostics (dogfood, verify, scorecard, output review), fixes verify failures, removes dead code, cleans descriptions and READMEs, offers to publish. Auto-runs as Phase 5.5 of every generation; can also run standalone:

/printing-press-polish notion
Publish a CLI to the library

When you're happy with a CLI, publish it to the library:

/printing-press-publish linear   # Validates, packages, creates PR
Amend a published CLI from a dogfood session

After dogfooding a published CLI in a Claude Code session, turn the friction you hit (missing flags, hand-rolled API payloads, silent-null returns) into a PR for the public library. Mines the active session transcript, scopes the patch with you, plans + executes the fix autonomously, scrubs PII, and opens a PR — two checkpoints (scope, PR draft):

/printing-press-amend                # auto-detect target CLI from session
/printing-press-amend superhuman     # explicit target

Why these CLIs win

Most generators wrap endpoints and stop. Printing Press generates CLIs that understand the domain.

Local-first data layer. High-gravity resources get domain-specific SQLite tables (not JSON blobs), FTS5 full-text search indexes, and incremental sync with cursor tracking. sync pulls data down. search finds it in milliseconds. sql lets power users query directly. All offline, all local.

Machine-owned freshness. Store-backed CLIs can opt into a bounded pre-read refresh via cache.enabled so --data-source auto keeps the local store current without a manual sync. --data-source local and --data-source live give you full control.

Compound commands no wrapper can do. Once data lives in SQLite, commands like stale, health, bottleneck, and reconcile become possible - they join across resources and analyze history. A stateless API wrapper literally cannot do this.

Agent-native by default. Human-friendly tables when you're in a terminal. Auto-JSON when piped, no --json flag needed. --compact drops to high-gravity fields only (60-80% fewer tokens). Typed exit codes (0/2/3/4/5/7) let agents self-correct without parsing error text. --dry-run for safe exploration. Every flag exists because an AI agent will call it thousands of times a day.

No spec? No problem. Don't have an OpenAPI spec? Point the press at a website. It launches a browser, captures traffic, reverse-engineers the API, and generates the spec for you. ESPN, Postman Explore, internal tools - if you can click through it, the press can build a CLI for it.

Dual interface from one spec. Every API gets a Cobra CLI (<api>-pp-cli) and an MCP server (<api>-pp-mcp). Same client, same store, same auth. Shell agents use the CLI. IDE agents use MCP. Zero code duplication.

Verified, not vibes. Four mechanical checks - scorecard, dogfood, proof-of-behavior, live API smoke test - catch hallucinated paths, dead flags, auth mismatches, and broken data pipelines before you ship.

Credits its sources. Every generated README includes a Sources and Inspiration section that credits the ecosystem tools studied during research. We built on giants' shoulders and we say so.

The non-obvious insight

Every API has a secret identity. The data it exposes is useful for something its creators never designed for. The printing press finds that secret and builds a CLI around it.

The Non-Obvious Insight (NOI) is a one-sentence reframe:

"[API] isn't just [obvious thing]. It's [non-obvious thing].
 Every [data point] is a signal about [hidden truth]."
API What they think it is What it actually is
Discord A chat app A searchable knowledge base. Every message thread is institutional memory.
Linear An issue tracker A team behavior observatory. Every state change is a signal about how your team actually works vs. how they think they work.
Stripe A payment processor A business health monitor. Every failed charge and churn event is a signal about product-market fit.
GitHub A code host An engineering culture fingerprint. Every review turnaround and merge pattern is a signal about how your team ships.
Notion A doc editor A knowledge decay detector. Every stale page and orphaned database is a signal about what your team has forgotten.
HubSpot A CRM Your company's relationship memory. Every deal stage transition, email open, and meeting log is a signal about pipeline health and rep performance.
Slack Messaging An organizational nervous system. Every response time and channel silence is a signal about team health.
ESPN Sports data A betting intelligence terminal. Every injury report, lineup change, and odds movement is a signal about game outcomes.

The NOI is the creative DNA of every CLI the press generates. Phase 0 cannot complete without one. If the LLM can't write an NOI, the research wasn't deep enough.

The printing press automates what Steinberger does intuitively: look at an API, see what power users actually do with it, and build the commands that matter. Then also wrap every endpoint for completeness.

The thinking behind it

Every endpoint. Every insight. One command.

Discord's API has 300+ endpoints. Most generators stop there - wrap every endpoint, ship it, done. But discrawl - Peter Steinberger's Discord tool - ignores most of them. It ships 11 commands: sync, search, sql, tail, mentions, members. 583 stars.

Why does the 11-command tool win? Because Steinberger saw something Discord's own API designers didn't: conversations are institutional knowledge. Every message thread is a document that should be archived, indexed, and searched locally. Those 11 commands embody that insight. The 300 endpoint wrappers don't.

Until now, you had to choose: breadth (wrap every endpoint) or depth (understand the user). The printing press eliminates that choice. It generates the full API surface AND matches every feature the top competitor has AND adds the discrawl-style intelligence layer AND an MCP server. One spec in. Everything out.

Absorb and transcend

The GOAT CLI isn't built by finding gaps. It's built by absorbing every good idea and compounding on top.

Layer 1, absorb. Before generating, the ecosystem absorb gate catalogs every feature from every Claude Code plugin, MCP server, community skill, competing CLI, and automation script for your API. Every feature becomes a row in the absorb manifest, something our CLI must match AND beat with offline support, agent-native output, and SQLite persistence. The system even auto-suggests novel features it thinks are missing from the ecosystem before you approve the manifest.

Layer 2, transcend. Once you have everything in SQLite, compound use cases emerge that no stateless tool can do. Velocity tracking requires historical cycle data. Churn risk requires joining charges + subscriptions. Bottleneck detection requires the full issue relationship graph. These are the Non-Obvious Insight commands, and they only work because Layer 1 put everything in a local database.

The GOAT = everything everyone else does + everything nobody else thought of.

The creativity ladder

Most API CLIs stop at Rung 1. The printing press climbs to Rung 5.

Rung What it is Auto-generated? Example
1 API wrapper commands Yes (from spec) issue create --title "..."
2 Output formatting Yes (always) --json, --select, --csv, --dry-run
3 Local persistence Yes (conditional) sync, search, export, tail
4 Domain analytics Yes (from archetype) stale --days 30, orphans, load
5 Behavioral insights Yes (from archetype) health (composite score), similar (duplicate detection)

Rung 3 is table stakes. Rung 4 is where discrawl lives. Rung 5 is where nobody else is yet.

The press generates the API wrapper in Phase 2 (Rung 1-2). Then it generates the discrawl-style data layer and workflow commands in Phase 3 (Rung 3-5) from domain archetype templates. Both in one run.

How we knew this was real

When choosing between Peter Steinberger's gogcli (6.5K+ stars, Go) and Google's official Workspace CLI (10K+ stars in a week, Rust), we ran /last30days - a recency research skill - across 34 X posts, 5 YouTube videos, and 10 web sources.

The verdict: use gogcli. The newer, official tool with 10x the API coverage lost to the older third-party one. As one user put it: "my preference is 100% gogcli since I have my agent working a lot with Google Docs and sheets, and gogcli just makes him able to do what he needs to do."

Breadth doesn't beat depth. Understanding the user beats understanding the API.

Why CLIs plus MCP

The NOI is the creative intelligence. The printing press generates both interfaces from one spec:

Same internal/client, same internal/store, same auth. Two binaries, zero code duplication.

CLIs win for agents. 100x fewer tokens than MCP tool definitions. LLMs were trained on shell interactions. Exit code 0 = done. --json | jq is a first-class composition pattern.

MCP wins for IDE integration. Claude Desktop and Cursor discover tools automatically via MCP. No shell needed. The MCP server exposes the same operations as the CLI, including the data layer (sync, search, sql).

One spec  ->  cli-printing-press generate  ->  <api>-pp-cli (cobra)  +  <api>-pp-mcp (MCP server)
                                            |                       |
                                            same internal/client, internal/store

Every API that gets a CLI+MCP becomes instantly accessible to every AI coding tool. The printing press is the factory.

How it works

The fast path is a lean loop. Artifacts still matter, but only when they directly improve the next phase.

Phase 0     Resolve + Reuse           (1-3 min)    Reuse research, detect tokens, resolve spec or URL
Phase 1     Research Brief            (5-10 min)   API identity, competitors, data layer, product thesis
Phase 1.5   Ecosystem Absorb Gate     (5-10 min)   Catalog every MCP/skill/CLI feature -> absorb manifest + novel suggestions
Phase 1.7   Browser-Sniff Gate        (2-5 min)    Browser capture, HAR import, discovery provenance
Phase 2     Generate                  (1-2 min)    Go CLI + MCP server from spec with validation
Phase 3     Build The GOAT            (10-20 min)  ALL absorbed featu

cli-printing-press (mvanhorn/cli-printing-press)

Searching Database…

这是什么?CLI Printing Press 是一个生成器:它会研究某个 API(其文档、所有同类 CLI、MCP 服务器和技能,甚至是没有任何公开 API 的网站),然后为它生成一个省 token 的 Go CLI、配套的 MCP 服务器和一个 Claude Code 技能,专为 AI 代理每天调用成千上万次而打造。
这是单个 CLI 工具,还是能造出其他 CLI 的东西?它是一个生成器:每次运行会为目标 API 产出两个新的二进制文件(一个 `-pp-cli` 和一个 `-pp-mcp`),外加研究文档、验证证明和质量评分,而不是单一的固定工具。
怎么把它跑起来?安装器会为 `cli-printing-press` 生成器二进制运行 `go install`,然后通过 `skills@latest add` 把 Printing Press 技能安装到 Claude Code。重启代理会话后,在 Claude Code 中运行 `/printing-press ` 即可开始一次生成会话。
在它工作之前需要装好什么?你需要 Go 1.26.6 或更高版本、Node/npm(用于 npx),以及一个支持技能的代理——Claude Code 是经过测试的默认选择,Codex 也可通过 `--agent codex` 支持。
它必须有官方 OpenAPI 规范才能工作吗?不需要——如果 API 没有公开规范,印刷机会启动浏览器、捕获流量并自行逆向分析 API,ESPN 就是这么做的。质量仍取决于生成早期的一个“非显而易见洞见”(Non-Obvious Insight)步骤;如果模型说不清这个 API 究竟暗藏着什么用处,该阶段就无法完成。
它是为谁打造的?面向希望在 Claude Code 或 Codex 中为其所用 API 获得代理就绪的 CLI 和 MCP 服务器的开发者,省得为每个端点手写封装。
生成的 CLI 的数据存在哪里?生成的 CLI 会把 API 数据同步到本地 SQLite 存储(带 FTS5 全文搜索和基于游标的增量同步),查询直接在这份本地存储上进行,而不是每次都请求 API。
它一直提到的“非显而易见洞见”是什么?它是用一句话重新定义某个 API 在其表面用途之外暗藏的价值——例如把 Discord 看作可搜索的机构知识库,而不是“一个聊天应用”。每个生成的 CLI 的组合命令都源于这一洞见。
Codex 模式是做什么的?在会话中加入 `codex` 会把第 3 阶段的代码生成任务委托给 Codex CLI,而 Claude 仍负责研究、规划和评分,可将 Opus 的 token 用量降低约 60%。如果 Codex 连续失败三次,就会回退为在本地完成工作。
为什么它同时构建 CLI 和 MCP 服务器?这样基于 shell 的代理可以调用 Cobra CLI,基于 IDE 的代理可以调用 MCP,两者共享完全相同的客户端、本地存储和认证逻辑,零代码重复。
可以直接使用已经生成好的 CLI,而不自己生成吗?可以——ESPN、flight-goat、linear-pp-cli 等已生成的 CLI 现在就可安装,按类别列在 Printing Press Library 和 printingpress.dev 上。
Creator
mvanhorn
Size
64.5 MB
Stars
4.8K
Age
6mo
Commits · 90 Days