printing-press-retro

Name: printing-press-retro
Author: mvanhorn

4.6kinstalls453forks

How to install printing-press-retro?

mvanhorn/cli-printing-press/printing-press-retro

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

Installs into the current project.

Summary

Run a retrospective after generating a CLI. Identifies systemic improvements to the Printing Press — templates, Go binary, skill instructions, and workflow docs — so the next CLI comes out better. Creates a GitHub issue with actionable findings when there are Printing Press fixes

Files · 1

View on GitHub

SKILL.md

1	# /printing-press-retro
2
3	Analyze a Printing Press session to find ways to improve the system that produces
4	CLIs — the Go binary, templates, skills, and workflow docs. Not fixes to the specific CLI
5	that was just printed, but improvements so the next CLI comes out stronger.
6
7	**It is a non-goal for the Printing Press to produce flawless CLIs without manual
8	tweaks.** That's the nature of the system. We expect agents to reason over the
9	generated CLI, customize for the specific API, build novel features, and iterate.
10	Some hand-built work in every run is normal.
11
12	The retro's job is to find the subset of manual work where **the machine could
13	have realistically raised the floor** — given the agent a better starting point,
14	prevented the issue entirely, or eliminated friction that would recur on the
15	next CLI. Two clear cases qualify:
16
17	1. **The machine could have completely prevented the issue, and the pattern is
18	generalizable across many printed CLIs.** File it.
19	2. The machine could have raised the floor meaningfully — better default,
20	partial scaffold, helper that absorbs the boilerplate — **across multiple
21	CLIs you can name with evidence.** File it.
22
23	Otherwise, the manual work is normal iteration and should not generate a finding.
24	Some items make it back as machine fixes; not all. The retro is the filter that
25	distinguishes the two.
26
27	The retro creates a GitHub issue on the printing-press repo with the findings
28	that survive triage and the adversarial check, plus artifacts, so maintainers
29	(or an AI agent) can fix the Printing Press.
30
31	## Terminology
32
33	- The Printing Press: The whole system that produces CLIs. Use this name in all
34	user-facing output (issues, retros, prompts). It has four subsystems:
35	- Generator — templates that emit Go code (`internal/generator/`)
36	- Scorer — tools that grade the output: verify, dogfood, scorecard
37	- Skills — SKILL.md instructions that guide Claude during generation
38	- Binary — the Go CLI itself: commands, flags, parsers (`cmd/cli-printing-press/`)
39	- Printed CLI: A CLI produced by the Printing Press for a specific API (e.g.,
40	`notion-pp-cli`). Printed-CLI fixes only help that one CLI.
41
42	Use "the Printing Press" when talking about the system. Use the subsystem name when
43	pointing a developer at what to fix — "fix the scorer" and "fix the generator" are
44	different PRs.
45
46	## Cardinal rules
47
48	- Issue bodies and retro docs are public surfaces. Redact every real secret and PII before quoting. Manuscripts contain credentials, account identifiers, real emails, and live API response data — that's why `references/secret-scrubbing.md` scrubs them before artifact upload. Issue body text goes straight to a public GitHub issue, and the retro doc itself is preserved in manuscript proofs and may be uploaded as a zip. When you quote scanner output, dogfood payloads, Greptile review comments, or API response bodies as "evidence," replace the sensitive substring with `<REDACTED:<kind>>` BEFORE pasting. This applies hardest to findings about secret/PII leaks: the natural impulse is to quote the actual leaked value to prove the leak exists — that re-leaks it in a public issue. Phase 5 (retro doc write) and Phase 6 (pre-post scrub) enforce this mechanically; this rule is the human-readable charter behind the mechanical enforcement. See [`references/secret-scrubbing.md`](references/secret-scrubbing.md) "Layer 0" for the redaction patterns and substitution shapes.
49	- Default is "don't change the machine." The Printing Press is mature — 30+ CLIs printed, most templates exercised across many shapes. The burden of proof is on the finding, not on the Skip path. Most things you encountered while printing one CLI are that CLI's quirks, iteration noise, or upstream API behavior — not generator gaps. Propose a machine change only when cross-CLI evidence is concrete and the finding survives the Phase 3 adversarial check (Step G).
50	- A retro of three sharp findings is more valuable than ten mixed-quality findings. Each filed finding spends maintainer attention. If you find yourself writing "every finding warrants action" or producing zero drops and zero skips, stop and re-triage — that outcome is the failure mode this skill exists to prevent.
51	- The retro proposes Printing Press changes tha

