cli/skills/deploy/SKILL.md

name, description

name

description

deploy

Batch install, update, or uninstall the whole jsc skill set on every installed AI CLI. Detect CLIs via detect-clis.sh, report every plugin's local-versus-published version first and recommend update when any one of them is behind, then ask the user for the mode via decision tree, then run each CLI's native plugin commands with the unified jsc marketplace (token jsc-{domain}@jsc). Domain list comes from the plugins/meta marketplace.json, never hardcoded. Use for rollout or removal of the jsc plugins; not for a single skill.

deploy — batch install, update, or uninstall the skill set

Steps

1. Run tools/detect-clis.sh to find the installed CLIs and their executable paths. Done when the TSV lists at least one CLI with an executable path.

2. Check versions before asking anything, so the recommendation is based on fact rather than a guess:

   1. Run jsc-hooks/hooks/version-guard.sh report. It prints one line per installed jsc plugin — {domain}<TAB>{本機}<TAB>{遠端}<TAB>{落後|最新|超前|查詢失敗} — and a final behind<TAB>{落後個數}.
   2. No local plugin registry → report this CLI as unverifiable, never as up to date. Two forms of the same fact: a report carrying no {domain} row at all before the behind line, or the script's explicit no-registry line (noregistry<TAB>{路徑}). Both mean the version check could not run for this CLI, so behind<TAB>0 here proves nothing. State that plainly and base no recommendation on it.
   3. Show that table to the user as-is. It is the evidence behind the recommendation, so never summarise it away.
   4. behind ≥ 1 → mark update as the recommended option, and name every domain that is behind together with its local and remote version. One domain behind is enough; do not wait for a majority.
   5. behind = 0 with at least one domain row → recommend nothing; present the three options neutrally.
   6. 查詢失敗 on any domain → say so explicitly. An unverified domain is not the same as an up-to-date one, and must not be counted as either.

   Done when the report is shown and either every domain row carries one of the four status literals 落後 最新 超前 查詢失敗, or the CLI is reported as having no local registry and therefore unverifiable.

3. Ask the user for the mode per the jsc-ask:ask rules: install / update / uninstall. Every option states its impact scope: which CLIs it touches and which configs it writes. Done when the user has named exactly one of install, update or uninstall.

4. Get the domain list (never hardcode it; this skill follows automatically when domains are added or removed): read plugins[].name from the unified marketplace via jsc-gitea/tools/gitea.sh api GET /repos/plugins/meta/raw/.claude-plugin/marketplace.json. The marketplace is unified as jsc; the install token is jsc-{domain}@jsc. Each plugins[].name already carries the jsc- prefix (e.g. jsc-ask) — pass it to tools/deploy.sh as-is, prefixed or not; the script normalizes it. Done when the domain list comes from that response and holds at least one name.

5. Run tools/deploy.sh {mode} {cli} {domain}... once per detected CLI, passing the whole domain list in one call so the marketplace command runs only once. This step MUST run as a sub agent (one sub agent per CLI). The script prints cmd and exit lines for every command, then one result line; -n prints the commands without running them. Antigravity cannot install from a Gitea URL, so the script clones each domain into the local plugin directory (JSC_LOCAL_PLUGINS, default $JSC_HOME/plugins) and installs from that path — keep that clone, because update pulls the same one. That default deliberately avoids a development checkout: when the directory holds uncommitted changes or unpushed commits, the script prints a skip line, leaves the tree untouched, and installs the on-disk content. Done when every detected CLI has reported an exit status for every command it ran.

6. After install or update, call jsc-hooks:hooks-install to rewire the hooks. Done when hooks-install reports a wiring result for each detected CLI.

7. Report the result and any failure reason for every CLI × mode, plus every skip line and every CLI that could not be version-checked in step 2. Done when every detected CLI appears in the report with its result status.