Regenerate an existing printed CLI from scratch under the current Printing Press, with prior research, prior novel features, and prior patches (post-publish hand-fixes) carried into the writing pipeline as reconciliation context rather than dropped on the floor. Pulls the CLI from the public library

/printing press reprint Regenerate an existing printed CLI under the current machine. The user gives a CLI name and (optionally) reasons for the reprint. This skill ensures the prior CLI is locally present, recommends whether to reuse or redo prior research, and hands off to /printing press with the context the novel features subagent needs to reconcile prior features against the current machine — keep, reframe, or drop with reasons, never silent. When to run A significant Printing Press upgrade (new MCP surface, new auth modes, new transport, scoring rubric changes) would lift this CLI more than manual polish. The published CLI ships with a known systemic gap a reprint would fix. The user wants prior novel features re evaluated against the current machine and current personas, not carried forward verbatim. For one off code quality fixes, prefer /printing press polish — it doesn't redo research or rebuild the manuscript. Setup Phase A — Resolve and reconcile presence Resolve the user's argument the same way /printing press import does: fetch the public library registry.json once, then exact → normalized → fuzzy match. The argument can be an API slug ( notion ), a brand name ( cal.com ), an old <api pp cli form, or close enough. Capture from the matched registry entry: API SLUG (from .name ) and LIB PATH (from .path , e.g., library/productivity/cal com ). Phase B uses $LIB PATH for the public patches fetch. For the "present absent" never published row, $LIB PATH stays empty — Phase B's fetch short circuits on that. Then check what exists locally and reconcile against the public library by reading both provenance manifests' run id and generated at : Local Public registry Action absent absent STOP — nothing to reprint; suggest /printing press <api for a fresh print absent present invoke /printing press import <api , then continue present absent continue — never published local CLI; skip import present, same run id present continue without import present, public newer generated at present offer import via AskUserQuestion ; user decides present, local newer generated at present STOP — local has unpublished work; tell user to publish or discard first When invoking /printing press import , let it own backup, overwrite, build verify, and module path rewrite. Wait for it to return clean before continuing. Phase B — Verify reconcilable prior context Locate the two artifacts the writing pipeline should be aware of: research (drives novel features Pass 2(d)) and patches (post publish hand fixes recorded by /printing press amend , e.g. live discovered API quirks the spec didn't reveal). Research absent If neither research path exists, the published CLI predates research.json provenance. The subagent will treat the run as a first print and Pass 2(d) reprint reconciliation will not fire — there is nothing for it to read. Surface this and ask: Published <api was built before research.json provenance landed. Without it, the novel features subagent will treat this as a first print — there is nothing to reconcile against. Continue as a degraded reprint (essentially a fresh print with a kept binary name)? If the user declines, exit. If they continue, record the absence so the hand off prompt notes that this is a degraded reprint. Patches discovery Refresh the local patches index from public when reachable, then read locally so downstream references are durable. Amends may have landed against the public copy without triggering a regen, so the local copy can lag even when run id matches; this step closes that gap. The index ships in one of two shapes: the per patch directory .printing press patches/ (current) or the legacy single array .printing press patches.json (older CLIs not yet normalized). Always check both shapes when reachable. Prefer the directory when it contains patch files, but never let an absent legacy single file index set PATCH COUNT=0 until the directory fallback has been read. If $PATCH COUNT == 0 or no index is present (older CLI predating the patches contract), skip the rest of this subsection — no patches block in the hand off. If $PATCH COUNT 0 , surface a one liner to the user before continuing: Public <api has $PATCH COUNT recorded patch(es) against the prior printed CLI. Carry them into the brief as a watch list. Regen and publish validate now read the records and fail closed if a recorded file or declared call site / pp:patch marker is gone — do not treat the index as a claim that the customization still shipped. Hold $PATCHES SOURCE and $PATCH COUNT for Phase D. Phase C — Recency recommendation Pull researched at from the most recent prior research.json and printing press version + generated at from .printing press.json : Compute the calendar age of the research with python3 so it stays portable across macOS/Linux and tolerates the microsecond precision that generated at carries (BSD date f rejects fractional seconds; python3 is on every supported platform): Surface both signals to the user — research age and prior machine version. Age thresholds are rules of thumb, not gates: under 30 days → reuse looks safe 30–120 days → reuse plausible; the user should mention any known API churn in their reprint reason so the subagent's Pass 2 picks it up over 120 days → redo recommended Don't predict API churn from age alone — describe the signals and let the user override. The Phase 0 binary version bump revalidation in /printing press handles the machine delta side independently; don't duplicate it here. Ask via AskUserQuestion : 1. Reuse prior research — keep the prior brief; the subagent re scores prior novel features against current personas 2. Redo research — re run Phase 1 of /printing press from scratch; the subagent still ingests prior novel features as Pass 2(d) input 3. Show me first — display the prior brief's headline + novel features list, then re ask between options 1 and 2 Phase D — Hand off to /printing press Before invoking /printing press , use the prior CLI's scorecard and manifest to decide whether the reprint should offer spec enrichment that the first print could not have used. Reprints have better evidence than fresh prints: they know which structural dimensions were weak, which Printing Press version produced the prior CLI, and what the user named as the reason for regenerating. Find the most recent scorecard JSON from the prior manuscript run. If no scorecard artifact exists, run a fresh structural scorecard against the local library copy: If SCORECARD JSON is empty, continue without enrichment prompting and say the reprint is proceeding without prior score evidence. Do not invent a prompt from the reprint reason alone. When SCORECARD JSON is available, inspect only dimensions that map to a pre generation spec edit and skip dimensions that already score 10/10: mcp remote transport , mcp token efficiency , mcp tool design , and mcp surface strategy below 10 can be lifted by the /printing press Phase 2 section Pre Generation MCP Enrichment . Examples: remote transport is below 10: offer mcp.transport: [stdio, http] or the OpenAPI x mcp.transport equivalent before regeneration. token efficiency, tool design, or surface strategy is below 10: offer the /printing press Phase 2 MCP surface decision, including intents for clear multi step workflows or the Cloudflare pattern for large surfaces. auth protocol below 10, or prior manifest evidence that the CLI used a slug derived env var where the ecosystem has a canonical env var, can be lifted by Pre Generation Auth Enrichment . Offer to carry canonical auth.env vars or OpenAPI x auth env vars guidance into the spec. data pipeline integrity below 10 is only an enrichment opportunity when the prior CLI or research shows sync eligible resources. In that case, point the handoff at the relevant /printing press Phase 2 sync/cache enrichment decision rather than treating the score alone as proof that a local store should exist. Use AskUserQuestion for each concrete opportunity before the handoff. Phrase the question around the scorecard evidence and the named canonical section, not around a freeform rewrite. Example: Prior scorecard shows mcp remote transport: 5/10 . Offer MCP transport enrichment before regenerating, using /printing press Phase 2 Pre Generation MCP Enrichment as the source of truth? Options: 1. Apply enrichment to the handoff include the selected spec edit in the /printing press prompt so Phase 2 can update the spec before generation. 2. Skip for this reprint leave the spec unchanged for this dimension. 3. Show score evidence first print the relevant scorecard lines and then re ask between options 1 and 2. Do not auto apply enrichment. If the prior scorecard already has mcp remote transport: 10/10 , do not ask the redundant MCP transport question. If the user accepts any opportunity, add a Reprint Spec Enrichment section to the /printing press handoff. Keep it brief: name the weak dimension, the accepted enrichment, and the canonical /printing press Phase 2 section to execute. Do not duplicate the canonical enrichment text here. Invoke /printing press <api and bundle these into the prompt: 1. A header line stating the user already chose to regenerate, so /printing press Phase 0's library check should select "Generate a fresh CLI" and not re prompt fresh vs improve. 2. Research mode from Phase C ( reuse or redo ). /printing press Phase 0's existing reuse logic consumes this. 3. The user's freeform reprint reason , verbatim, in a User context block. This propagates into the brief as User Vision and becomes Pass 2(e) input to the novel features subagent — the right hook for "I want better MCP support" → bias the brainstorm accordingly. 4. Reprint spec enrichment — only when the scorecard driven prompt above found an accepted opportunity. Include under a Reprint Spec Enrichment heading. 5. Prior patches — only when Phase B found $PATCH COUNT 0 . Include under a Prior Patches heading. Lead the section with this framing sentence, verbatim: The following were hand fixed against the prior printed CLI. They are informational — the machine may have absorbed some of these upstream since the patch was applied. Stay aware so the fresh code doesn't silently regress the underlying API truth or architectural pattern, but do not treat as a re apply checklist. Then summarize the patches from $PATCHES SOURCE . Lead each entry with the substance the patch encodes (the API truth, the architectural pattern, the cross file convention) drawn from each patch's reason and validated outcome — not just summary . Patch metadata ( id , files ) is fine as parenthetical context but never the headline. Scale the section to patch count: 1–3 patches : one short paragraph per patch — substance first, then how it manifested. Model the shape on: Linear's personal API keys go in Authorization: lin api … raw, with no Bearer prefix; OAuth tokens use Authorization: Bearer <token . The prior CLI shipped with auth set token only (Bearer defaulted) and was patched post publish to add auth set api key plus the raw header path in config.go ( linear auth api key vs oauth token ). 4–9 patches : one tight sentence per patch, same substance first shape. 10+ patches : thematic summary by category (auth, pagination, query encoding, MCP additions, helpers, classifiers, error envelopes). Two or three sentences per theme citing 2–3 patch id s as

printing-press-reprint