Polish a generated CLI to pass verification and become publish-ready. Runs diagnostics (dogfood, verify, scorecard, go vet, gosec), automatically fixes all issues (verify failures, static-analysis findings, dead code, descriptions, README, MCP tool quality), reports the before/after delta, and offer

/printing press polish Polish a generated CLI so it passes verification and is ready to publish. The retro improves the Printing Press. Polish improves the generated CLI. This skill runs in a forked context ( context: fork ) so its diagnostic and fix loop doesn't pollute the caller — the diagnostic spam, fix iterations, and re diagnose noise stay scoped to the polish session, and the caller receives a clean summary. When to run After any /printing press generation, especially when: The shipcheck verdict is ship with gaps The verify pass rate is below 80% The scorecard is below 85 You want the CLI publish ready in one pass Can also be run standalone on any CLI in $PRESS LIBRARY/ . Setup After setup, capture PRINTING PRESS BIN=<abs path and use that absolute path for every cli printing press ... invocation in this skill. If setup emitted [go toolchain old] or [low disk] , surface the advisory to the user and continue unless setup also emitted [setup error] . [go toolchain old] means later Go commands may download the required toolchain or fail when downloads are blocked; [low disk] means this run may need several GiB for generated files, Go build cache, module downloads, or repository clones. Check binary version compatibility by reading the min binary version field from this skill's YAML frontmatter, running "$PRINTING PRESS BIN" version json , and parsing the version from the output. Compare it to min binary version using semver rules. If the installed binary is older than the minimum, stop immediately and tell the user: "cli printing press binary vX.Y.Z is older than the minimum required vA.B.C. Run go install github.com/mvanhorn/cli printing press/v4/cmd/cli printing press@latest to update." Public library hint If the user's request includes phrasing like "polish notion in the public library ", "polish from the public library ", or "polish the published cal com" — and the named CLI is not in $PRESS LIBRARY/<slug / — they're asking to polish a CLI that lives upstream but not locally. Polish runs against the internal library, so the right move is to import first. Suggest: /printing press import <slug to bring it in, then re run polish. Don't try to polish a CLI that isn't in the internal library. If the named CLI is already in $PRESS LIBRARY/<slug / , the "public library" phrasing is informational — just proceed with polish and let the divergence check (below) handle any drift. Resolve CLI The argument string can contain a standalone flag plus one positional value (a slug, binary name, or path). In standalone slash command mode, it may also contain a free text scope after the optional positional value, such as /printing press polish sculptok review the open PR comments and fix them . That trailing natural language text is the user's own trusted user scope. Carry it forward into the polish plan and result block; do not classify it as injection or tampering. It can also contain a Phase 3 gate bundle and a printing press bin: <abs path line on following lines when invoked by the main printing press skill. The flag may appear before or after the positional value; it is the only flag this skill consumes from args . Strip it before path resolution. When args is multi line, treat the first non empty line as the positional value/scope line and parse the remaining lines as the optional Phase 3 gate bundle. Do not include the bundle text in path resolution. Parse caller modes differently: Standalone slash command ( STANDALONE MODE=true ). After stripping standalone , try to resolve the first shell word as a slug, binary name, or path. If it resolves, use it as the positional value and store the remaining words as USER SCOPE . If it does not resolve, treat the whole line as free text scope; this branch asks which CLI to polish and retains that scope for the chosen CLI. If there is no trailing text after a resolved positional value, run the normal generic polish pass. Mid pipeline Skill tool call. Keep the strict grammar: one path like positional value on the first line plus the optional structured bundle on later lines. Unexpected free text in this machine generated path is not a user scope and should still be rejected or clarified rather than folded into the run. The positional value can be: A short name: redfin (looks up $PRESS LIBRARY/redfin ) A full name: redfin pp cli (strips suffix, looks up $PRESS LIBRARY/redfin ) A path: $PRESS LIBRARY/redfin (used directly) Resolution order for the positional value: 1. If it is an absolute or ~ prefixed path and exists, use it 2. Try $PRESS LIBRARY/<arg (exact match — works for slug like redfin ) 3. If it has pp cli suffix, strip it and try $PRESS LIBRARY/<slug (e.g., redfin pp cli → redfin ) 4. Fuzzy search: ls $PRESS LIBRARY/ grep i <arg for close matches Caller scenarios and the standalone flag. Polish has two callers; they invoke it through different mechanisms, and the Publish Offer at the end of this skill fires only when STANDALONE MODE is true. Determine STANDALONE MODE from the caller mode and the flag, not from the resolved path. Standalone (user invoked, /printing press polish redfin ). Invoked via the slash command. Treat as STANDALONE MODE=true unconditionally — the slash command form is the publish intent surface, even when the user omits the flag. The arg is a slug or binary name; resolution lands on $PRESS LIBRARY/<slug / . This is the published copy and the right target. Mid pipeline (main printing press skill Phase 5.5, hold path "Polish to retry"). Invoked via the Skill tool with args: "$CLI WORK DIR" . The arg is an absolute path to ~/printing press/.runstate/.../runs/.../working/<api pp cli/ ; resolution must hit rule 1. STANDALONE MODE=false by default — main SKILL owns the publish flow on this path, so polish defers. Do not paraphrase the arg to the slug — Phase 5.5 fires before the working CLI is promoted, so $PRESS LIBRARY/<slug / either doesn't exist or holds the prior run's stale CLI. Skill tool standalone override. A non slash caller that genuinely wants polish to publish must opt in explicitly by including standalone in args (e.g., args: " standalone $PRESS LIBRARY/redfin" ). Without that token, polish never publishes from a Skill tool invocation — even if the resolved path happens to live under $PRESS LIBRARY/ . The flag is the contract; the path is not. This caller mode driven gate replaces the older path substring heuristic ( .runstate/ ). The heuristic broke when the main SKILL's Phase 5.5/5.6 ordering inverted, or when polish was invoked from a non .runstate scratch layout: polish would see a $PRESS LIBRARY/<slug / path, conclude "standalone," and fire its Publish Offer (fork, global git config, public PR) inside a mid pipeline run. The flag is unambiguous and the safer default is no publish. Phase 3 gate bundle Mid pipeline callers pass these fields after the CLI path in args : Parse the bundle before diagnostics and keep the values available for ship logic. Missing bundle fields mean "no forced Phase 3 hold"; they do not block standalone polish. If prior sub60 reprint: true , phase3 transcendence rows missing contains any row, and partial transcendence override is empty or none , polish must emit ship recommendation: hold even if the local diagnostics are otherwise clean. Add the missing rows to remaining issues so the parent skill can show the specific gate that blocked promotion. The lock status check in the next code block is the safety net for the mid pipeline scenario: if a build lock is held for this CLI (under either name form), polish refuses to run. cli printing press lock normalizes slug ↔ binary name internally, so the check works regardless of which form the basename produces. If no match or multiple matches, present via AskUserQuestion . Show at most 4 matches sorted by modification time (most recent first) with human friendly relative timestamps (e.g., "generated 2 hours ago"). Find spec and research dir Divergence check Stop and run this step before Phase 1. Do not skip it. Do not proceed to diagnostics until you have completed the check and resolved any divergence. The internal copy at $CLI DIR can drift from the public library ( mvanhorn/printing press library ) copy if anyone edited the public repo directly after this CLI was last published. Polishing a stale internal copy and re publishing later silently overwrites those public only fixes — a real failure mode that shipped CLIs hit. You must: 1. Locate the public library clone. Honor $PRINTING PRESS LIBRARY PUBLIC if set; otherwise scan the user's filesystem however fits this platform. Validate every candidate by checking the git remote points at mvanhorn/printing press library — other directories may share the name (forks, accidental name collisions). If multiple valid clones exist, prefer the most recently modified; ask the user to disambiguate only if still unclear. 2. Locate this CLI inside the clone. find <clone /library type d name "<api pp cli" or equivalent. 3. Run diff r <public cli dir $CLI DIR with these exclusions, all of which are expected to diverge after publish: .printing press tools polish.json (local ledger, not published) .printing press pii polish.json (local ledger, not published) go.mod and go.sum — publish rewrites the module path from <api pp cli to github.com/mvanhorn/printing press library/library/<category /<api All .go files where the only difference is the rewritten import path (the publish step propagates the new module path through every internal import). When inspecting .go diffs, scan for substantive changes — anything beyond the module path prefix swap is real divergence. Concretely: diff r exclude=go.mod exclude=go.sum exclude=.printing press tools polish.json exclude=.printing press pii polish.json <public cli dir $CLI DIR . Don't pass exclude='<api pp cli' or exclude='<api pp mcp' — those names match both the root level binary files and the cmd/<api pp cli/ and cmd/<api pp mcp/ source directories. Excluding by binary name silently skips the entire cmd/ subtree, hiding real divergence in main.go . The "Only in $CLI DIR: <api pp cli" line for the built binary is one row of expected output, not noise worth filtering at the cost of completeness. 4. Surface the result before continuing. Outcomes: No clone found → user doesn't have public locally. State this explicitly ("public library not found locally; proceeding on internal as canonical") and continue. Clone found but doesn't contain this CLI → never published or under a different name. State this and continue. Found and diff is empty → in sync. State this and continue. Found and divergent → stop . Do not run Phase 1 diagnostics yet. List the divergent files for the user. Ask via AskUserQuestion: sync public→internal , or proceed without syncing . If the user picks sync, copy public's version of the divergent files into internal, then continue polish on the synced internal copy. Before showing the sync prompt, check whether internal has files modified after its .printing press.json timestamp (the user has been polishing locally without publishing). If yes, hedge the prompt explicitly: syncing will overwrite their pending local work. Let them decide whether to keep their local edits or pull public's. After sync (or explicit skip), the rest of polish operates on $CLI DIR as canonical. The eventual /printing press publish step pushes internal back to public; no second divergence check is needed there. The check has run only when one of the four outcomes above is explicitly stated in your response. Silent omission counts as not having run it. Phase 1: Baseline diagnostics verify skill and workflow

printing-press-polish