Skill v1.0.1
Automated scan100/100+3 new
version: "1.0.1" name: printing-press-reprint description: > 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 if it isn't local, recommends reuse-vs-redo of prior research based on age, then hands off to /printing-press with the right context. Use when a machine upgrade would benefit a published CLI more than manual polish. Trigger phrases: "reprint <api>", "regenerate <api>", "redo the <api> CLI", "rebuild <api> from scratch", "this CLI would benefit from a reprint". allowed-tools:
- Bash
- Read
- AskUserQuestion
- Skill
/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.
/printing-press-reprint notion/printing-press-reprint cal.com the new MCP intent surface landed and the prior CLI ships endpoint-mirror only/printing-press-reprint allrecipes
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
PRESS_HOME="$HOME/printing-press"PRESS_LIBRARY="$PRESS_HOME/library"PRESS_MANUSCRIPTS="$PRESS_HOME/manuscripts"
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).
LIB_TARGET="$PRESS_LIBRARY/$API_SLUG"LIB_RESEARCH="$LIB_TARGET/research.json"MAN_RESEARCH=$(ls -1t "$PRESS_MANUSCRIPTS/$API_SLUG"/*/research.json 2>/dev/null | head -1)
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 beforeresearch.jsonprovenance landed.Without it, the novel-features subagent will treat this as a firstprint — there is nothing to reconcile against. Continue as a degradedreprint (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 file 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 file can lag even when run_id matches; this step closes that gap. The fetch writes to a temp file and atomically renames on success, so a partial transfer never replaces a good local copy.
PATCHES_SOURCE="$LIB_TARGET/.printing-press-patches.json"if [[ -n "$LIB_PATH" ]]; thenPATCHES_TMP=$(mktemp)if gh api -H "Accept: application/vnd.github.v3.raw" \"repos/mvanhorn/printing-press-library/contents/$LIB_PATH/.printing-press-patches.json" \> "$PATCHES_TMP" 2>/dev/null; thenmv "$PATCHES_TMP" "$PATCHES_SOURCE"elserm -f "$PATCHES_TMP"fifiPATCH_COUNT=$(jq '.patches | length' "$PATCHES_SOURCE" 2>/dev/null || echo 0)
If $PATCH_COUNT == 0 or the file is missing entirely (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_COUNTrecorded patch(es) against the priorprinted CLI. Will carry into the brief as a watch-list (informational,not a re-apply mandate) so the fresh code doesn't silently regresslive-validated fixes.
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:
RESEARCHED_AT=$(jq -r '.researched_at // empty' "$MAN_RESEARCH" 2>/dev/null)PRESS_VERSION=$(jq -r '.printing_press_version // empty' "$LIB_TARGET/.printing-press.json" 2>/dev/null)GENERATED_AT=$(jq -r '.generated_at // empty' "$LIB_TARGET/.printing-press.json" 2>/dev/null)
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):
AGE_DAYS=$(python3 -c "from datetime import datetime, timezonets = '$RESEARCHED_AT'.replace('Z', '+00:00')print(int((datetime.now(timezone.utc) - datetime.fromisoformat(ts)).total_seconds() // 86400))" 2>/dev/null)
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:
- Reuse prior research — keep the prior brief; the subagent re-scores
prior novel features against current personas
- Redo research — re-run Phase 1 from scratch; the subagent still
ingests prior novel features as Pass 2(d) input
- 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
Invoke /printing-press <api> and bundle these into the prompt:
- A header line stating the user already chose to regenerate, so
Phase 0's library-check should select "Generate a fresh CLI" and not re-prompt fresh-vs-improve.
- Research mode from Phase C (
reuseorredo). Phase 0's existing
reuse logic consumes this.
- 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.
- 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 ids as evidence. Do not enumerate all entries inline.
Close the section with a pointer so a downstream agent can drill into any specific patch when working in the relevant area:
> Full patch detail: $PATCHES_SOURCE. Schema: > PatchesIndex in internal/pipeline/climanifest.go.
Do not pass a separate "this is a reprint" marker. The novel-features subagent runs unconditionally on every print and discovers prior research via its own discovery snippet (see skills/printing-press/references/novel-features-subagent.md). The paths import populated in Phase A are exactly the paths it checks; Pass 2(d) fires whenever prior research.json exists.
After hand-off
The printing-press flow drives the rest. Don't summarize its work — let the user see the live phases.
If /printing-press halts with the subagent's pre-flight HALT (brief lacks concrete Users / Top Workflows content), the reused prior brief predates the subagent's required schema. Recommend re-running with Redo research selected at Phase C.