Skip to content

vskill 1.0.0

Choose a tag to compare

View all tags
@anton-abyzov anton-abyzov released this 27 Apr 07:19
· 185 commits to main since this release
v1.0.0
727b31d

Highlights

Studio update notifications — multi-update visibility (the headline fix)

useSkillUpdates.buildMap and the reconcileCheckUpdates setUpdates callback both keyed by leaf-name only (u.name.split('/').pop()). When two skills shared a leaf name across plugins (e.g. acme/x/foo + bob/y/foo), the second silently overwrote the first in updatesMap and downstream lookups, hiding one of the available updates from the panel.

1.0 keys updatesMap by canonical full name (<owner>/<repo>/<skill> or <plugin>/<skill>) and adds a leaf alias only when unambiguous; ambiguous leaves drop the alias deterministically rather than overwrite. The dropdown panel reads updates[] directly so the panel itself was unaffected, but everything downstream of updatesMap is now collision-safe.

Tests

  • New unit cases for two distinct updates and same-leaf collision (useSkillUpdates.test.ts)
  • New E2E cases asserting the dropdown lists every entry when polling returns multiple, including same-leaf-cross-plugin (e2e/update-notifications.spec.ts)

Note on source-origin skills

Locally authored skills (no lockfile entry) are not tracked by /api/skills/updates — the polling endpoint enumerates lockfile entries via getOutdatedJson(). Self-publishing notifications for source-origin skills you author are tracked as a separate follow-up.

Why 1.0

This release transitions vskill to 1.0 to mark the public API as stable for the Studio update-notification contract and the vskill skill CLI surface introduced over the 0.5.x series.

Assets 2
Loading