printing-press-retro
/printing-press-retro
Analyze a Printing Press session to find ways to improve the system that produces CLIs — the Go binary, templates, skills, and catalog. Not fixes to the specific CLI that was just printed, but improvements so the next CLI comes out stronger.
It is a non-goal for the Printing Press to produce flawless CLIs without manual tweaks. That's the nature of the system. We expect agents to reason over the generated CLI, customize for the specific API, build novel features, and iterate. Some hand-built work in every run is normal.
The retro's job is to find the subset of manual work where the machine could have realistically raised the floor — given the agent a better starting point, prevented the issue entirely, or eliminated friction that would recur on the next CLI. Two clear cases qualify:
- The machine could have completely prevented the issue, and the pattern is generalizable across many printed CLIs. File it.
- The machine could have raised the floor meaningfully — better default,
More from mvanhorn/cli-printing-press
printing-press
Generate a ship-ready CLI for an API with a lean research -> generate -> build -> shipcheck loop.
695printing-press-publish
Publish a generated CLI to the printing-press-library repo
673printing-press-polish
>
671printing-press-catalog
Browse and install pre-built Go CLIs for popular APIs from the catalog
670printing-press-output-review
>
669printing-press-score
Score a generated CLI against the Steinberger bar, compare two CLIs side-by-side
668