printing-press

Name: printing-press
Author: mvanhorn

5.1kinstalls453forks

How to install printing-press?

mvanhorn/cli-printing-press/printing-press

$npx -y skills add mvanhorn/cli-printing-press --skill printing-press

Installs into the current project.

Summary

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, a

Files · 1

View on GitHub

SKILL.md

1	# /printing-press
2
3	Generate the best useful CLI for an API without burning an hour on phase theater.
4
5	```bash
6	/printing-press Notion
7	/printing-press Discord codex
8	/printing-press --spec ./openapi.yaml
9	/printing-press --har ./capture.har --name MyAPI
10	/printing-press https://postman.com/explore
11	/printing-press https://postman.com
12	```
13
14	## What Changed In v2
15
16	The old skill inflated the path to ship:
17	- too many mandatory research documents before code existed
18	- too many separate late-stage validation phases after code existed
19	- too many chances to discover obvious failures late
20
21	This version uses one lean loop:
22	1. Resolve the spec and write one research brief
23	2. Generate
24	3. Build the highest-value gaps
25	4. Run one shipcheck block
26	5. Optionally run live API smoke tests
27
28	Artifacts are still written, but only the ones that materially help the next step.
29
30	## Modes
31
32	### Default
33
34	Normal mode. Claude does research, generation orchestration, implementation, and verification.
35
36	### Codex Mode
37
38	If the arguments include `codex` or `--codex`, offload pure code-writing tasks to Codex CLI.
39
40	Use Codex for:
41	- writing store/data-layer code
42	- writing workflow commands
43	- fixing dead flags / dead code / path issues
44	- README cookbook edits
45
46	Keep on Claude:
47	- research and product positioning
48	- choosing which gaps matter
49	- verification results and ship decisions
50
51	If Codex fails 3 times in a row, stop delegating and finish locally.
52
53	### Polish Mode (Standalone Skill)
54
55	For second-pass improvements to an existing CLI, use the standalone polish skill:
56
57	```bash
58	/printing-press-polish redfin
59	```
60
61	See the `printing-press-polish` skill for details. It runs diagnostics, fixes verify failures, removes dead code, cleans up descriptions and README, and offers to publish.
62
63	## Rules
64
65	- Do not ship a CLI that hasn't been behaviorally tested against real targets. `go build` and `verify` pass-rate are structural signals, not correctness signals. Phase 5's mechanical test matrix runs every subcommand + `--json` + error paths; if that matrix was not executed, the CLI is not shippable. Quick Check is the floor; Full Dogfood is required when the user asks for thoroughness.
66	- Bugs found during dogfood are fix-before-ship, not "file for v0.2". If a 1-3 file edit resolves it, do it now. `ship-with-gaps` is deprecated as a default verdict (see Phase 4). Context is freshest in-session; a v0.2 backlog that may never be revisited ships known-broken CLIs.
67	- Features approved in Phase 1.5 are shipping scope. Do not downgrade a shipping-scope feature to a stub mid-build. If implementation becomes infeasible, return to Phase 1.5 with a revised manifest and get explicit re-approval.
68	- Do not quote human-time estimates for sub-tasks ("~15-30 min", "~1 hour", "quick fix") in `AskUserQuestion` options, phase descriptions, or reference docs. The agent does the work, not the user; agent-fabricated estimates are notoriously bad and train users to distrust the prompt. Describe scope instead (lines of code, files touched, relative size). The carve-outs are wall-clock estimates for genuinely time-bound things: the whole-CLI run (set the user's expectation up front — most CLIs take 30+ minutes), tool installs (`go install` takes ~10 seconds), and printing-press subcommands that do network-bound work (crowd-sniff scans npm + GitHub, ~5-10 minutes). Anything bounded by agent reasoning time is not time-bound — describe scope.
69	- Use raw captures for contract research. When reading official docs, auth/error/rate-limit pages, endpoint references, OpenAPI/Postman links, or source pages whose exact identifiers affect the generated CLI, read [references/fetch-docs.md](references/fetch-docs.md) and use its `fetch-docs.sh` helper. Reserve `WebFetch` for quick TL;DR reads where losing field-level details is acceptable.
70	- Optimize for time-to-ship, not time-to-document.
71	- Reuse prior research whenever it is already good enough.
72	- Do not split one idea across multiple mandatory artifacts.
73	- Durable files produced by this skill go under `$PRESS_RUNSTATE/` (working state) or `$PRESS_MANUSCRIPTS/` (archived). Short-lived command captures may use `/tmp/printing-press/` and must be removed after use.
74	- Do not create a separate narrative phase for dogfood, dead-code audit, runtime verification, and final score. Treat them as one shipcheck block.
75	- Run cheap, high-signal checks early.
76	- Fix blockers and high-lev

People who liked this also viewed

6 picks

Type

printing-press

5.1kinstalls453forks

View on GitHub

How to install printing-press?

mvanhorn/cli-printing-press/printing-press

$npx -y skills add mvanhorn/cli-printing-press --skill printing-press

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# /printing-press
2
3	Generate the best useful CLI for an API without burning an hour on phase theater.
4
5	```bash
6	/printing-press Notion
7	/printing-press Discord codex
8	/printing-press --spec ./openapi.yaml
9	/printing-press --har ./capture.har --name MyAPI
10	/printing-press https://postman.com/explore
11	/printing-press https://postman.com
12	```
13
14	## What Changed In v2
15
16	The old skill inflated the path to ship:
17	- too many mandatory research documents before code existed
18	- too many separate late-stage validation phases after code existed
19	- too many chances to discover obvious failures late
20
21	This version uses one lean loop:
22	1. Resolve the spec and write one research brief
23	2. Generate
24	3. Build the highest-value gaps
25	4. Run one shipcheck block
26	5. Optionally run live API smoke tests
27
28	Artifacts are still written, but only the ones that materially help the next step.
29
30	## Modes
31
32	### Default
33
34	Normal mode. Claude does research, generation orchestration, implementation, and verification.
35
36	### Codex Mode
37
38	If the arguments include `codex` or `--codex`, offload pure code-writing tasks to Codex CLI.
39
40	Use Codex for:
41	- writing store/data-layer code
42	- writing workflow commands
43	- fixing dead flags / dead code / path issues
44	- README cookbook edits
45
46	Keep on Claude:
47	- research and product positioning
48	- choosing which gaps matter
49	- verification results and ship decisions
50
51	If Codex fails 3 times in a row, stop delegating and finish locally.
52
53	### Polish Mode (Standalone Skill)
54
55	For second-pass improvements to an existing CLI, use the standalone polish skill:
56
57	```bash
58	/printing-press-polish redfin
59	```
60
61	See the `printing-press-polish` skill for details. It runs diagnostics, fixes verify failures, removes dead code, cleans up descriptions and README, and offers to publish.
62
63	## Rules
64
65	- Do not ship a CLI that hasn't been behaviorally tested against real targets. `go build` and `verify` pass-rate are structural signals, not correctness signals. Phase 5's mechanical test matrix runs every subcommand + `--json` + error paths; if that matrix was not executed, the CLI is not shippable. Quick Check is the floor; Full Dogfood is required when the user asks for thoroughness.
66	- Bugs found during dogfood are fix-before-ship, not "file for v0.2". If a 1-3 file edit resolves it, do it now. `ship-with-gaps` is deprecated as a default verdict (see Phase 4). Context is freshest in-session; a v0.2 backlog that may never be revisited ships known-broken CLIs.
67	- Features approved in Phase 1.5 are shipping scope. Do not downgrade a shipping-scope feature to a stub mid-build. If implementation becomes infeasible, return to Phase 1.5 with a revised manifest and get explicit re-approval.
68	- Do not quote human-time estimates for sub-tasks ("~15-30 min", "~1 hour", "quick fix") in `AskUserQuestion` options, phase descriptions, or reference docs. The agent does the work, not the user; agent-fabricated estimates are notoriously bad and train users to distrust the prompt. Describe scope instead (lines of code, files touched, relative size). The carve-outs are wall-clock estimates for genuinely time-bound things: the whole-CLI run (set the user's expectation up front — most CLIs take 30+ minutes), tool installs (`go install` takes ~10 seconds), and printing-press subcommands that do network-bound work (crowd-sniff scans npm + GitHub, ~5-10 minutes). Anything bounded by agent reasoning time is not time-bound — describe scope.
69	- Use raw captures for contract research. When reading official docs, auth/error/rate-limit pages, endpoint references, OpenAPI/Postman links, or source pages whose exact identifiers affect the generated CLI, read [references/fetch-docs.md](references/fetch-docs.md) and use its `fetch-docs.sh` helper. Reserve `WebFetch` for quick TL;DR reads where losing field-level details is acceptable.
70	- Optimize for time-to-ship, not time-to-document.
71	- Reuse prior research whenever it is already good enough.
72	- Do not split one idea across multiple mandatory artifacts.
73	- Durable files produced by this skill go under `$PRESS_RUNSTATE/` (working state) or `$PRESS_MANUSCRIPTS/` (archived). Short-lived command captures may use `/tmp/printing-press/` and must be removed after use.
74	- Do not create a separate narrative phase for dogfood, dead-code audit, runtime verification, and final score. Treat them as one shipcheck block.
75	- Run cheap, high-signal checks early.
76	- Fix blockers and high-lev

People who liked this also viewed

6 picks

Type