wise-init

/wise-init — first-time setup wizard

Why this skill exists

Before 0.41.0, every workflow-adjacent wise skill ran scripts/bootstrap-deps.sh as its first step — probing Python, Node, and the gh CLI on every invocation. That was correct but slow on the hot path and clumsy for fresh installs: the user got piecemeal "install X, now install Y, now gh auth login" across successive skill invocations instead of one guided walkthrough.

/wise-init is that walkthrough. It probes each dep in turn, shows installer options with exact commands to paste when something's missing, pauses for the user to run them, re-probes, and finally writes a registry file the workflow engine consumes as a fast-path on every subsequent run. Re-runs are cheap — the wizard skips deps that are already present.

The registry lives at ${CLAUDE_PLUGIN_ROOT}/.wise-init-registry.yaml. That's inside the plugin install dir on purpose — it gets wiped on every /plugin install wise@…, which is exactly the invalidation signal we want: "the plugin updated, something new might be required, user should re-init".

Arguments

This skill takes no arguments. Ignore anything the user types beyond the skill name.

Procedure

1. Preamble

Print one short paragraph to the user introducing the flow. Keep it under 4 lines:

First-time setup. I'll walk you through the system deps wise needs —
Python 3, Node ≥22, the gh CLI (with auth), and markitdown (file →
markdown text extraction). Re-runs are safe: I skip what's already
installed. After this I cache the probe results so future workflow
runs skip the live check.

2. Python (and its pip modules)

2a. Probe.

bash "${CLAUDE_PLUGIN_ROOT}/scripts/init.sh" probe-python

The probe emits bare KEY=VALUE lines — STATUS, BINARY, VERSION, MODULE_YAML, MODULE_ULID, MODULE_TYPING_EXTENSIONS (all three probes reuse the same bare key names by design; see init.sh). Read them into per-dep Claude-side variables — referred to below as PY_STATUS, PY_BINARY, PY_VERSION, PY_MODULE_*.