skillshare v0.20.28 Release Notes
TL;DR
- Your project directory can be visible now β
skillshare init -p --visiblecreatesskillshare/instead of the hidden.skillshare/, for repositories where skills are reviewed like any other content. .skillignoreworks on Windows again β a file saved with CRLF line endings silently ignored nothing, whilestatusstill listed its patterns as loaded.- A directory symlink inside a skill no longer wipes its file hashes β hashing stopped at the first entry it could not read and discarded everything computed so far.
A visible project directory
Project mode has always been marked by a hidden .skillshare/ directory, and trash, backups and logs live inside it. That suits tool state, but not repositories that treat skills as content people review in pull requests like anything else in the tree.
--visible creates the same layout under a plain skillshare/ directory instead:
skillshare init -p --visible<project-root>/
βββ skillshare/
β βββ config.yaml
β βββ skills/
β βββ agents/
βββ src/
Nothing else changes. config.yaml, skills/, agents/, extras/ and the operational trash/, backups/ and logs/ directories all live inside whichever project directory is in use.
Detection looks for .skillshare/config.yaml first and skillshare/config.yaml second, so existing projects keep working exactly as before and the hidden directory wins if both are present. Running init -p without the flag still creates .skillshare/.
To move a project you already have:
mv .skillshare skillshare
skillshare sync -p # repair target symlinks pointing at the old pathIf your sources settings name .skillshare/ explicitly, update those paths in config.yaml before syncing. Refs: #256.
.skillignore and CRLF line endings
A .skillignore saved with Windows line endings compiled every rule with a trailing carriage return, which can never match a path segment. The result was silent: nothing was ignored, and status still reported the patterns as loaded, so the file looked like it was working.
Editing patterns had the same problem β existing entries were not found, adding one created a duplicate, and removing one failed. This regressed in v0.17.4 and now behaves the way git reads a CRLF .gitignore. Refs: #275.
Directory symlinks no longer discard skill hashes
Skillshare records a hash for each file in an installed skill so it can tell later whether you edited it locally. Hashing stopped at the first entry that could not be read as a file β a directory symlink inside a skill, for example β and threw away every hash collected up to that point, leaving the skill without that metadata.
Directory symlinks are skipped now. File symlinks are still hashed, and genuine problems such as a broken link still surface as errors. Refs: #272.
Changelog
- 18734ab chore: release v0.20.28
- 60e19f9 feat(project): support a visible
skillshare/project directory (#256) (#258) - ea442b9 fix(install): skip directory symlinks when computing file hashes
- 7a8db3b fix(skillignore): strip \r so CRLF files match
Notes
- Full changelog: https://github.com/runkids/skillshare/blob/main/CHANGELOG.md
- Security model docs: https://skillshare.runkids.cc/docs/guides/security
- Command reference: https://skillshare.runkids.cc/docs/commands