Browse and compare versions

Every publish adds an immutable, content-hashed version to a skill's linear history — and every one of them stays browsable forever. This guide reads that history from both sides: the dashboard, where a skill's Versions and Files tabs give you a timeline, the real file body of any release, and a red/green diff between two of them; and the CLI, where skillhub outdated, skillhub list, and skillhub update let you see where your installs sit and move them between versions on purpose.

If you want the model first, read Skills & versions and Versions & dist-tags; this page is the hands-on tour.

Find the skill in the dashboard

A skill's page is organized into tabs — README, Versions, Files, and (for imported skills) Provenance. The Versions and Files tabs are where its history lives.

You can jump straight to a skill's page from the terminal instead of clicking in — skillhub open takes an @owner/registry/skill ref (append @version to open an exact release):

skillhub open @studio/design-systems/tokens-workflow

Read the version timeline

Inspect a version's files

Pick a version from the timeline and open the Files tab to read what actually shipped in it — not a re-render, but the real file body captured in that content-hashed snapshot. This is the same content the registry hashed at publish, so what you're reading is exactly what an install of that version would extract.

Because each version is its own frozen snapshot, switching the selected version switches the files with it — you can read SKILL.md (or any script or reference) as it existed at 1.0.0 and again at 1.2.0 without leaving the page.

Compare two versions

The Versions and Files tabs tell you what a release contains; the compare view tells you what changed between two of them. Because both sides are stored snapshots, the registry computes a real red/green diff — reviewing a skill update reads exactly like a code review.

The diff has two layouts, and you can toggle between them live:

Track your installs from the CLI

The dashboard shows a skill's published history. The CLI shows where your installs sit against it — and lets you move between versions deliberately. Three read-only commands map the terrain before you change anything.

skillhub list

skillhub outdated

{
  "ok": true,
  "data": {
    "scope": "project",
    "skills": [
      {
        "ref": "@studio/design-systems/tokens-workflow",
        "name": "tokens-workflow",
        "current": "1.0.0",
        "wanted": "1.2.0",
        "latest": "2.0.0",
        "pinned": null,
        "deprecated": null,
        "renamedTo": null,
        "yanked": false,
        "upToDate": false
      }
    ]
  }
}

Move between versions

There are two ways to change which version a scope resolves, and they answer two different questions.

skillhub update

skillhub update --dry-run

skillhub update tokens-workflow@^2.0.0

skillhub update tokens-workflow@2.0.0

skillhub update tokens-workflow@beta

Move a dist-tag (maintainers)

Everything above reads or resolves versions. If you maintain the skill, you can also move the pointers themselves. skillhub tag slides a dist-tag onto an exact published version — the same promotion the dashboard performs when it lands a release tag:

skillhub tag @studio/design-systems/tokens-workflow@2.0.0 latest

The move is enforced server-side: a release-only tag is refused on a prerelease version, and on a review-required registry only an admin can land the release tag. The result echoes what the tag pointed at before, so a move is never silent:

{
  "ok": true,
  "data": {
    "ref": "@studio/design-systems/tokens-workflow@2.0.0",
    "tag": "latest",
    "version": "2.0.0",
    "previousVersion": "1.2.0"
  }
}

After the move, the Versions tab shows latest pinned to its new row — the timeline and the tag pointers stay in lockstep with what the CLI just did.

Where to go next