feat(marketplace): add 'Check for Updates' action using skills CLI update command

[ryota-murakami]

Summary

Skills CLI v1.5.0 added skills update [name] -g/-p with interactive scope selection (project/global/both) and per-skill targeting. Integrate this into the app's marketplace UI.

Motivation

Users currently have no way to check if their installed skills have newer versions available. The CLI now supports this via lock file v3 (skillFolderHash comparison), but it requires terminal access.

Proposed Implementation

• Add "Check for Updates" button in the Marketplace dashboard or Installed tab
• Call skills update --json (or equivalent IPC) to get update-available list
• Show updatable skills with a one-click "Update" action
• Support both global and project scope

Reference

• Skills CLI source: /Users/ryotamurakami/clone/skills/src/cli.ts (runUpdate)
• CLI version: v1.5.0
• Related: skills update -g -y for non-interactive global update

[ryota-murakami]

Investigation — blocked on a skills-CLI capability gap

I scoped this against the pinned CLI version (SKILLS_CLI_VERSION = 1.5.11 in src/shared/constants.ts) by reading the raw source at the v1.5.11 tag, and cross-checked the local 1.5.10 clone. The proposed implementation isn't feasible as written, for two concrete reasons:

1. skills update has no --json output

parseUpdateOptions (src/update.ts) only parses -g/--global, -p/--project, -y/--yes, and positional skill names. The global --json flag advertised in --help is honored only by ls/find (skills ls --json), not by update — runUpdate has no JSON branch and emits ANSI-colored human text via console.log.

2. update has no check-only / dry-run mode

There is no --dry-run / check-only path. runUpdate → updateGlobalSkills/updateProjectSkills checks and applies in the same pass — it compares skillFolderHash, then immediately spawnSync('add', …, '-y') to overwrite. There is no way to obtain the "update-available list" without performing the updates.

So the issue's core ask — "check whether installed skills have newer versions, show the list, then let the user choose" — maps to a CLI capability that doesn't exist at the pinned version.

Feasible shapes considered (both rejected)

• A. Run npx skills update -g -y and parse its output. Honest to the CLI's real behavior and reuses the existing skillsCliService spawn path — but it applies updates to all global skills on one click, with no preview, pulling new upstream content into the user's live ~/.agents/skills/ unattended. That contradicts the app's "don't mutate the user's live skills without care" ethos and the "confirm before hard-to-reverse / outward-facing actions" rule, and it silently drops the issue's primary "check first" UX. Shipping it via a notarized release would push that behavior to real users. This is a product/behavior decision, not a mechanical one.
• B. Reimplement the hash-comparison check in the app (read the lock file's skillFolderHash, fetch the latest GitHub tree, recompute the folder hash → build a preview list without applying). This is faithful to the requested UX, but it forks computeSkillFolderHash + lock-file parsing from skills-CLI internals that carry no stability contract. A future CLI change to the hashing algorithm would silently produce false "update available" / "up to date" results. Unsound to maintain.

Recommendation

Keep this issue open and revisit once the skills CLI exposes a check-only / --json mode for update (or a documented dry-run that lists updatable skills without applying). At that point the original design — list → one-click update, global/project scope — becomes feasible and safe to build. An upstream request to vercel-labs/skills for skills update --json / --dry-run would unblock it directly.

Deferred during the current issue-sweep: investigated, documented, not built — the only faithful build (B) is unsound, and the only safe build (A) changes the feature's behavior and needs product sign-off.