Bring a published CLI from the public library into the internal library so 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 you don't have locally, or to

/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 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 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 If setup emitted [low disk] , surface the advisory to the user and continue unless setup also emitted [setup error] . [low disk] means this run may need several GiB for repository clones, staged files, backups, Go build cache, or module downloads. 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. Match in this order: 1. Exact name match — jq 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 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: 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: 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 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. 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: The polish skill operates on the internal library, so import then polish is the right flow when starting from a published CLI.

printing-press-import