How to Build a Custom CLI for Any Website with Claude Code and Printing Press in 10 Minutes
Printing Press's factory skill lets Claude Code reverse-engineer any website and build a working CLI in about 10 minutes. Here's the exact process.
You Can Build a CLI for Any Website in About 10 Minutes
Most websites your agents want to talk to don’t have a public API. ESPN doesn’t. Craigslist doesn’t. School doesn’t. Domino’s doesn’t. All Recipes has anti-scrape protection that blocks naive HTTP clients. You’ve probably hit this wall: you want Claude Code to pull data from some site you use every day, and there’s no clean programmatic interface to reach for.
The fix takes about 10 minutes, and the process is almost entirely automated. Printing Press — a CLI factory that runs inside Claude Code — follows a four-step sequence: Claude researches the target site, catalogs every available feature, generates a Go CLI, then verifies it works through what the docs call “dog food runtime verification and scoring.” You end up with a working command-line tool that your agent can invoke natively, with pre-formatted output measured in hundreds of tokens rather than hundreds of thousands.
This post is the step-by-step walkthrough. Not the theory — the actual commands, the actual failure modes, and what to do when Claude’s time estimate is wildly wrong (it always is).
What You Actually Get at the End
Before the prerequisites, it’s worth being concrete about the output.
How Remy works. You talk. Remy ships.
The School CLI demo is the clearest illustration. Claude Code was asked to pull 10 recent posts from a School community — a platform with no public API. The CLI fetched the data, which amounted to roughly 132,000 tokens of raw content from School’s servers. What entered the Claude context window: about 2,000 tokens of clean, structured summary. That’s a 66x compression ratio, achieved not by summarization but by architecture — the CLI processes and formats the data locally before handing anything back to the agent.
Compare that to what happens with an MCP server on the same task. Benchmarks from the Printing Press team show MCP using 35 times more tokens than the equivalent CLI, with task reliability dropping from 100% to 72% as task complexity increases. The MCP overhead isn’t just the tool descriptions loaded at session start — it’s the raw JSON responses, the round-trip latency, the context bloat that accumulates across a long session.
The CLI approach solves this structurally. Pre-formatted output means the agent gets roughly 200 tokens of clean text rather than a massive JSON body. A local SQLite mirror means no round trips for repeated queries. Auth tokens are held by the CLI itself, so the agent never has to manage credentials mid-task. If you’re building Claude Code skills that chain multiple tools together, this architecture matters a lot — you’re not burning context budget on plumbing.
What You Need Before You Start
Go. The CLIs that Printing Press generates are written in Go — a free, open-source language from Google designed for exactly this kind of work: fast binaries, simple deployment, no runtime dependencies. You don’t need to know Go to use this. You just need it installed. If you don’t have it, drop the Printing Press setup instructions into Claude Code and ask it to walk you through the Go installation. It’ll tell you what to download and prompt you through the steps. Budget about a minute.
Claude Code. This is the environment where everything runs. The factory is a Claude Code skill, not a standalone app.
Three URLs. From printingpress.dev, you’ll want: the starter pack install command, the factory install command, and the GitHub library URL. The starter pack gives you five pre-built CLIs immediately (ESPN, Flight Goat, Movie Goat, Recipe Goat). The factory is what lets you build your own. Paste all three into a fresh Claude Code session and tell it to read them and get everything set up.
The target site. Know what site you want to build a CLI for, and have a sense of what data you want to pull. You don’t need to understand the site’s internals — that’s Claude’s job — but having a clear use case (“I want to pull top stories from Hacker News daily” or “I want to search Craigslist listings in my city”) will make the factory’s research phase more targeted.
No API key required for the target site, necessarily. That’s the point. Sites like ESPN and Craigslist have no public API to key into. The factory reverse-engineers the site’s behavior directly.
Building the CLI: Step by Step
Step 1: Install the starter pack and factory
Open a Claude Code session. Paste in the three URLs from printingpress.dev — the starter pack, the factory, and the GitHub library. Tell Claude: “Read all three of these. This is a new tool with pre-loaded CLIs and a factory for building new ones. Install everything I need.”
- ✕a coding agent
- ✕no-code
- ✕vibe coding
- ✕a faster Cursor
The one that tells the coding agents what to build.
Claude will work through the setup. If Go isn’t installed, it’ll flag that first. Once Go is in place, it’ll install the starter pack CLIs and the factory skill.
Now you have: Five working CLIs (ESPN, Flight Goat, Movie Goat, Recipe Goat, and the factory itself) and the ability to query the Printing Press catalog for additional pre-built options.
Step 2: Verify the starter pack works
Before building anything custom, confirm the installed CLIs are functional. Ask Claude: “What NBA games are on tonight?” or “What are the top flights from [city] to [city] this week?”
The ESPN CLI should return a clean, formatted response in seconds. When it works, you’ll see the pp-espn skill being invoked in Claude’s tool use trace, and the response will be a handful of sentences — not a JSON dump.
If you want to see what’s installed and what’s available in the catalog, ask Claude to check the Printing Press catalog. It’ll list local CLIs and available ones from the GitHub library. The catalog includes Amazon, Craigslist, eBay, TikTok Shop, Shopify, Airbnb, LinkedIn (via Contact Goat), Hacker News, and Linear, among others.
Now you have: Confirmed working CLIs and a clear picture of what’s already built versus what you’d need to create.
Step 3: Invoke the factory for your target site
This is the core step. Tell Claude something like: “Can you use the Printing Press CLI factory to build me a CLI for [site]? I want to be able to [specific use case]. Here’s the site: [URL].”
The factory then runs its four-phase process:
Research. Claude visits the target site, examines its structure, and figures out how data is organized and accessed. For sites without a public API, this means reverse-engineering the site’s behavior — looking at what requests the browser makes, what endpoints exist, how authentication works if needed.
Catalog. Claude produces a list of every feature it found. For Hacker News, this might be: top stories, new stories, ask HN, show HN, job listings, comments on a specific post, user profiles. You’ll see this list before any code is written.
Generate. Claude writes the Go CLI, implementing every cataloged feature. This is where the binary gets built. The output is a compiled executable, not a script — it runs fast and has no dependencies beyond what Go compiled in.
Verify. The factory runs what it calls “dog food runtime verification and scoring” — it actually invokes the CLI it just built, checks that the outputs are correct and well-formatted, and scores the result. If something is wrong, it iterates.
The whole process takes roughly 10 minutes for a site like Hacker News. Claude will estimate 30-60 minutes. Ignore that estimate.
Now you have: A working Go CLI binary for your target site, plus a Claude Code skill that lets you invoke it with natural language.
Step 4: Test the new CLI
Ask Claude to test the CLI using the skill it just built. For Hacker News: “Using the new CLI, which sites are dominating Hacker News today?”
Other agents start typing. Remy starts asking.
Scoping, trade-offs, edge cases — the real work. Before a line of code.
You should get back a clean, formatted list — top stories from the last 24 hours, ranked by score, with titles and links. The response should be fast and the token count should be small. If you’re curious about the actual token consumption, ask Claude to report it explicitly.
Now you have: A verified, working CLI that your agent can use in any future session.
Step 5: Package and share (optional but worth doing)
If you’re on a team, the CLI can be pushed to a private GitHub repo and shared. Each team member clones the repo and substitutes their own API key or auth token in their local config. The CLI scripts themselves don’t contain credentials — they reference them from environment config, the same way you’d handle any API integration.
Ask Claude: “Can you package this CLI and its skill into a GitHub repo so I can share it with my team?” It’ll create the repo structure, write a README, and handle the packaging. A few seconds of work.
Now you have: A shareable, team-ready CLI that anyone can clone and use with their own credentials.
Where This Breaks (and What to Do)
Authentication complexity. Sites that use OAuth or session-based auth require more work. The factory handles this, but you’ll need to provide credentials or walk Claude through the auth flow. Treat it the same way you’d treat any API with OAuth — the CLI will hold the token once configured, but you have to get the token first. The Contact Goat CLI (which finds verified emails via LinkedIn, cross-checks via Happenstand, and runs deep email verification) is a good example of a CLI that handles complex auth gracefully once set up.
Rate limits still apply. Using a CLI doesn’t bypass quotas. If the YouTube Data API allows a certain number of comment posts per day, the CLI respects that limit. The CLI is a better interface to the underlying system, not a way around the underlying system’s constraints.
Anti-scrape protection. Some sites actively block automated access. All Recipes is a known example. The Printing Press CLIs handle this by using a real Chrome session rather than raw HTTP requests — but this means the CLI needs a browser available. If you’re running Claude Code in a headless environment, check whether the target site requires browser rendering before you start.
The factory’s time estimates. Claude will say “30 to 60 minutes.” It will finish in 10. This is a consistent quirk, not a sign that something is wrong. Just say “go ahead” and let it run.
The catalog phase produces too many features. For complex sites, Claude might catalog dozens of features and try to implement all of them. If you only need a subset, say so before the generate phase starts. “I only need top stories and comment threads — skip user profiles and job listings.” This keeps the binary smaller and the verification faster.
Where to Take This Next
Remy doesn't write the code. It manages the agents who do.
Remy runs the project. The specialists do the work. You work with the PM, not the implementers.
The most useful next move is identifying which tools in your current workflow have the worst API-to-usefulness ratio. If you’re using an MCP server for something and noticing context bloat or reliability issues, that’s a candidate for a CLI replacement. If you’re hitting a site manually because there’s no API, that’s an even better candidate.
The browser automation with Claude Code and Playwright approach handles some of the same use cases — particularly for sites that require real browser sessions — but CLIs are faster and more token-efficient for structured data retrieval once they’re built.
For teams building more complex agent workflows, the CLI-as-skill pattern pairs well with Claude Code’s self-evolving memory systems. Your agent accumulates knowledge about how to use its CLIs effectively, which compounds over time.
If the broader question is how to go from “I have a CLI that produces structured data” to “I have a production application built on that data,” the abstraction layer above this is worth thinking about. Remy takes a different approach to that problem: you write an annotated markdown spec, and it compiles a complete TypeScript stack — backend, SQLite database, auth, deployment — from that spec. The CLI becomes one input source; the spec describes what the application does with it.
The Printing Press catalog will keep growing. The GitHub library already has CLIs for Amazon, Craigslist, eBay, TikTok Shop, Shopify, Airbnb, LinkedIn, Hacker News, and Linear. Before building a custom CLI, check whether one already exists — the install is faster than the factory run.
One opinion worth stating plainly: the tier ordering matters. CLI first, then API if no CLI exists, then MCP only if there’s no other option. The 35x token overhead of MCP isn’t a rounding error — it’s the difference between a session that stays coherent and one that hits context limits before finishing a complex task. If you’re building agents that do real work, the interface layer is worth optimizing. Platforms like MindStudio handle orchestration across 200+ models and 1,000+ integrations, but even in a well-orchestrated system, the per-tool token cost compounds quickly across a long workflow.
The 10-minute investment to build a CLI pays back every time your agent runs a task against that site. Build the ones you need, share them with your team, and stop paying MCP overhead for things that don’t require it.
