From cli-printing-press
Imports a published CLI from the printing-press public library into your local ~/printing-press/library/, reverting module paths and placing manuscripts alongside. Use when missing locally or recovering broken copies before polish or emboss.
npx claudepluginhub mvanhorn/cli-printing-press --plugin cli-printing-pressThis skill is limited to using the following tools:
Bring a published CLI from the public library
Publishes generated CLIs from local printing-press library to printing-press-library GitHub repo via pull request. Handles mirrors, manifests, and PR creation.
Imports external skills, templates, or agents into a repository's v0.2 Claude Code plugin architecture. Supports /agentic-import with --plugin, --force, --dry-run options.
Performs Phase 4 quality gate for cli-web Python CLIs: 3-agent implementation review, 75-check checklist, pip package publishing, and read/write smoke tests.
Share bugs, ideas, or general feedback.
Bring a published CLI from the public library
(mvanhorn/printing-press-library)
into the internal library at ~/printing-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.
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.
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>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:
name match — jq --arg q "$ARG" '.entries[] | select(.name == $q)' "$REGISTRY"-pp-cli suffix, lowercase, dot→hyphen, then exact matchname 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 .nameCATEGORY from .categoryDon'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').
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:
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.generated_at — public has changes the internal
doesn't. Importing is the safe move; ask the user to confirm.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..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.
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"
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:
<category>/<api-slug>).printing-press.json)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.