← Item page

Printing Press turns APIs and websites into agent-native command surfaces.

A product/tool link relevant to Dab’s tooling stack: one generator can produce a Go CLI, Claude Code skill, OpenClaw skill, and MCP server from an API spec, undocumented website, or fan project.

Source: printingpress.dev Type: developer tool / agent infrastructure Mission Control fit: high Related item: #46 Dab Improvements

What the link is

The captured page describes Printing Press as: “From an API spec, a website with no public API, or a community fan project — one command prints a Go CLI, a Claude Code skill, an OpenClaw skill, and an MCP server. Muscle memory for agents.”

The important idea is not generic code generation. It is tool-surface generation: give agents a stable, documented, command-line shape around messy external services so they can call tools cheaply and repeatably instead of scraping docs or re-reading integration code every run.

Input

OpenAPI specs, API docs, websites with no public API, or community/fan projects that expose enough behavior to wrap.

Outputs

A Go CLI, a Claude Code skill, an OpenClaw skill, and an MCP server around the same capability.

Agent value

Predictable commands, JSON output, reusable skills, and a shared muscle-memory layer across agents.

Fit for Dab

Useful for turning recurring Mission Control services into compact tools that Dab can verify and delegate through Claude Code.

The architecture pattern worth stealing

1. SpecifyPoint the Press at an API spec, docs, site behavior, or target service.
2. PrintGenerate a CLI plus skill/MCP wrappers instead of a one-off script.
3. DogfoodRun commands against real workflows; check outputs, failure modes, and destructive edges.
4. PolishImprove naming, command grouping, JSON output, docs, and examples.
5. ReuseAgents call a stable surface in future sessions with far less context.

This maps directly to the current Dab principle: orchestration should be in Dab, but execution should happen through scoped tools and Claude Code workers with explicit acceptance criteria.

Why this already mattered for Notice Board

Item #46 has already been explored in Mission Control. The useful conclusion: Notice Board does not yet have a proper HTTP API for Printing Press to consume, so the immediate implementation was a small stdlib Python CLI — tools/notice.py — built in the Press’s style.

Notice Board today
├─ brain.json                 source of truth
├─ inbox.md                   append-only audit log
├─ render.py / mc_pages.py    deterministic generated pages
└─ tools/notice.py            Press-inspired local CLI
   ├─ list / show             compact read surfaces for agents
   ├─ capture / explore       safe mutations with audit trail
   ├─ done                    status cleanup without JSON surgery
   ├─ link capture/list       Link Triage intake + queue inspection
   └─ validate/render/status  repeatable verification hooks

That is the main local lesson: even before full API generation, the Press nudged Notice Board toward a smaller, safer, agent-callable operating surface.

How Ananth can use this

Use now

  • Keep using tools/notice.py for capture, cleanup, validation, and Link Triage jobs.
  • Use Printing Press from Claude Code only when a target has a clear API/docs surface and the output will replace repeated manual glue.
  • Prefer small generated tools for recurring Dab workflows: finance data, content pipelines, link research sources, deployment/status checks.

Do not overdo

  • Do not print a full CLI for every random link or one-off task.
  • Do not wrap sensitive services until auth/secrets boundaries are designed.
  • Do not replace Notice Board’s local-first JSON workflow until there is a real service/API boundary worth wrapping.

Decision lens for future Printing Press uses

  1. Is this a recurring capability? If not, use a one-off script or Claude Code session.
  2. Is the source stable enough? Public API/spec beats fragile website scraping.
  3. Will JSON output save agent context? If yes, a CLI/MCP surface may be worth it.
  4. Can Dab independently verify it? Generated tools still need dogfood, validation, and scoped commits.
  5. Does it belong in Mission Control? The strongest fits are Dab Improvements, Read/Link Triage expansion, research pipelines, and repeatable admin tooling.

Bottom line

Printing Press is best treated as an agent-tool factory, not a magic app builder. Its value for Ananth is giving Dab and Claude Code fewer bespoke integrations and more stable command surfaces. The immediate Notice Board outcome already exists: tools/notice.py. The next sensible step is to use that CLI hard, then only print a fuller Go CLI/MCP server when Notice Board or another workflow exposes a real API-like boundary.

Related deeper project page: Printing Press · Notice Board CLI explainer.

← back to Read · source link