mirror of
https://github.com/only-cli/oc.git
synced 2026-09-15 10:40:56 +02:00
only-cli
b084e080bb
skills.sh renders skills/web-browsing-cli/SKILL.md straight from GitHub, and the release checklist said there was nothing to do for it because the skills CLI reads that file live off main. That is true of the install path and false of the page: the page showed the 0.2.0 pin from 2026-08-20 while main had already shipped 0.3.0 and 0.4.0 the same day, so every reader was handed a two-release-old install command. The site offers exactly one lever. Its documented API is read only, with no refresh or re-index endpoint, and the skills CLI has no publish or sync command; a repository is re-read after the telemetry service sees an install from it, and repo pages are cached on top of that. So a stable publish now runs one `skills add` against the repo, which is the invocation the install-remove-loop experiment already proved out. It costs one install on the counter per release, which is the price of the only mechanism there is. The job is continue-on-error and runs after npm publish has already succeeded: a page that catches up late is a smaller problem than a red release. The refresh is worthless if the pin it publishes is stale, which is the actual root cause here, so a latest publish now fails when SKILL.md disagrees with package.json. Beta and dev skip the check, because a pin moves when a release is stable rather than when it enters beta, which is the rule 0.3.0-beta.1 already followed. Verified both ways against the current tree: it passes on 0.4.0 with a matching pin and refuses a 0.4.0 release still pinning 0.2.0. The channel the earlier step resolves is now a job output, so the refresh job can gate on it instead of re-deriving it from the version string.