Skip to content

Add catalog update command and sync accepted skill versions #6

Description

@itsjling

What to build

Add viblib update to check catalog skills for upstream changes, let the user accept all updates or choose skills, and record the accepted versions. The user then runs viblib sync in each project to apply those versions.

The catalog currently stores skill names, source refs, and categories. It does not record a separate resolved version. Sync compares sources and literal refs, so a new commit on the same branch does not count as drift. This ticket includes the version checks and install behavior needed to make the full update-then-sync flow work.

Agreed behavior

An accepted update selects an exact revision. If upstream changes again before the user runs sync, sync installs the accepted revision. Preserve the source used to check for future updates, including its branch or other ref. The implementation may use the existing source representation or separate version state; this ticket does not require a new catalog field.

Use the pinned Skills CLI for skill operations. Its update command acts on installed skills, so do not assume that calling it in the current project will update only the catalog. Verify its supported interfaces before choosing how to check and record catalog revisions.

Acceptance criteria

  • Plain viblib update checks the whole catalog, regardless of the current project, and shows which skills have updates before changing catalog state.
  • In a terminal, offer Update all, Choose skills, and Cancel. Only accepted selections change state. Cancellation leaves state unchanged.
  • --check reports updates without writing. --yes accepts all available updates without prompts. Without a terminal, default to checking only unless --yes is set. --check always prevents writes.
  • Record an exact accepted revision for each selected skill. Preserve skill names, categories, and the source needed for later update checks.
  • Update does not change project or global skill installs, their links, or their lock files.
  • Existing catalogs remain readable. When an entry has no recorded revision, show that it needs an initial version baseline rather than claiming it has an update. Record that baseline only when the user accepts it.
  • Sync detects when an installed skill differs from its accepted catalog revision and applies that revision. Install also uses the accepted revision when one exists. Preserve current behavior for entries with no accepted revision.
  • After accepting a revision, later upstream changes do not change what install or sync applies. A second sync reports no drift once the accepted revision is installed.
  • Empty catalogs and catalogs with no updates produce clear output. Unsupported sources, unavailable sources, and failed checks do not appear as current skills. Do not silently move an explicit pinned ref to a different release or branch.
  • A failed update preserves that skill's prior state. Report successful, skipped, and failed results separately. Do not claim full success after a partial failure.
  • After recording accepted versions, print: Run viblib sync in each project to apply these skill versions. Use viblib sync --global for global installs.
  • Document command behavior, first-time version tracking, supported source types, and exit codes. Keep check and failure exit codes consistent with sync where their meanings match.
  • Tests cover first-time tracking, all and partial selection, cancellation, non-interactive checks, failed sources, unchanged installed state during update, and exact-version install and sync after upstream moves again. Verify the full flow against the pinned Skills CLI, including repeated sync.

Out of scope

  • Project discovery or updating several projects in one command.
  • Automatic project or global sync after update.
  • New command grouping or changes to existing default install scope.
  • New skill/category selectors for update in this first ticket.

Blocked by

None. This is one complete update-then-sync ticket. Issue #4 concerns command naming and scope, but its proposed redesign is not a prerequisite.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestready-for-agentFully specified and ready for an agent to implement

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions