[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-74638":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":9,"language":10,"languages":9,"totalLinesOfCode":9,"stars":11,"forks":12,"watchers":13,"openIssues":14,"contributorsCount":15,"subscribersCount":15,"size":15,"stars1d":16,"stars7d":17,"stars30d":18,"stars90d":15,"forks30d":15,"starsTrendScore":19,"compositeScore":20,"rankGlobal":9,"rankLanguage":9,"license":21,"archived":22,"fork":22,"defaultBranch":23,"hasWiki":22,"hasPages":22,"topics":24,"createdAt":9,"pushedAt":9,"updatedAt":31,"readmeContent":32,"aiSummary":33,"trendingCount":15,"starSnapshotCount":15,"syncStatus":34,"lastSyncTime":35,"discoverSource":36},74638,"cli-printing-press","mvanhorn\u002Fcli-printing-press","mvanhorn","Every API has a secret identity. This finds it, absorbs every feature from every competing tool, then builds the GOAT CLI — designed for AI agents first, with SQLite sync, offline search, and compound insight commands.",null,"Go",3179,331,10,134,0,251,490,743,753,29.56,"MIT License",false,"main",[25,26,27,28,29,30],"ai-agents","cli","cli-generator","developer-tools","golang","openapi","2026-06-12 02:03:26","# CLI Printing Press\n\n[![CI](https:\u002F\u002Fgithub.com\u002Fmvanhorn\u002Fcli-printing-press\u002Factions\u002Fworkflows\u002Flint.yml\u002Fbadge.svg)](https:\u002F\u002Fgithub.com\u002Fmvanhorn\u002Fcli-printing-press\u002Factions\u002Fworkflows\u002Flint.yml)\n[![Golden](https:\u002F\u002Fgithub.com\u002Fmvanhorn\u002Fcli-printing-press\u002Factions\u002Fworkflows\u002Fgolden.yml\u002Fbadge.svg)](https:\u002F\u002Fgithub.com\u002Fmvanhorn\u002Fcli-printing-press\u002Factions\u002Fworkflows\u002Fgolden.yml)\n[![Release](https:\u002F\u002Fimg.shields.io\u002Fgithub\u002Fv\u002Frelease\u002Fmvanhorn\u002Fcli-printing-press?display_name=tag&sort=semver)](https:\u002F\u002Fgithub.com\u002Fmvanhorn\u002Fcli-printing-press\u002Freleases)\n[![Go](https:\u002F\u002Fimg.shields.io\u002Fgithub\u002Fgo-mod\u002Fgo-version\u002Fmvanhorn\u002Fcli-printing-press)](go.mod)\n[![License](https:\u002F\u002Fimg.shields.io\u002Fgithub\u002Flicense\u002Fmvanhorn\u002Fcli-printing-press)](LICENSE)\n\nNothing 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.\n\nIt 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](https:\u002F\u002Fgithub.com\u002Fsteipete\u002Fdiscrawl) and [gogcli](https:\u002F\u002Fgithub.com\u002Fsteipete\u002Fgogcli) - 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.\n\nThree CLIs printed by the press, installable today:\n\n- ESPN (sniffed, no official API). _\"Tonight's NBA playoff games with live score, series state, each team's leading scorer's stat line, and any injury or lineup news from the last 24 hours.\"_ Returns everything in one call.\n- flight-goat (Kayak nonstop search plus sniffed Google Flights). _\"Non-stop flights over 8 hours from Seattle for 4 people, Dec 24 to Jan 1, cheapest first.\"_ Two sources stitched into one query.\n- linear-pp-cli (50ms against a local SQLite mirror). _\"Every blocked issue whose blocker has been stuck for a week.\"_ Compound queries the API can't answer.\n\nBrowse the full catalog of printed CLIs at [printingpress.dev](https:\u002F\u002Fprintingpress.dev) or in the [Printing Press Library](https:\u002F\u002Fgithub.com\u002Fmvanhorn\u002Fprinting-press-library), organized by category, most with full MCP servers.\n\n**Cursor users:** see [docs\u002FCURSOR.md](docs\u002FCURSOR.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.\n\n## Install\n\nYou need both the **binary** and the **Claude Code skills**. The skills (`\u002Fprinting-press \u003Capp>`) are the primary interface; they drive the binary behind the scenes.\n\nThe binary alone works (research, generation, verification, scoring) but skips the curated agent loop. The skills alone have nothing to call. Install both.\n\n**Prerequisites:** [Go 1.26.3 or newer](https:\u002F\u002Fgo.dev\u002Fdl\u002F) and [Claude Code](https:\u002F\u002Fclaude.ai\u002Fcode). The skills are tested with Claude Code; other harnesses like Codex may work but aren't tested. **Use Claude Code for the best experience.**\n\n### 1. Install the binary\n\n```bash\ngo install github.com\u002Fmvanhorn\u002Fcli-printing-press\u002Fv4\u002Fcmd\u002Fprinting-press@latest\n```\n\nVerify with `printing-press --version`. If `go install` fails, confirm Go 1.26.3 or newer is installed and `$GOPATH\u002Fbin` is on your `PATH`.\n\n### 2. Install the skills — pick one path\n\n**Recommended: clone the repo.** Simplest, gets you the bleeding edge as it ships, and `git pull` is your update mechanism.\n\n```bash\ngit clone https:\u002F\u002Fgithub.com\u002Fmvanhorn\u002Fcli-printing-press.git\n```\n\n\u003Cdetails>\n\u003Csummary>\u003Cb>Alternative: install just the skills (no clone)\u003C\u002Fb>\u003C\u002Fsummary>\n\nUse this if you don't want a local clone. You'll need to run an explicit `update` command to pull newer skills.\n\n**With GitHub CLI (`gh` v2.90+):**\n\n```bash\ngh skill install mvanhorn\u002Fcli-printing-press --agent claude-code --scope user\ngh skill update                                # update later\n```\n\n**Without `gh` — use Vercel's [open-agent-skills](https:\u002F\u002Fwww.npmjs.com\u002Fpackage\u002Fskills):**\n\n```bash\nnpx skills add mvanhorn\u002Fcli-printing-press\u002Fskills -g -a claude-code -y\nnpx skills update                              # update later\n```\n\nOnce installed, you can run `claude` from any folder.\n\n\u003C\u002Fdetails>\n\n### 3. Start a printing session\n\nIf you cloned the repo, run from the repo root:\n\n```bash\nclaude --plugin-dir .          # load this repo's skills directly\nclaude --plugin-dir . -w       # ...in a new git worktree (parallel runs)\n```\n\nIf you installed skills only, run `claude` from any folder.\n\nThen inside Claude Code:\n\n```text\n\u002Fprinting-press \u003Capp-name>\n```\n\nFor example:\n\n```text\n\u002Fprinting-press Notion                       # Print a CLI for an API by name\n\u002Fprinting-press https:\u002F\u002Fpostman.com\u002Fexplore  # ...or point at a website (no spec needed)\n\u002Fprinting-press-reprint notion               # Reprint an existing CLI under the latest machine\n```\n\n`\u002Fprinting-press` drives the `printing-press` binary you installed — research, generation, scoring, and shipcheck all run through it. Two parts, one workflow.\n\nOne 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.\n\nEach run produces two binaries (`\u003Capi>-pp-cli` plus `\u003Capi>-pp-mcp`), research documents, verification proofs, and a Quality Score.\n\n\u003Cdetails>\n\u003Csummary>\u003Cb>Where output goes\u003C\u002Fb>\u003C\u002Fsummary>\n\nBy default, active and published output are separated:\n\n- Active managed runs work in `~\u002Fprinting-press\u002F.runstate\u002F\u003Cscope>\u002Fruns\u002F\u003Crun-id>\u002Fworking\u002F\u003Capi>-pp-cli`\n- Published CLIs go to `~\u002Fprinting-press\u002Flibrary\u002F\u003Capi>`\n- Archived manuscripts go to `~\u002Fprinting-press\u002Fmanuscripts\u002F\u003Capi>\u002F\u003Crun-id>\u002F`\n- Manuscripts are split into `research\u002F`, `proofs\u002F`, `discovery\u002F`, and `pipeline\u002F`\n\n`\u003Cscope>` 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.\n\n\u003C\u002Fdetails>\n\n\u003Cdetails>\n\u003Csummary>\u003Cb>Codex mode (60% fewer Opus tokens)\u003C\u002Fb>\u003C\u002Fsummary>\n\n```bash\n\u002Fprinting-press HubSpot codex    # Offload code generation to Codex CLI\n\u002Fprinting-press HubSpot          # Standard Opus mode (default)\n```\n\nWhen 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.\n\n\u003C\u002Fdetails>\n\n\u003Cdetails>\n\u003Csummary>\u003Cb>Improve an existing CLI (Polish)\u003C\u002Fb>\u003C\u002Fsummary>\n\nTargeted 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:\n\n```bash\n\u002Fprinting-press-polish notion\n```\n\n\u003C\u002Fdetails>\n\n\u003Cdetails>\n\u003Csummary>\u003Cb>Publish a CLI to the library\u003C\u002Fb>\u003C\u002Fsummary>\n\nWhen you're happy with a CLI, publish it to the library:\n\n```bash\n\u002Fprinting-press-publish linear   # Validates, packages, creates PR\n```\n\n\u003C\u002Fdetails>\n\n\u003Cdetails>\n\u003Csummary>\u003Cb>Amend a published CLI from a dogfood session\u003C\u002Fb>\u003C\u002Fsummary>\n\nAfter 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):\n\n```bash\n\u002Fprinting-press-amend                # auto-detect target CLI from session\n\u002Fprinting-press-amend superhuman     # explicit target\n```\n\n\u003C\u002Fdetails>\n\n## Why these CLIs win\n\nMost generators wrap endpoints and stop. Printing Press generates CLIs that understand the domain.\n\nLocal-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.\n\nMachine-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.\n\nCompound 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.\n\nAgent-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`\u002F`2`\u002F`3`\u002F`4`\u002F`5`\u002F`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.\n\nNo 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.\n\nDual interface from one spec. Every API gets a Cobra CLI (`\u003Capi>-pp-cli`) and an MCP server (`\u003Capi>-pp-mcp`). Same client, same store, same auth. Shell agents use the CLI. IDE agents use MCP. Zero code duplication.\n\nVerified, 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.\n\nCredits 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.\n\n## The non-obvious insight\n\nEvery 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.\n\nThe Non-Obvious Insight (NOI) is a one-sentence reframe:\n\n```\n\"[API] isn't just [obvious thing]. It's [non-obvious thing].\n Every [data point] is a signal about [hidden truth].\"\n```\n\n| API | What they think it is | What it actually is |\n|-----|----------------------|---------------------|\n| Discord | A chat app | A searchable knowledge base. Every message thread is institutional memory. |\n| 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. |\n| Stripe | A payment processor | A business health monitor. Every failed charge and churn event is a signal about product-market fit. |\n| GitHub | A code host | An engineering culture fingerprint. Every review turnaround and merge pattern is a signal about how your team ships. |\n| Notion | A doc editor | A knowledge decay detector. Every stale page and orphaned database is a signal about what your team has forgotten. |\n| 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. |\n| Slack | Messaging | An organizational nervous system. Every response time and channel silence is a signal about team health. |\n| ESPN | Sports data | A betting intelligence terminal. Every injury report, lineup change, and odds movement is a signal about game outcomes. |\n\nThe 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.\n\nThe 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.\n\n## The thinking behind it\n\n### Every endpoint. Every insight. One command.\n\nDiscord's API has 300+ endpoints. Most generators stop there - wrap every endpoint, ship it, done. But [discrawl](https:\u002F\u002Fgithub.com\u002Fsteipete\u002Fdiscrawl) - Peter Steinberger's Discord tool - ignores most of them. It ships 11 commands: `sync`, `search`, `sql`, `tail`, `mentions`, `members`. 583 stars.\n\nWhy 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.\n\nUntil 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.\n\n### Absorb and transcend\n\nThe GOAT CLI isn't built by finding gaps. It's built by absorbing every good idea and compounding on top.\n\nLayer 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.\n\nLayer 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.\n\nThe GOAT = everything everyone else does + everything nobody else thought of.\n\n### The creativity ladder\n\nMost API CLIs stop at Rung 1. The printing press climbs to Rung 5.\n\n| Rung | What it is | Auto-generated? | Example |\n|------|-----------|-----------------|---------|\n| 1 | API wrapper commands | Yes (from spec) | `issue create --title \"...\"` |\n| 2 | Output formatting | Yes (always) | `--json`, `--select`, `--csv`, `--dry-run` |\n| 3 | Local persistence | Yes (conditional) | `sync`, `search`, `export`, `tail` |\n| 4 | Domain analytics | Yes (from archetype) | `stale --days 30`, `orphans`, `load` |\n| 5 | Behavioral insights | Yes (from archetype) | `health` (composite score), `similar` (duplicate detection) |\n\nRung 3 is table stakes. Rung 4 is where discrawl lives. Rung 5 is where nobody else is yet.\n\nThe 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.\n\n### How we knew this was real\n\nWhen choosing between Peter Steinberger's [gogcli](https:\u002F\u002Fgithub.com\u002Fsteipete\u002Fgogcli) (6.5K+ stars, Go) and Google's official [Workspace CLI](https:\u002F\u002Fgithub.com\u002Fgoogleworkspace\u002Fcli) (10K+ stars in a week, Rust), we ran [\u002Flast30days](https:\u002F\u002Fgithub.com\u002Fmvanhorn\u002Flast30days-skill) - a recency research skill - across 34 X posts, 5 YouTube videos, and 10 web sources.\n\nThe 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.\"\n\nBreadth doesn't beat depth. Understanding the user beats understanding the API.\n\n### Why CLIs plus MCP\n\nThe NOI is the creative intelligence. The printing press generates both interfaces from one spec:\n\n- `\u003Capi>-pp-cli`. Cobra CLI for humans plus shell agents (Claude Code, Codex, Gemini CLI).\n- `\u003Capi>-pp-mcp`. MCP server for Claude Desktop, Cursor, Windsurf, Cline. Auto-discovered, no shell needed.\n\nSame `internal\u002Fclient`, same `internal\u002Fstore`, same auth. Two binaries, zero code duplication.\n\nCLIs 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.\n\nMCP 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).\n\n```\nOne spec  ->  printing-press generate  ->  \u003Capi>-pp-cli (cobra)  +  \u003Capi>-pp-mcp (MCP server)\n                                            |                       |\n                                            same internal\u002Fclient, internal\u002Fstore\n```\n\nEvery API that gets a CLI+MCP becomes instantly accessible to every AI coding tool. The printing press is the factory.\n\n## How it works\n\nThe fast path is a lean loop. Artifacts still matter, but only when they directly improve the next phase.\n\n```\nPhase 0     Resolve + Reuse           (1-3 min)    Reuse research, detect tokens, resolve spec or URL\nPhase 1     Research Brief            (5-10 min)   API identity, competitors, data layer, product thesis\nPhase 1.5   Ecosystem Absorb Gate     (5-10 min)   Catalog every MCP\u002Fskill\u002FCLI feature -> absorb manifest + novel suggestions\nPhase 1.7   Browser-Sniff Gate        (2-5 min)    Browser capture, HAR import, discovery provenance\nPhase 2     Generate                  (1-2 min)    Go CLI + MCP server from spec with validation\nPhase 3     Build The GOAT            (10-20 min)  ALL absorbed features + transcendence commands\nPhase 4     Shipcheck                 (3-8 min)    Dogfood + verify --fix + scorecard as one verification block\nPhase 5     Live Smoke (optional)     (2-5 min)    Read-only API smoke + data-flow check\n```\n\nThree entry paths. Got an OpenAPI spec? Use `--spec`. Got a URL to a website with no docs? The browser-sniff gate launches a browser, captures traffic, and generates the spec. Got a HAR file from DevTools? Pass `--har`. The press handles all three.\n\n19 APIs in the catalog. Asana, DigitalOcean, Discord, Front, GitHub, Google Flights, HubSpot, Kayak, LaunchDarkly, Mercury, Pipedrive, Plaid, Postman Explore, Product Hunt, Sentry, Stripe, Stytch, Telegram, Twilio, plus Petstore for testing. Each pre-verified with spec URL, auth type, and category.\n\nDiscovery provenance. When the press sniffs a website, it archives everything - pages visited, endpoints discovered, response samples, rate limiting events, and `traffic-analysis.json` with protocol\u002Fauth\u002Fprotection signals and discovery warnings - into a `discovery\u002F` manuscript alongside the research and proofs. Full audit trail.\n\nFull pipeline contract. The fast path above compresses a longer 9-phase managed pipeline: preflight, research, scaffold, enrich, regenerate, review, agent-readiness, comparative, ship. Inputs, outputs, gates, and artifacts for each phase are documented in [docs\u002FPIPELINE.md](docs\u002FPIPELINE.md). Use it when you want to stop at any phase, resume later, re-run one step, or port the flow to another tool.\n\n\u003Cdetails>\n\u003Csummary>\u003Cb>MCP spec surface (advanced config)\u003C\u002Fb>\u003C\u002Fsummary>\n\nThe generator ships three opt-in knobs on the spec's `mcp:` block, aligned with Anthropic's [production-agent MCP guidance](https:\u002F\u002Fwww.anthropic.com\u002Fnews\u002Fbuilding-agents-that-reach-production-systems-with-mcp):\n\n```yaml\nmcp:\n  transport: [stdio, http]        # remote-capable for cloud-hosted agents; default [stdio]\n  addr: \":7777\"                   # default bind for the http transport\n  orchestration: code             # \"endpoint-mirror\" (default), \"intent\", or \"code\"\n  endpoint_tools: hidden          # suppress raw endpoint tools when intents cover the surface\n  intents:                        # compose multi-step tools declaratively\n    - name: create_issue_from_thread\n      description: \"Create an issue from a Slack thread.\"\n      params:\n        - { name: thread_id, type: string, required: true, description: \"slack thread id\" }\n      steps:\n        - endpoint: messages.get_thread\n          bind: { thread_id: \"${input.thread_id}\" }\n          capture: thread\n        - endpoint: issues.create\n          bind: { title: \"${thread.subject}\", description: \"${thread.body}\" }\n          capture: issue\n      returns: issue\n```\n\nRun `printing-press mcp-audit` after changes to see which library CLIs would benefit from the new surface.\n\n\u003C\u002Fdetails>\n\n## What gets generated\n\nDesigned for AI agents. Every flag, every output format, every exit code is chosen because an agent will consume it. Human-friendly table output in the terminal. Auto-JSON when piped, no flag needed. `--compact` drops to high-gravity fields only (id, name, status, timestamps), 60-80% fewer tokens. Typed exit codes (`0`=success, `2`=usage, `3`=not found, `4`=auth, `5`=API, `7`=rate limited) let agents self-correct in one retry without parsing error text. `--dry-run` lets agents explore safely. Humans benefit from all of this too. Agent-native design is just good CLI design taken seriously.\n\nAgent-first flags (every command): `--json`, `--select`, `--dry-run`, `--stdin`, `--csv`, `--compact`, `--quiet`, `--yes`, `--no-input`, `--no-cache`, `--no-color`. Auto-JSON when piped (no `--json` needed). Typed exit codes as above.\n\nActionable errors. Errors include the specific flag\u002Farg that's wrong, the correct usage pattern, and the command path. Agents self-correct in one retry.\n\nBounded output. List commands show \"Showing N results. To narrow: add --limit, --json --select, or filter flags.\" Token-conscious `--compact` mode returns only high-gravity fields, 60-80% fewer tokens.\n\nTable stakes features (from the absorb gate). Every feature the top competitor has, classified and built before novel features. If schpet\u002Flinear-cli has `start` (git branch from issue), you get it. If 4ier\u002Fnotion-cli has human-friendly filters, you get it. Anti-gaming rules prevent scorecard optimization over real features.\n\nData layer (high-gravity entities). Domain-specific SQLite tables with proper columns (not JSON blobs), FTS5 full-text search, incremental sync with cursor tracking, `sql` command for raw queries, domain-specific `UpsertX()` and `SearchX()` methods.\n\nWorkflow commands (from archetype): `stale`, `orphans`, `load`, `channel-health`, `reconcile`, etc.\n\nInsight commands (Rung 5): `health` (composite score), `similar` (duplicate detection), `trends`, `bottleneck`, `forecast`, `patterns`.\n\nProduction-ready output. Command name normalization (`retrieve-a` -> `get`, `post` -> `create`, `patch` -> `update`); `.printing-press.json` provenance manifest; \"Sources and Inspiration\" section in each generated README; proxy-envelope support for APIs that wrap requests in a POST envelope; adaptive rate limiting on browser-sniffed APIs (start slow, ramp on success, back off on 429); minimum 1 test file per package; `.goreleaser.yaml` plus Homebrew formula plus GitHub Actions CI; REST or GraphQL specs both supported; MCP server auto-emitted at `cmd\u002Fapi-mcp\u002Fmain.go`; cursor-based pagination, batch SQLite transactions, tuned pragmas, `--since` incremental sync, and `--concurrency` parallel workers in every `sync` (discrawl-inspired).\n\n### Domain archetypes\n\nThe profiler classifies every API into a domain archetype and auto-generates the right workflow + insight commands:\n\n| Archetype | Detected by | Auto-generated commands |\n|-----------|------------|------------------------|\n| Project Management | issue\u002Ftask\u002Fticket resources, assignee fields, priority levels | `stale`, `orphans`, `load`, `health`, `similar` |\n| Communication | message\u002Fchannel\u002Fthread resources, threading fields | `channel-health`, `message-stats`, `health`, `similar` |\n| Payments | charge\u002Fpayment\u002Finvoice resources, amount\u002Fcurrency fields | `reconcile`, `revenue`, `health`, `similar` |\n| Infrastructure | server\u002Fdeploy\u002Finstance resources | `health`, `similar` |\n| Content | document\u002Fpage\u002Fblock resources | `health`, `similar` |\n\nThe archetype is detected automatically from the spec. The entity mapper figures out which resource is the \"primary entity\" (issues for PM, messages for comms, charges for payments) and wires the templates accordingly.\n\n## Verification & quality\n\nFour mechanical checks before a CLI can ship: a two-tier scorecard, structural dogfood, proof of behavior, and (when an API key is present) a live read-only smoke test. No vibes, no self-assessment.\n\nThree benchmarks shape the scorecard, all must pass:\n\n1. Architecture (discrawl benchmark). Does it have a real data layer: domain-specific SQLite, FTS5, incremental sync, workflow commands?\n2. Quality (gogcli benchmark). Does the code have proper output modes, typed errors, agent-native flags, doctor, README with cookbook?\n3. Features (competitor benchmark). Would a user of the top competitor switch to this CLI?\n\nArchitecture without features is a toy. Features without architecture is a thin wrapper. Quality without either is polished nothing.\n\n### Two-tier scorecard (100 points)\n\nInspired by Peter Steinberger's [gogcli](https:\u002F\u002Fgithub.com\u002Fsteipete\u002Fgogcli). Two tiers, weighted 50\u002F50. Grade A = 85+.\n\nTier 1: infrastructure (50 points). Does the skeleton have the right patterns?\n\n| Dimension | What it checks |\n|-----------|---------------|\n| Output Modes | --json, --csv, --select, --quiet, --compact, auto-JSON when piped |\n| Auth | OAuth flow, format-aware headers (Bot\u002FBearer\u002FBasic from spec) |\n| Error Handling | Typed exits, retry with backoff, actionable error messages |\n| Agent-Native | --json, --select, --dry-run, --stdin, --no-input, --compact, --yes |\n| + 5 more | Terminal UX, README, Doctor, Local Cache, Breadth |\n\nTier 2: domain correctness (50 points). Does the code actually work?\n\n| Dimension | What it checks |\n|-----------|---------------|\n| Path Validity | Generated paths exist in the OpenAPI spec |\n| Auth Protocol | Auth format matches spec's securitySchemes |\n| Data Pipeline | Sync calls domain-specific UpsertX(), not generic Upsert() |\n| Sync Correctness | Real resources, nested paths, pagination, incremental cursors |\n| Type Fidelity | String IDs (not int), required params marked, quality descriptions |\n| Dead Code | No unwired flags, no uncalled functions, no ghost tables |\n\nWhy two tiers? A scorecard that only checks syntax (\"does this string exist in the file?\") misses semantics (\"does this code actually work?\"). The two-tier system forces both breadth and depth.\n\nAnti-gaming rules prevent optimizing for score instead of features. Table stakes (features competitors have) are Priority 1. Scorecard optimization is Priority 4.\n\n### Verification commands\n\n```bash\n# Quality scorecard: two-tier scoring (infrastructure + domain correctness)\nprinting-press scorecard --dir .\u002Fmy-pp-cli --spec .\u002Fopenapi.json\n\n# Dogfood: catches dead flags, dead functions, auth mismatches, invalid paths\nprinting-press dogfood --dir .\u002Fmy-pp-cli --spec .\u002Fopenapi.json\n\n# Runtime verification: tests every command against real API or mock server\nprinting-press verify --dir .\u002Fmy-pp-cli --spec .\u002Fopenapi.json --api-key $TOKEN\n\n# Emboss audit: baseline snapshot for improvement cycle\nprinting-press emboss --dir .\u002Fmy-pp-cli --spec .\u002Fopenapi.json --audit-only\n```\n\n### Proof of behavior\n\nThe scorecard checks structure. Proof of Behavior checks data flow: does `sync.go` actually call `UpsertMessage` on a table that `search.go` queries?\n\nFour behavioral proofs:\n\n- Path Proof. Every URL in generated commands exists in the OpenAPI spec.\n- Flag Proof. Every registered flag is referenced in at least one command.\n- Pipeline Proof. Every SQLite table has a WRITE path (sync) and READ path (search\u002Fquery).\n- Auth Proof. Auth header format matches the spec's securitySchemes.\n\nIf any proof fails, auto-remediation removes dead code and re-verifies. Hallucinated paths and auth mismatches are hard FAIL gates.\n\n### Live API testing\n\nWhen you provide an API key at the start, Phase 5 runs read-only tests against the real API:\n\n```\nLIVE API TEST RESULTS\n=====================\nAuth:     PASS (200 OK on doctor)\nList:     3\u002F3 passed (users, channels, guilds)\nGet:      1\u002F1 passed (user abc123)\nSync:     PASS (5 pages synced, 12 blocks)\nSearch:   PASS (3 results for \"a\")\n\nVerdict:  PASS - CLI works against real API\n```\n\nSafety: GET only, --limit 1, 10s timeout, stops on 401. Never creates, posts, or deletes anything.\n\n### Auth doctor\n\n`printing-press auth doctor` scans every installed printed CLI's `tools-manifest.json` and reports whether its declared env vars are set, unset, or suspicious. Fingerprints show the first four characters of each set value, never the full token.\n\n```bash\nprinting-press auth doctor\nprinting-press auth doctor --json\n```\n\nUseful when an agent hits a 401 on a printed CLI: one command shows whether the token is missing, truncated, or shadowed by a stale value without having to inspect shell config. Offline, read-only, and exits 0 even when findings include \"not set\" or \"suspicious\" because this is diagnostic, not gating.\n\n### Ship loop\n\n\"Is this shippable?\" triggers a fix cycle: identify top 3 issues, fix them, re-score. Max 3 iterations. No more dead-end assessments.\n\n## Library\n\nPublished CLIs live in the [Printing Press Library](https:\u002F\u002Fgithub.com\u002Fmvanhorn\u002Fprinting-press-library), organized by category, most with full MCP servers. Browse at [printingpress.dev](https:\u002F\u002Fprintingpress.dev).\n\nA small sample, see the [full catalog](https:\u002F\u002Fgithub.com\u002Fmvanhorn\u002Fprinting-press-library#catalog) for the rest:\n\n| CLI | Category | What it does |\n|-----|----------|--------------|\n| `espn-pp-cli` | Media and Entertainment | ESPN sports data: scores, stats, standings across 17 sports. |\n| `flightgoat-pp-cli` | Travel | Kayak nonstop search plus sniffed Google Flights, in one call. |\n| `linear-pp-cli` | Project Management | 50ms compound queries against a local Linear mirror. |\n| `kalshi-pp-cli` | Payments | Trade prediction markets from the terminal. |\n| `recipe-goat-pp-cli` | Food and Dining | Trust-aware ranking across 37 recipe sites. |\n\nEach newly published CLI ships a root `AGENTS.md` operating guide, a research manuscript, verification proofs, and a `.printing-press.json` provenance manifest.\n\n## Troubleshooting\n\n**`\u002Fprinting-press` slash command doesn't appear in Claude Code.** Restart your Claude Code session after installing the skills. If you cloned the repo, confirm `claude --plugin-dir .` was run from the cloned repo root. If you installed skills only, run `gh skill list` (or `npx skills list`) to verify the install.\n\n**`printing-press: command not found` after a successful `go install`.** `$GOPATH\u002Fbin` (default `~\u002Fgo\u002Fbin`) isn't on your `PATH`. Add it to your shell profile.\n\n**Live API smoke test reports 401.** Token unset or stale. Run `printing-press auth doctor` to see which env vars are missing or suspicious before reading shell config.\n\n**Browser-sniff captures no useful endpoints.** The site likely uses websockets, gRPC, or aggressive bot detection. Try a HAR export from DevTools (`\u002Fprinting-press --har .\u002Fcapture.har`) instead of the live browser flow.\n\n**Codex mode falls back to local generation.** Expected behavior after 3 consecutive Codex failures. Standard Opus mode takes over with no manual intervention.\n\n## Limitations\n\n- **Requires Go 1.26.3 or newer and Claude Code.** No standalone distribution today; the slash command is the supported entry point.\n- **Generated CLIs are domain-shaped, not vendor-replacements.** A `\u003Capi>-pp-cli` covers the agent power-user surface, not every back-office knob a vendor's official CLI ships.\n- **Browser-sniff requires manual capture.** You point a browser at the site (or import a HAR); the press doesn't crawl autonomously.\n- **Live verify is read-only.** Phase 5 runs GET only and never mutates. Real write-path coverage lives in unit tests and the dogfood structural checks.\n- **Scoring is structural, not end-user QA.** A Grade A scorecard means the CLI follows the patterns; it doesn't replace using the CLI in anger for an afternoon.\n- **`regen-merge` is macOS+Linux only.** Windows isn't supported for the regen-merge subcommand today.\n\n## FAQ\n\n**Why not Speakeasy, Fern, or openapi-generator?** Those wrap endpoints. We wrap endpoints AND generate the discrawl-style data layer (SQLite, FTS5, sync, compound commands) AND the MCP server AND the agent-native UX (typed exit codes, `--compact`, auto-JSON-when-piped). The output is shaped for an agent that will call it thousands of times a day.\n\n**Does it work without Claude?** The binary works standalone (research, generation, verification, scoring), but the curated agent loop — research absorption, novel-feature suggestion, ship cycle — runs through the `\u002Fprinting-press` slash command in Claude Code. Bring your own agent loop if you want to skip it.\n\n**Does it require an OpenAPI spec?** No. Three input modes: a spec (`--spec`), a HAR file (`--har`), or just a URL. The browser-sniff gate launches a browser, captures traffic, and reverse-engineers the spec for sites that don't publish one.\n\n**How fresh is the local SQLite cache?** Configurable. Without `cache.enabled`, you run `sync` manually. With `cache.enabled` and `--data-source auto`, the CLI runs a bounded pre-read refresh before serving local data. `--data-source local` skips refresh; `--data-source live` bypasses the cache entirely.\n\n**What does shipping a CLI cost in tokens?** Standard Opus mode runs end-to-end on Opus. Codex mode (`\u002Fprinting-press \u003Capi> codex`) offloads Phase 3 code generation to Codex CLI for ~60% fewer Opus tokens. Both produce equivalent quality.\n\n**Can I run the verification tools on a CLI I built by hand?** Yes. `printing-press scorecard`, `dogfood`, and `verify` accept any directory + spec. Tier 1 of the scorecard checks for agent-native patterns; Tier 2 checks paths\u002Fauth\u002Fdata-flow against the spec.\n\n## Contributing\n\nBug reports, feature requests, and PRs are welcome. Read [CONTRIBUTING.md](CONTRIBUTING.md) before opening a PR; it explains the PR template, AI \u002F automation disclosure, and the repo boundary between the Printing Press and printed CLIs. [AGENTS.md](AGENTS.md) carries the full developer conventions, glossary, commit style, and verification rules.\n\n## Development\n\n\u003Cdetails>\n\u003Csummary>\u003Cb>Build, test, lint, and hooks\u003C\u002Fb>\u003C\u002Fsummary>\n\n```bash\ngo build -o .\u002Fprinting-press .\u002Fcmd\u002Fprinting-press\ngo test .\u002F...\ngo fmt .\u002F...\ngolangci-lint run .\u002F...\n```\n\nA pre-push lefthook hook runs `golangci-lint` on changed files; the same config (`.golangci.yml`) runs in CI.\n\nInstall hooks with:\n\n```bash\nbrew install lefthook\nlefthook install --reset-hooks-path\n```\n\nUse `--reset-hooks-path` so stale local `core.hooksPath` settings do not block hook sync. Avoid `lefthook install --force` unless intentionally overriding a custom hooks path.\n\nIf you cloned the repo (the recommended install path above), `claude --plugin-dir .` already loads `\u002Fprinting-press` from your working copy, so local skill edits take effect on the next session start. See [AGENTS.md](AGENTS.md) for full conventions, glossary, and release flow.\n\n\u003C\u002Fdetails>\n\n\u003Cdetails>\n\u003Csummary>\u003Cb>Golden Output Harness\u003C\u002Fb>\u003C\u002Fsummary>\n\nGolden output checks compare deterministic, offline `printing-press` commands against committed stdout, stderr, exit-code, and selected artifact fixtures:\n\n```bash\nscripts\u002Fgolden.sh verify\n```\n\nUse update mode only after an intentional behavior change:\n\n```bash\nscripts\u002Fgolden.sh update\n```\n\nThe harness rebuilds `.\u002Fprinting-press`, writes actual outputs under `.gotmp\u002Fgolden\u002Factual`, and compares them to `testdata\u002Fgolden\u002Fexpected`. Cases live under `testdata\u002Fgolden\u002Fcases\u002F\u003Ccase-name>\u002F`; `command.txt` defines the offline command, and `artifacts.txt` lists behaviorally important generated files to compare. Normalization is intentionally narrow: machine-specific paths, deterministic JSON formatting, and known provenance fields like generated timestamps. CI runs this as a separate `Golden` workflow, not inside `go test .\u002F...`.\n\nThe generated-CLI golden uses `testdata\u002Fgolden\u002Ffixtures\u002Fgolden-api.yaml`, a purpose-built OpenAPI fixture for the Printing Press. Extend that fixture when the machine gains new deterministic generation capabilities that should be protected by artifact goldens. Update mode refuses dirty worktrees unless `GOLDEN_ALLOW_DIRTY=1` is set, so fixture churn stays intentional.\n\n\u003C\u002Fdetails>\n\n## Credits\n\n- Peter Steinberger ([@steipete](https:\u002F\u002Fgithub.com\u002Fsteipete)). [discrawl](https:\u002F\u002Fgithub.com\u002Fsteipete\u002Fdiscrawl) and [gogcli](https:\u002F\u002Fgithub.com\u002Fsteipete\u002Fgogcli) set the bar. The quality scoring system is inspired by his work; discrawl's sync architecture directly influenced the printing press templates.\n- Trevin Chow ([@trevin](https:\u002F\u002Fx.com\u002Ftrevin)). [10 Principles for Agent Native CLIs](https:\u002F\u002Ftrevinsays.com\u002Fp\u002F10-principles-for-agent-native-clis) shaped the agent-first template design. Co-creator shipping PRs daily.\n- Ramp ([@tryramp](https:\u002F\u002Fgithub.com\u002Framp-public\u002Framp-cli)). Their agent-first CLI inspired auto-JSON piping, --no-input, and --compact output.\n- The community filers and contributors whose issues and PRs nudged the catalog forward.\n\n## License\n\nMIT\n","CLI Printing Press 是一个用于生成高效命令行界面（CLI）的工具，特别为AI代理设计。它能够解析官方API文档、分析流行的社区CLI及MCP服务器，并发掘未公开的API，最终融合这些信息来创建功能强大的Go语言CLI应用。其核心技术特点包括支持SQLite同步、离线搜索以及复合洞察命令等。该项目非常适合需要快速访问特定API或网站数据的场景，如自动化脚本编写、数据分析和提高AI代理工作效率等领域。通过提供预构建的CLIs，例如针对ESPN赛事信息查询、航班搜索整合以及项目管理问题追踪等，CLI Printing Press极大地简化了开发者的工作流程。",2,"2026-06-11 03:50:12","high_star"]