skillshare v0.20.29 Release Notes

TL;DR

1. install -p no longer strips the skills it just installed from config.yaml — setting a project up from a clean checkout installed everything correctly on disk, then removed the declarative list that made it reproducible for the next person.

install -p keeps your declarative skill list

The documented way to adopt skillshare in a repository is to commit a project config with a skills: list, and let everyone else run:

skillshare install -p
skillshare sync -p

On a clean checkout — nothing installed yet — that first command did the right thing on disk and the wrong thing to the config. Skills were fetched, their metadata was written, and the install reported success. Then the entries describing them were removed from config.yaml, so the file that was supposed to be the source of truth no longer said what to install.

The trigger was a source pointing at a subdirectory of a repository, which is how most shared skills are referenced:

skills:
  - name: my-skill
    source: https://github.com/someone/skills.git/skills/my-skill

A skill installed that way arrives as a plain copy of those files, without a repository of its own. After every install, skillshare re-checks what is on disk and keeps config.yaml in step with it — but that check was reading a picture of the installed skills taken before the install ran. The freshly copied skills were missing from it, so their entries looked stale and were pruned.

Two things made this easy to miss. The install itself succeeded, so nothing looked wrong until you opened config.yaml. And the check only runs when something was actually installed, so running the command a second time left the file alone.

Installing a skill by URL was never affected, which is why this only showed up in the config-driven flow. Project-mode installs made through skillshare search shared the same problem and are fixed by the same change.

If a project already lost its skills: block, restore it from version control — the entries were only removed at install time, and this release stops that happening. Refs: #280.

Thanks to @Snurppa for the report, the root-cause analysis, and for verifying the fix.