Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
mvanhorn avatar

Printing Press Import

  • 4.8k installs
  • 4.3k repo stars
  • Updated July 23, 2026
  • mvanhorn/cli-printing-press

printing-press-import is an agent skill: Bring a published CLI from the public library into the internal libraryso it's identical to a freshly-generated copy — module path reverted,

About

The printing-press-import skill Bring a published CLI from the public library into the internal libraryso it's identical to a freshly-generated copy — module path reverted,manuscripts placed alongside, ready for /printing-press-polish or/printing-press-emboss. Use when the public library has a CLI youdon't have locally, or to recover from a broken/lost internal copy.Trigger phrases: "import the CLI", "bring it into my library","fetch from public library", "I don't have it locally yet".. /printing-press-import Bring a published CLI from the public library ([`mvanhorn/printing-press-library`](https://github.com/mvanhorn/printing-press-library)) into the internal library at `$PRESS_LIBRARY/` so it matches the form the generator would produce. Manuscripts ride along. The internal library is the working copy; the public library is the durable artifact. After import, the CLI is ready for polish, emboss, or re-publish — the publish step will re-apply the module path rewrites. When to run - The public library has a CLI you don't have locally - The internal copy is broken, lost, or out of sync - You

  • Covers printing-press-import quick start, workflow steps, and reference pointers from SKILL.md.
  • Tagged for stage build and subphase agent-tooling in the closed Skillselion taxonomy.
  • Documents prerequisites, permissions shell, filesystem, git, and compatible agents.
  • Includes AEO tagMeta with task queries, keywords, and evidence quotes for discovery.
  • Cross-links related skills and generated REFERENCE.md tables where the repo provides them.

Printing Press Import by the numbers

  • 4,778 all-time installs (skills.sh)
  • +261 installs in the week ending Jul 28, 2026 (Skillselion tracking)
  • Ranked #38 of 560 CLI & Terminal skills by installs in the Skillselion catalog
  • Security screen: MEDIUM risk (skills.sh audit)
  • Data as of Jul 28, 2026 (Skillselion catalog sync)
At a glance

printing-press-import capabilities & compatibility

Capabilities
printing press import documented workflow · quick start examples · reference parameter lookup · taxonomy aligned metadata · aeo discovery fields
Works with
github
Use cases
orchestration · documentation
npx skills add https://github.com/mvanhorn/cli-printing-press --skill printing-press-import

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs4.8k
repo stars4.3k
Security audit1 / 3 scanners passed
Last updatedJuly 23, 2026
Repositorymvanhorn/cli-printing-press

How do I run printing-press-import correctly without guessing steps, tools, or parameters?

Bring a published CLI from the public library into the internal libraryso it's identical to a freshly-generated copy — module path reverted,manuscripts placed alongside, ready for /printing-press

Who is it for?

Teams using printing-press-import when SKILL.md triggers match the user request.

Skip if: Skip when the task is outside printing-press-import documented triggers or sibling skill scope.

When should I use this skill?

User mentions printing-press-import, related trigger phrases, or asks to follow this SKILL.md workflow.

What you get

Completed printing-press-import workflow with outputs and checks defined in SKILL.md.

  • printing-press-import output per SKILL.md

By the numbers

  • Stage build/agent-tooling
  • Category CLI & Terminal
  • Complexity intermediate

Files

SKILL.mdMarkdownGitHub ↗

/printing-press-import

Bring a published CLI from the public library (`mvanhorn/printing-press-library`) into the internal library at $PRESS_LIBRARY/ so it matches the form the generator would produce. Manuscripts ride along.

/printing-press-import notion
/printing-press-import cal.com
/printing-press-import allrecipes --from-clone ~/Code/printing-press-library

The internal library is the working copy; the public library is the durable artifact. After import, the CLI is ready for polish, emboss, or re-publish — the publish step will re-apply the module path rewrites.

When to run

  • The public library has a CLI you don't have locally
  • The internal copy is broken, lost, or out of sync
  • You want a clean baseline before running polish on a published CLI

If the user is asking to polish a CLI and mentions "in/from the public library" or "from the repo", suggest running this skill first.

Setup

PRESS_HOME="${PRINTING_PRESS_HOME:-$HOME/printing-press}"
PRESS_LIBRARY="$PRESS_HOME/library"
PRESS_MANUSCRIPTS="$PRESS_HOME/manuscripts"
SCRIPTS_DIR="$(dirname "${BASH_SOURCE[0]:-$0}")/references"

The four reference scripts live alongside this SKILL.md under references/:

  • import-fetch.sh <library-path> <staging> [--clone <path>]
  • import-backup.sh <api-slug> (prints zip path on stdout)
  • import-rewrite.sh <staging> <api-slug>
  • import-place.sh <staging> <api-slug>

Phase 1 — Resolve the CLI

The argument can be anything natural: an API slug (notion), a brand name (cal.com), an old CLI name (notion-pp-cli), or close enough (Allrecipes). Resolve via the public library's registry.json — which carries name, category, api, description, and path for every entry, in one fetch.

REGISTRY=$(mktemp)
gh api -H "Accept: application/vnd.github.v3.raw" \
  repos/mvanhorn/printing-press-library/contents/registry.json \
  > "$REGISTRY"

Match in this order:

1. Exact `name` matchjq --arg q "$ARG" '.entries[] | select(.name == $q)' "$REGISTRY" 2. Normalized exact — strip -pp-cli suffix, lowercase, dot→hyphen, then exact match 3. Substring on `name` or `description` — case-insensitive contains

# Exact:
jq --arg q "$ARG" '.entries[] | select(.name == $q)' "$REGISTRY"

# Normalized exact (after $ARG2 = lowercase, dot→hyphen, suffix-stripped):
jq --arg q "$ARG2" '.entries[] | select(.name == $q)' "$REGISTRY"

# Fuzzy (substring on name or description):
jq --arg q "$ARG2" '.entries[]
  | select((.name | ascii_downcase | contains($q | ascii_downcase))
        or (.description | ascii_downcase | contains($q | ascii_downcase)))
' "$REGISTRY"

If you get one match: use it. If multiple: present at most 4 to the user via AskUserQuestion showing name + description per candidate. If zero: tell the user the public library doesn't have that CLI.

The matched entry gives you everything you need:

  • LIB_PATH from .path (e.g., library/productivity/cal-com)
  • API_SLUG from .name
  • CATEGORY from .category

Don't slurp whole files when reasoning over candidates. The fields above are enough; if you genuinely need more, the per-CLI manifest is just <LIB_PATH>/manifest.json and the description there can be pulled the same way (gh api -H "Accept: ... raw" .../manifest.json | jq -r '.description').

Phase 2 — Decide on overwrite

Check whether the internal library already has this CLI:

LIB_TARGET="$PRESS_LIBRARY/$API_SLUG"
MAN_TARGET="$PRESS_MANUSCRIPTS/$API_SLUG"

If neither exists: straightforward import — proceed to Phase 3.

If either exists: read provenance from both sides to decide whether to overwrite. Don't read whole .printing-press.json files — pull just the fields that matter:

# Internal provenance (if present):
jq '{run_id, generated_at, printing_press_version, spec_checksum}' \
  "$LIB_TARGET/.printing-press.json" 2>/dev/null

# Public provenance (one-shot via raw):
gh api -H "Accept: application/vnd.github.v3.raw" \
  repos/mvanhorn/printing-press-library/contents/$LIB_PATH/.printing-press.json \
  | jq '{run_id, generated_at, printing_press_version, spec_checksum}'

Reason over the diff:

  • Same `run_id` — public is the same generation as internal. Likely

no-op; ask before clobbering. If the user wants to import anyway (e.g., to recover from a broken internal copy), proceed.

  • Public newer `generated_at` — public has changes the internal

doesn't. Importing is the safe move; ask the user to confirm.

  • Internal newer `generated_at` — internal has work the public

doesn't (in-progress polish, manual fixes). Importing would clobber that. Stop and surface this to the user — they likely want to publish the internal changes first.

  • Either side missing `.printing-press.json` — older or hand-imported.

Ask the user.

When the user confirms overwrite, the backup step in Phase 3 captures the current internal state.

Phase 3 — Import

STAGING=$(mktemp -d)

# Fetch (remote unless --from-clone was passed)
if [[ -n "${CLONE_PATH:-}" ]]; then
  bash "$SCRIPTS_DIR/import-fetch.sh" "$LIB_PATH" "$STAGING" --clone "$CLONE_PATH"
else
  bash "$SCRIPTS_DIR/import-fetch.sh" "$LIB_PATH" "$STAGING"
fi

# Backup if anything is being clobbered. Prints zip path on stdout.
if [[ -d "$LIB_TARGET" || -d "$MAN_TARGET" ]]; then
  BACKUP_ZIP=$(bash "$SCRIPTS_DIR/import-backup.sh" "$API_SLUG")
  echo "Backed up to: $BACKUP_ZIP"
fi

# Reverse the publish-step module path rewrites.
bash "$SCRIPTS_DIR/import-rewrite.sh" "$STAGING" "$API_SLUG"

# Atomically move staging into place.
bash "$SCRIPTS_DIR/import-place.sh" "$STAGING" "$API_SLUG"

Phase 4 — Verify internal consistency

After the move, confirm the imported CLI builds and is structurally intact. Treat any failure as a real problem — don't paper over it.

cd "$LIB_TARGET"

# Module path is local form
grep -q "^module ${API_SLUG}-pp-cli\$" go.mod \
  || { echo "FAIL: go.mod still on public module path"; exit 1; }

# No public module path leaked into source
if grep -rq "github.com/mvanhorn/printing-press-library/library" \
   --include='*.go' --include='*.yaml' --include='*.yml' .; then
  echo "FAIL: source still references public module path"
  exit 1
fi

# Build
go build ./... \
  || { echo "FAIL: go build"; exit 1; }

# Doctor (self-check)
make doctor 2>/dev/null \
  || ./bin/${API_SLUG}-pp-cli doctor 2>/dev/null \
  || true   # best-effort; not all CLIs have doctor wired the same way

Report the import outcome:

  • Source path (from registry: <category>/<api-slug>)
  • Run ID (from .printing-press.json)
  • Manuscripts run-ids placed (count + names)
  • Backup zip path (if any)
  • Build status

Polish-side hint

If the user's request to import was triggered by a polish ask (e.g., they said "polish notion in the public library"), suggest:

Imported $API_SLUG. To polish: /printing-press-polish $API_SLUG

The polish skill operates on the internal library, so import-then-polish is the right flow when starting from a published CLI.

Related skills

How it compares

printing-press-import implements its own SKILL.md workflow rather than a generic substitute skill.

FAQ

Who is printing-press-import for?

Agents and developers following the printing-press-import SKILL.md guidance.

When should I use printing-press-import?

When user intent matches description triggers and quick start scenarios.

Is printing-press-import safe to install?

Review the Security Audits panel before production shell or network use.

CLI & Terminalintegrationsgit

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.