People who liked this also viewed

6 picks

Type

printing-press-retro

4.6kinstalls453forks

View on GitHub

How to install printing-press-retro?

mvanhorn/cli-printing-press/printing-press-retro

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

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# /printing-press-retro
2
3	Analyze a Printing Press session to find ways to improve the system that produces
4	CLIs — the Go binary, templates, skills, and workflow docs. Not fixes to the specific CLI
5	that was just printed, but improvements so the next CLI comes out stronger.
6
7	**It is a non-goal for the Printing Press to produce flawless CLIs without manual
8	tweaks.** That's the nature of the system. We expect agents to reason over the
9	generated CLI, customize for the specific API, build novel features, and iterate.
10	Some hand-built work in every run is normal.
11
12	The retro's job is to find the subset of manual work where **the machine could
13	have realistically raised the floor** — given the agent a better starting point,
14	prevented the issue entirely, or eliminated friction that would recur on the
15	next CLI. Two clear cases qualify:
16
17	1. **The machine could have completely prevented the issue, and the pattern is
18	generalizable across many printed CLIs.** File it.
19	2. The machine could have raised the floor meaningfully — better default,
20	partial scaffold, helper that absorbs the boilerplate — **across multiple
21	CLIs you can name with evidence.** File it.
22
23	Otherwise, the manual work is normal iteration and should not generate a finding.
24	Some items make it back as machine fixes; not all. The retro is the filter that
25	distinguishes the two.
26
27	The retro creates a GitHub issue on the printing-press repo with the findings
28	that survive triage and the adversarial check, plus artifacts, so maintainers
29	(or an AI agent) can fix the Printing Press.
30
31	## Terminology
32
33	- The Printing Press: The whole system that produces CLIs. Use this name in all
34	user-facing output (issues, retros, prompts). It has four subsystems:
35	- Generator — templates that emit Go code (`internal/generator/`)
36	- Scorer — tools that grade the output: verify, dogfood, scorecard
37	- Skills — SKILL.md instructions that guide Claude during generation
38	- Binary — the Go CLI itself: commands, flags, parsers (`cmd/cli-printing-press/`)
39	- Printed CLI: A CLI produced by the Printing Press for a specific API (e.g.,
40	`notion-pp-cli`). Printed-CLI fixes only help that one CLI.
41
42	Use "the Printing Press" when talking about the system. Use the subsystem name when
43	pointing a developer at what to fix — "fix the scorer" and "fix the generator" are
44	different PRs.
45
46	## Cardinal rules
47
48	- Issue bodies and retro docs are public surfaces. Redact every real secret and PII before quoting. Manuscripts contain credentials, account identifiers, real emails, and live API response data — that's why `references/secret-scrubbing.md` scrubs them before artifact upload. Issue body text goes straight to a public GitHub issue, and the retro doc itself is preserved in manuscript proofs and may be uploaded as a zip. When you quote scanner output, dogfood payloads, Greptile review comments, or API response bodies as "evidence," replace the sensitive substring with `<REDACTED:<kind>>` BEFORE pasting. This applies hardest to findings about secret/PII leaks: the natural impulse is to quote the actual leaked value to prove the leak exists — that re-leaks it in a public issue. Phase 5 (retro doc write) and Phase 6 (pre-post scrub) enforce this mechanically; this rule is the human-readable charter behind the mechanical enforcement. See [`references/secret-scrubbing.md`](references/secret-scrubbing.md) "Layer 0" for the redaction patterns and substitution shapes.
49	- Default is "don't change the machine." The Printing Press is mature — 30+ CLIs printed, most templates exercised across many shapes. The burden of proof is on the finding, not on the Skip path. Most things you encountered while printing one CLI are that CLI's quirks, iteration noise, or upstream API behavior — not generator gaps. Propose a machine change only when cross-CLI evidence is concrete and the finding survives the Phase 3 adversarial check (Step G).
50	- A retro of three sharp findings is more valuable than ten mixed-quality findings. Each filed finding spends maintainer attention. If you find yourself writing "every finding warrants action" or producing zero drops and zero skips, stop and re-triage — that outcome is the failure mode this skill exists to prevent.
51	- The retro proposes Printing Press changes tha

People who liked this also viewed

6 picks

Type